Noi apariţii/versiuni de software popular

_~_

Membru
Joined
May 6, 2005
Location
Viena, Austria
Nimeni. Eu zic de mine și de Velkan (că el a adus vorba). Bănuiesc că sunt mulți alții pe forum care fac la fel.

 

AdrianB1

Membru Senior
Sugar daddy
Joined
Aug 3, 2004
Location
offline
Modelul psihoacustic e același, implementarea diferă din punctul de vedere al compilării/asamblării/codului mașină generat. Presupun că pe 64 biți există niște instrucțiuni care nu există / funcționează altfel pe 32 de biți (operanzi nativi pe 64 biți sau diverse intrinsics care nu există decît pe 64 de biți) și-atunci compilatorul/asamblorul (că nenea a zis de nasm) emulează funcționalitatea respectivă (nasm math routines) cînd ținta e 32 de biți. Algoritmu' o fi el același, da' cînd începi să faci calcule în virgulă mobilă faci aproximări.
Explicatia ta nu are nici un sens, daca ai un algoritm nu poate sa faca compilatorul pilaf din el ca asa are chef, trebuie sa respecte ordinea si corectitudinea calculelor, altfel 1+1 va avea rezultate impredictibile in functie de ce a baut compilatorul in seara precedenta si ala nu mai e computer, e masinia de calculat probabilitati (adica nu da rezultate exacte, ci aproximari).
 

_~_

Membru
Joined
May 6, 2005
Location
Viena, Austria
1+1 va avea rezultate impredictibile in functie de ce a baut compilatorul in seara precedenta
De fapt, floating point nu e determinist. Dacă ai nevoie de un rezultat determinist atunci nu folosești floating point, ci fixed precision arithmetic implementat în integer operations.

Dar nu acesta e motivul pentru rezultate diferite. Am scris mai devreme, codul e diferit. Pe 32bit se folosește o bibliotecă scrisă în assembly (de către developeri) pe 64 bit se folosesc compiler intrinsecs.

PS: fără vreo legătură cu problema de mai sus, dar foarte mulți algoritmi depind de rand() și nu sunt determiniști, de exemplu tot ce e legat de criptare.
 

AdrianB1

Membru Senior
Sugar daddy
Joined
Aug 3, 2004
Location
offline
Nu am zis ca nu am inteles si nu am acceptat explicatia ta, ci pe a lui whiskas. Procesarea unui mp3 poate fi facuta deterministic, iar tot ceea ce e legat de criptare e intentionat facut asa.
 

whiskas

Chronic suicidal
Joined
Jan 19, 2005
Adrian, fix ce-a zis _~_, mai zic și eu o dată: degeaba e algoritmul același dacă faci calcule în virgulă mobilă.
În ceea ce privește LAME, mai citește o dată ce-am zis (și ce-a zis și _~_ mai sus, mai bine și mai la obiect ca mine): diferă implementarea, adică funcțiile alea de matematică care-s unele pe 32 biți și altele pe 64 biți.
 

IceCub

Membru Senior
Sugar daddy
Joined
Jun 27, 2005
Location
/dev/urandom
Sa fie de la faptul ca operatiile cu FPU 64bit au prezicie mai mare? Pana la urma 1.2 + 1.2 ≠ 1.21+1.21
 

AdrianB1

Membru Senior
Sugar daddy
Joined
Aug 3, 2004
Location
offline
Operatiile FPU sunt aceleasi pe i86 si pe x64, nu inseama ca pe x64 ai FPU pe 64 si la i86 ai FPU pe 32 de biti :smile: Diferenta intre 32 si 64 e in mare la dimensiunea registrilor si a adreselor de memorie, nu de setul de instructiuni (da, exista variante de instructiuni pentru operatiile pe 64 de biti ca altel nu poti manipula registrii si adresele de memorie, dar nu despre asta e vorba).

Nu, codul e pur si simplu diferit si gata. La i86 are bucati facute cu manuta, la x64 e cod generat de compilator si nimeni nu isi bate capul sa verifice daca rezultatele sunt egale pentru ca oricum rezultatele sunt in sine o aproximatie ("psihoacustica"). Ma mir ca nu au deja discutii daca variante pe 32 se aude mai bine decat cea pe 64 sau ca una baga distorsiuni audibile pentru lilieci.
 

whiskas

Chronic suicidal
Joined
Jan 19, 2005
Operatiile FPU sunt aceleasi pe i86 si pe x64, nu inseama ca pe x64 ai FPU pe 64 si la i86 ai FPU pe 32 de biti :smile: Diferenta intre 32 si 64 e in mare la dimensiunea registrilor si a adreselor de memorie, nu de setul de instructiuni (da, exista variante de instructiuni pentru operatiile pe 64 de biti ca altel nu poti manipula registrii si adresele de memorie, dar nu despre asta e vorba).
Depinde. În modul x86 se folosește una bucată FPU, în modul x86-64 se folosește una bucată de procesare vectorială cu instrucțiuni SSE. Sînt mai multe opcodes disponibile pentru aceeași operație, chiar dacă e același calcul.

Nu, codul e pur si simplu diferit si gata. La i86 are bucati facute cu manuta, la x64 e cod generat de compilator si nimeni nu isi bate capul sa verifice daca rezultatele sunt egale pentru ca oricum rezultatele sunt in sine o aproximatie ("psihoacustica"). Ma mir ca nu au deja discutii daca variante pe 32 se aude mai bine decat cea pe 64 sau ca una baga distorsiuni audibile pentru lilieci.
Da, codul e diferit, că doar asta a zis și dezvoltatorul. Cît despre egalitatea rezultatelor, 1,1 nu e egal cu 1,1 în virgulă mobilă decît dacă [ adaugă multe chestii restrictive pe-aici ].

Revenind la mesajul inițial: ce contează? :smile:
 

AdrianB1

Membru Senior
Sugar daddy
Joined
Aug 3, 2004
Location
offline
Depinde. În modul x86 se folosește una bucată FPU, în modul x86-64 se folosește una bucată de procesare vectorială cu instrucțiuni SSE. Sînt mai multe opcodes disponibile pentru aceeași operație, chiar dacă e același calcul.
Nu depinde de nimic, in ambele moduri ai la dispozitie aceleasi operatii, utilizarea SSE tine de capabilitatea procesorului (existenta instructiunilor) nu de modul de lucru. Or fi mai multe opcodes disponibile pentru aceeasi operatie, daca folosesti operatii diferite nu mai e acelasi cod.

De ce conteaza? Pentru ca vei obtine rezultate diferite, unul mai bun si unul mai prost (egale - cam greu de crezut). Si de ce sa faci prost cand poti sa faci bine?
 

_~_

Membru
Joined
May 6, 2005
Location
Viena, Austria
De fapt SSE nu e deloc determinstic, același algoritm cu același input poate să dea rezultate ușor diferite la rulări diferite. x87 are un oarecare mod determinist care e semnificativ mai lent decât modul non-determinist așa că nu e folosit în practică de nimeni. Cine are nevoie de precizie cunoscută folosește integer math anyway.

Si de ce sa faci prost cand poti sa faci bine?
Pentru că e mult mai rapid să faci prost. în general nu merită să faci determinist, precizia floating point oricum variază și nu o cunoști dinainte, dacă ai toleranțe mici sau dacă algoritmul e instabil numeric folosești integer math, care e mai lent.

 

Foxter

Membru Senior
Joined
Aug 22, 2006
Location
Bucuresti
CCleaner v3.12.1572.
Changelog:

- Added Firefox 8.0 Beta support.
- Added Firefox 7.0 Final support.
- Added secure delete for Cluster tips.
- Added secure delete for Alternate Data Streams.
- Added cleaning for Network Passwords.
- Added PATH environment variable cleaning.
- Added cleaning for Top Sites in Safari.
- Improved support for Chrome Canary.
- Improved support for Firefox Aurora channel.
- Added cleaning for AVG AntiVirus 2012, ACDSee 14, BitZipper and Avast! Antivirus 6.
- Improved cleaning for VLC Media Player and Axialis IconWorkshop.
- Added Marathi translation.
- Minor bug fixes.
 

Velkan

Moderator
Joined
Oct 30, 2006
Location
Bucureşti
Ăștia-s ca ăia de la uT - cînd îl deschizi nu poți să dai resume la... distribuția de Linux (sau porn, după caz) că trebuie actualizat. x.x.x.1 zilnic mi se pare cam stresant.
 

whiskas

Chronic suicidal
Joined
Jan 19, 2005
Aceeași poveste e și cînd folosești Calibre.
Release early, release often da' parcă nici chiar așa. :biggrin:
 

Thor

Membru Senior
Sugar daddy
Joined
Dec 6, 2004
Location
/dev/null
Cam dubioasa miscarea developerilor. Adica inteleg ca e foame de bani, dar acelasi lucru se putea face inainte prin whitelisting.
 

ipman

Membru Senior
Joined
Nov 7, 2003
Location
Stockholm
Cam acelasi lucru se intimpla si cu Spamhaus. Si datorita legislatiei interstatale greoaie, nici macar legal nu poti actiona in cazuri justificate.
 
Top Bottom