mboost-dp1
Microsoft
Ok den Steam statistik. Jeg kan ikke forestille mig mange gamere der bruger systemer der ikke kan køre 64-bit.
Der er vel to aspekter:
32-bit programmer vs. 64-bit programmer
Windows 10 32-bit vs. Windows 10 64-bit.
Som jeg forstår det er det Windows 10 32-bit der får sparket. Windows 10 64-bit vil stadig kunne køre 32 og 64 bit programmer.
Således vil gamle systemer der ikke kan køre 64-bit installationen af Windows blive ladt i stikken.
Right?
32-bit programmer vs. 64-bit programmer
Windows 10 32-bit vs. Windows 10 64-bit.
Som jeg forstår det er det Windows 10 32-bit der får sparket. Windows 10 64-bit vil stadig kunne køre 32 og 64 bit programmer.
Således vil gamle systemer der ikke kan køre 64-bit installationen af Windows blive ladt i stikken.
Right?
larsp (4) skrev:Der er vel to aspekter:
32-bit programmer vs. 64-bit programmer
Windows 10 32-bit vs. Windows 10 64-bit.
Som jeg forstår det er det Windows 10 32-bit der får sparket. Windows 10 64-bit vil stadig kunne køre 32 og 64 bit programmer.
Ja. Men de vil ikke kunne køre 16 bit programmer. Hvilket der formentligt heller ikke er mange som vil.
larsp (4) skrev:
Således vil gamle systemer der ikke kan køre 64-bit installationen af Windows blive ladt i stikken.
Right?
Ja. Men det er næsten 15 år siden Intel og AMD stoppede med at lave 32 bit only CPU'er, så det skal være nogle ret gamle PC'ere.
#4 Korrekt. Den danske oversættelse / genfortælling er helt forkert på den. Det kan ikke sammenlignes med Catalina til Mac OSX. Det er 32-bit versionen af Windows, der udfases fra maj, ikke understøttelsen af 32-bit programmer - 'for the time being'i hvert fald.
Generelt, vil jeg sige, at Newz.dk i dag bør betragtes som en link-feed. Stol hverken på overskrift eller brødtekst, for sansynligheden for fejl er ret stor. Foreslået rettelser ignoreres tilmed også ofte.
Generelt, vil jeg sige, at Newz.dk i dag bør betragtes som en link-feed. Stol hverken på overskrift eller brødtekst, for sansynligheden for fejl er ret stor. Foreslået rettelser ignoreres tilmed også ofte.
#6 Nemlig... det som skete med Catalina gav ikke rigtig mening.
Hvad var idéen der helt præcis? Var der en idé bag det? Rigtigt mange apps synes jeg er gode til at have både 32 og 64 bit version, og det syntes jeg også de burde. Specielt fordi jeg stadigt bruger 32 bit operativ systemer engang imellem.
Men generelt vil jeg gerne have at min maskine kan køre så meget software som muligt. Ofte syntes jeg at der kan være software som måske er 10 år gammelt, men stadigt er bedre til det man bruger det til end de nye alternativer... og så har de nye alternativer måske også en løsning der kræver et abonnement.
Hvad var idéen der helt præcis? Var der en idé bag det? Rigtigt mange apps synes jeg er gode til at have både 32 og 64 bit version, og det syntes jeg også de burde. Specielt fordi jeg stadigt bruger 32 bit operativ systemer engang imellem.
Men generelt vil jeg gerne have at min maskine kan køre så meget software som muligt. Ofte syntes jeg at der kan være software som måske er 10 år gammelt, men stadigt er bedre til det man bruger det til end de nye alternativer... og så har de nye alternativer måske også en løsning der kræver et abonnement.
kblood (8) skrev:Det er vel mest overskriften der er forkert? De dropper 32 bit Windows 10... ikke 32 bit i Windows 10.... for så lyder det netop som om at Windows 10 pludselig ikke vil tillade, eller understøtte 32 bit applicationer.
Dog vil muligheden for afviklingen af 16 bit programmer ikke længere være muligt uden emulering af et tidligere OS... fx hvis man vil køre gamle 16 bit windows spil
Fordi 64 bit windows 10 kan køre 64 og 32 bit software
Mens 32 bit windows 10 kan køre 32 og 16 bit software
Det er vel også på tide at de udfaser 32 bit. Det har jeg ventet på siden XP-64 bit kom på markedet. Det der spil hvor MS og Intel/AMD har siddet og lurepasset hinanden om hvornår den ene tager springet helt men begge tøver. Det spil kunne vi godt have været for uden. Det er ikke andet end en klods om benet ved at køre 32bit på produktions maskiner i dag.
Speaking of.... Skal de ikke snart i gang med at lave 128bit maskiner og styresystemer? Jeg vil da mene at tiden er ved at være moden. 15 år med 64 bit (rundt regnet) og det er først nu man er ved at gå all in. Er det ikke lidt af en joke?
Bare giv mig en 128bit ARM arbejdsstation med Linux installeret, og jeg er tilfreds.
Speaking of.... Skal de ikke snart i gang med at lave 128bit maskiner og styresystemer? Jeg vil da mene at tiden er ved at være moden. 15 år med 64 bit (rundt regnet) og det er først nu man er ved at gå all in. Er det ikke lidt af en joke?
Bare giv mig en 128bit ARM arbejdsstation med Linux installeret, og jeg er tilfreds.
#13 Der er flere grunde end bare ram at få 128bit arkitektur, eller bare mere end 64bit. Men det ville måske være mere til videnskabeligt brug og måske ikke til almindelige servere, f.eks. at kunne bruge langt større og mere præcise tal, uden at skulle lave software tricks.
#14
Måske skal vi være lidt mere præcise med hvad vi mener med X bit arkitektur.
Jeg vil mene at det normalt at X bit betyder X bits i virtuelle adresser.
Hvis du med X bit mener at der i CPU er support for aritmetiske integer operationer op til X bit, så er det noget andet.
Men:
* for det første mener jeg ikek at den definition er så gængs - VAX er almindeligt anerkendt som en klassisk 32 bit arkitektur og havde fuld support for 64 bit integer operationer
* den praktiske konsekvens er ikke så stor, da HLL sagtens kan supportere integers med flere bits end CPU'en - en operation bliver bare til 2 eller flere instruktioner
Måske skal vi være lidt mere præcise med hvad vi mener med X bit arkitektur.
Jeg vil mene at det normalt at X bit betyder X bits i virtuelle adresser.
Hvis du med X bit mener at der i CPU er support for aritmetiske integer operationer op til X bit, så er det noget andet.
Men:
* for det første mener jeg ikek at den definition er så gængs - VAX er almindeligt anerkendt som en klassisk 32 bit arkitektur og havde fuld support for 64 bit integer operationer
* den praktiske konsekvens er ikke så stor, da HLL sagtens kan supportere integers med flere bits end CPU'en - en operation bliver bare til 2 eller flere instruktioner
arne_v (5) skrev:Ja. Men det er næsten 15 år siden Intel og AMD stoppede med at lave 32 bit only CPU'er, så det skal være nogle ret gamle PC'ere.
Helt så lang tid er det nu ikke siden. Intel Atom Z2580 blev lanceret i Q2'13 og det er en ren 32-bit processor. Jeg er ikke sikker på hvor længe den blev produceret, men mon ikke det var et lille års tid som de fleste af deres modeller? 32 bit Atoms blev bl.a. brugt i de netbooks som var ret populære en overgang. Ovenstående model er dog fra dengang hvor Intel forsøgte at indtage Android markedet, så den blev brugt i telefoner og tablets.
arne_v (15) skrev:#14
Måske skal vi være lidt mere præcise med hvad vi mener med X bit arkitektur.
Jeg vil mene at det normalt at X bit betyder X bits i virtuelle adresser.
Hvis du med X bit mener at der i CPU er support for aritmetiske integer operationer op til X bit, så er det noget andet.
Men:
* for det første mener jeg ikek at den definition er så gængs - VAX er almindeligt anerkendt som en klassisk 32 bit arkitektur og havde fuld support for 64 bit integer operationer
* den praktiske konsekvens er ikke så stor, da HLL sagtens kan supportere integers med flere bits end CPU'en - en operation bliver bare til 2 eller flere instruktioner
Ja, men det er det jeg mener jeg software tricks at man skal til at bruge 2 bits eller mere for at kunne lave større og mere præcise tal.
Men i programmerings sprog og sådan er der vidst stadig store dele der er 32bit baseret fordi det bare ikke er blevet opdateret endnu og det er vidst også en af grundende til at nogle ting ikke fungere optimalt. Selv med en 128bit CPU ville der nok gå lang tid før at software ville undersøtte det særligt godt, når man tænker på hvor langsomt det er gået med 64bit.
Men til videnskabelig brug, så vil det være halvere antal operationer der skulle bruges til udregner med tal med den nøjagtighed, og det kunne hurtigt betyde en del for spil hvis man rent faktisk begyndte at udnytte så stor en præcision... allerede nu bruges der alle mulige tricks for at komme udenom de egentlig ret små tal vores programmerings sprog har det med at understøtte.
Game engines er stadigt 32 bit, og det er et problem for spil... specielt fordi spil virkeligt har svært ved at komme udenom at have brug for mindst 64bit nøjagtighed til mange ting.
Så ja... hvis vi startede med at udnytte 64bit ville det da nok hjælpe en del, men vil nu mene at 128bit har sin plads også og ville give mening. Medmindre at det så ville betyde at det ville forværre performance på andre områder, men det tvivler jeg nu på.
32-bit giver en range på ca. +/- 2 milliarder som signed integer. Det dækker langt de fleste formål. 64-bit integers har i min tid som udvikler sjældent været nødvendig men jeg har brugt det ind imellem, f.eks. til at tælle nanosekunder og ikke være bekymret for om tælleren laver overflow de næste par hundrede år. Og når man laver fixed-point matematik i 32 bit kan et smut forbi 64-bit også være nødvendigt.
#20 128-bit? You gotta be kidding me. Fortæl mig bare én reel use case for at beregne noget i 128-bit opløsning, jeg er nysgerrig.
#20 128-bit? You gotta be kidding me. Fortæl mig bare én reel use case for at beregne noget i 128-bit opløsning, jeg er nysgerrig.
#20 Går din point mht. game engines ikke på single precision (32-bit) floats? Her kan jeg godt følge dig. De kommer ofte til kort mht. præcision. 64 bit double precision floats har helt klart sin plads.
Men det kommer også an på algoritmen. Alle floating point algoritmer kan komme i problemer hvis de akkumulerer afrundingsfejl.
Men det kommer også an på algoritmen. Alle floating point algoritmer kan komme i problemer hvis de akkumulerer afrundingsfejl.
#20
De fleste sprog understøttter 64 bit integers.
Java : long
C# : long
VB.NET : Long
C/C++ : long long int / int64_t (i de fleste implementationer)
Fortran : integer*8 (i de fleste implementationer)
Men der bruges ofte 32 bit integer. Hvis de er store nok, så er der ikke behov for mere.
De fleste sprog understøttter 64 bit integers.
Java : long
C# : long
VB.NET : Long
C/C++ : long long int / int64_t (i de fleste implementationer)
Fortran : integer*8 (i de fleste implementationer)
Men der bruges ofte 32 bit integer. Hvis de er store nok, så er der ikke behov for mere.
#20
En 128 bit add operation bør være hurtigere end en 64 bit add + en 64 bit add with carry. O.s.v..
Men at tilføje sådanne instruktioner kan gøres uden at ændre fundamentalt på ISA.
For direkte memory access er det bare en ekstra opcode og de normale adresser som argument.
For register access kan man gøre der samme som V32 bit VAX gjorde for 64 bit nemlig bruge 2 registre.
addq3 r2, r4, r6
adderede en 64 bit integer gemt i r2 og r3 med en 64 bit integer gemt i r4 og r5 til resultat gemt i r6 og r7.
En 128 bit add operation bør være hurtigere end en 64 bit add + en 64 bit add with carry. O.s.v..
Men at tilføje sådanne instruktioner kan gøres uden at ændre fundamentalt på ISA.
For direkte memory access er det bare en ekstra opcode og de normale adresser som argument.
For register access kan man gøre der samme som V32 bit VAX gjorde for 64 bit nemlig bruge 2 registre.
addq3 r2, r4, r6
adderede en 64 bit integer gemt i r2 og r3 med en 64 bit integer gemt i r4 og r5 til resultat gemt i r6 og r7.
#22
Har man brug for 128 bit FP?
Med hensyn til FP er der jo 2 ting som ændrer sig ved flere bitsÆ
* større range aka support for større tal
* større præcision aka flere decimaler i tal
64 bit FP range er stor nok til det meste.
64 bit FP præcision er langt større end målenøjagtighed (og som hovedregel bør FP kun bruges til størrelse osm måles!) - så meget større at regneunøjagtighed ikke akkumuleres.
Men naturligvis er der undtagelser.
Mange Fortran implementationer har real*16.
real*8 aka 64 bit FP har range op til E308 og ca. 15 decimalers præcision
real*16 aka 128 bit FP har range op til E4932 og ca. 33 decimalers præcision
Har man brug for 128 bit FP?
Med hensyn til FP er der jo 2 ting som ændrer sig ved flere bitsÆ
* større range aka support for større tal
* større præcision aka flere decimaler i tal
64 bit FP range er stor nok til det meste.
64 bit FP præcision er langt større end målenøjagtighed (og som hovedregel bør FP kun bruges til størrelse osm måles!) - så meget større at regneunøjagtighed ikke akkumuleres.
Men naturligvis er der undtagelser.
Mange Fortran implementationer har real*16.
real*8 aka 64 bit FP har range op til E308 og ca. 15 decimalers præcision
real*16 aka 128 bit FP har range op til E4932 og ca. 33 decimalers præcision
#24 kræver det så ikke enten C++ eller noget i den stil? C# har godt nok en del af den slags muligheder hvis man graver lidt i det, men generelt set prøver man i C# at ikke ændre på hvordan hukommelse bliver brugt (adresseret), og som jeg læser det, er det lidt hvad det her kræver? Medmindre det er implementeret som en standard løsning i C# allerede at kunne bruge sådan et trick.
#23 Tæller double og decimal ikke også som 64 bit? Men når der kommer decimaler ind i det, så begynder det at blive specielt syntes jeg, for hurtigt er det en del af tallet hvor kommaet er sat, hvis jeg husker korrekt. Så er der så udregninger som vidst giver problemer hvis man bruger decimal. Kan ikke lige huske eksemplet, så kan være at der var et andet problem. Nu jeg læser op på det, så er decimal da faktisk 128bit. Vi brugte den en del da jeg arbejdede hos Neas Energy, som handler og administrerer energy/strøm, fordi de har kæmpe mængder af data og præcision er vigtig. Selve beskrivelsen af den er faktisk at den ofte bruges når det gælder penge. Så decimal bruges for at undgå at der pludselig skulle være en afrunding et sted, for det ville være et problem... men så kommer der måske en database et sted der vælger at holde tal som doubles eller floats og det kan jo ødelægge en del.
https://docs.microsoft.com/en-us/dotnet/csharp/lan...
#20+#21 Jo, primært. Game engines har det med at bruge floats, og et problem med floats er at de ikke er præcise... altså ikke engang indenfor de værdier som en float understøtter. Den primære årsag til at de stadig bruger floats så meget, så vidt jeg ved, er at de stadig bygger på gammel kode man bare ikke har fået opdateret og det ville være et kæmpe arbejde at gennemgå 3D formler osv.
Men der hvor 128 bit begynder at kunne være brugbart er når man rent faktisk vil lave meget store virtuelle verdener. Bare at genskabe vores egen planet skaber en del problemer hvor at 256 bit sikkert også kunne blive brugbar at arbejde med. Der skal bruges utroligt mange tricks i f.ex. No Man's Sky bare for at lave et enkelt solsystem... og alt det vil jeg mene kunne udføres en del simplerer hvis man rent faktisk kunne arbejde med langt mere præcise tal. Når det kommer op på en galaktisk skala, så vil 256bit sikkert også hurtigt ikke være nok... men svært at sige. Jeg har været ved at regne lidt på det, og i mange tilfælde giver det da også mening at bruge nogle tricks, men at simulere noget som skal være f.ex. en del af en planet, som er en del af et solsystem... der bliver alligevel hurtigt en del nytte ved bare at kunne holde noget af det i nogle meget meget store tal, så nogle af disse ting kan udregnes rigtigt, i forhold til den egentlige virtuelle afstand mellem solsystems elementer
#23 Tæller double og decimal ikke også som 64 bit? Men når der kommer decimaler ind i det, så begynder det at blive specielt syntes jeg, for hurtigt er det en del af tallet hvor kommaet er sat, hvis jeg husker korrekt. Så er der så udregninger som vidst giver problemer hvis man bruger decimal. Kan ikke lige huske eksemplet, så kan være at der var et andet problem. Nu jeg læser op på det, så er decimal da faktisk 128bit. Vi brugte den en del da jeg arbejdede hos Neas Energy, som handler og administrerer energy/strøm, fordi de har kæmpe mængder af data og præcision er vigtig. Selve beskrivelsen af den er faktisk at den ofte bruges når det gælder penge. Så decimal bruges for at undgå at der pludselig skulle være en afrunding et sted, for det ville være et problem... men så kommer der måske en database et sted der vælger at holde tal som doubles eller floats og det kan jo ødelægge en del.
https://docs.microsoft.com/en-us/dotnet/csharp/lan...
#20+#21 Jo, primært. Game engines har det med at bruge floats, og et problem med floats er at de ikke er præcise... altså ikke engang indenfor de værdier som en float understøtter. Den primære årsag til at de stadig bruger floats så meget, så vidt jeg ved, er at de stadig bygger på gammel kode man bare ikke har fået opdateret og det ville være et kæmpe arbejde at gennemgå 3D formler osv.
Men der hvor 128 bit begynder at kunne være brugbart er når man rent faktisk vil lave meget store virtuelle verdener. Bare at genskabe vores egen planet skaber en del problemer hvor at 256 bit sikkert også kunne blive brugbar at arbejde med. Der skal bruges utroligt mange tricks i f.ex. No Man's Sky bare for at lave et enkelt solsystem... og alt det vil jeg mene kunne udføres en del simplerer hvis man rent faktisk kunne arbejde med langt mere præcise tal. Når det kommer op på en galaktisk skala, så vil 256bit sikkert også hurtigt ikke være nok... men svært at sige. Jeg har været ved at regne lidt på det, og i mange tilfælde giver det da også mening at bruge nogle tricks, men at simulere noget som skal være f.ex. en del af en planet, som er en del af et solsystem... der bliver alligevel hurtigt en del nytte ved bare at kunne holde noget af det i nogle meget meget store tal, så nogle af disse ting kan udregnes rigtigt, i forhold til den egentlige virtuelle afstand mellem solsystems elementer
kblood (28) skrev:
#24 kræver det så ikke enten C++ eller noget i den stil? C# har godt nok en del af den slags muligheder hvis man graver lidt i det, men generelt set prøver man i C# at ikke ændre på hvordan hukommelse bliver brugt (adresseret), og som jeg læser det, er det lidt hvad det her kræver? Medmindre det er implementeret som en standard løsning i C# allerede at kunne bruge sådan et trick.
Det kræver at Intel & AMD tilføjer sådann instruktioner og at compiler leverandørerne tilføjer nogle data typer som kan bruge dem.
Så absolut en stor ændring.
Men det kræver ikke et 128 bit mode og 128 bit OS.
kblood (28) skrev:
#23 Tæller double og decimal ikke også som 64 bit? Men når der kommer decimaler ind i det, så begynder det at blive specielt syntes jeg, for hurtigt er det en del af tallet hvor kommaet er sat, hvis jeg husker korrekt. Så er der så udregninger som vidst giver problemer hvis man bruger decimal. Kan ikke lige huske eksemplet, så kan være at der var et andet problem. Nu jeg læser op på det, så er decimal da faktisk 128bit. Vi brugte den en del da jeg arbejdede hos Neas Energy, som handler og administrerer energy/strøm, fordi de har kæmpe mængder af data og præcision er vigtig. Selve beskrivelsen af den er faktisk at den ofte bruges når det gælder penge. Så decimal bruges for at undgå at der pludselig skulle være en afrunding et sted, for det ville være et problem... men så kommer der måske en database et sted der vælger at holde tal som doubles eller floats og det kan jo ødelægge en del.
https://docs.microsoft.com/en-us/dotnet/csharp/lan...
C# double er en helt standard 64 bit FP. Eller for at være mere præcis: en 64 bit binær Floating Point.
C# decimal er en 128 bit (der er dog nogle spild bits) decimal Floating Point.
Indenfor range har decimal floating point samme egenskaber som fixed point for alt der er decimalt orienteret. Eller sagt på en anden måde: decimal kan bruges til bogholderi af penge.
Der er som bekendt dødsstraf for at bruge (binær) floating point til bogholderi af penge.
@floats
De tidlige 3D kort brugte lav opløsning floating points for at spare resourcer. Og det kunne ses som artifacts.
Gamle CPUer kunne regne floats ud hurtigere end doubles, og det ville ikke undre mig om der er kode derude der stadig kører med floats til visse formål hvor det er godt nok. Men ja, de giver sjældent en fordel i dag. Undtaget hvis antal tal der passer i cache, eller antal tal overført pr. hukommelsesbåndbredde er vigtigt.
I embedded kode prøver jeg nogen gange en algoritme af i både float og double for at se om der er en performance penalty. Der kan sagtens være forskel. Visse CPUer har ikke floating point acceleration overhovedet, og nogle CPUer har kun acceleration af én type floats.
De tidlige 3D kort brugte lav opløsning floating points for at spare resourcer. Og det kunne ses som artifacts.
Gamle CPUer kunne regne floats ud hurtigere end doubles, og det ville ikke undre mig om der er kode derude der stadig kører med floats til visse formål hvor det er godt nok. Men ja, de giver sjældent en fordel i dag. Undtaget hvis antal tal der passer i cache, eller antal tal overført pr. hukommelsesbåndbredde er vigtigt.
I embedded kode prøver jeg nogen gange en algoritme af i både float og double for at se om der er en performance penalty. Der kan sagtens være forskel. Visse CPUer har ikke floating point acceleration overhovedet, og nogle CPUer har kun acceleration af én type floats.
kblood (28) skrev:
Men der hvor 128 bit begynder at kunne være brugbart er når man rent faktisk vil lave meget store virtuelle verdener. Bare at genskabe vores egen planet skaber en del problemer hvor at 256 bit sikkert også kunne blive brugbar at arbejde med. Der skal bruges utroligt mange tricks i f.ex. No Man's Sky bare for at lave et enkelt solsystem... og alt det vil jeg mene kunne udføres en del simplerer hvis man rent faktisk kunne arbejde med langt mere præcise tal. Når det kommer op på en galaktisk skala, så vil 256bit sikkert også hurtigt ikke være nok... men svært at sige. Jeg har været ved at regne lidt på det, og i mange tilfælde giver det da også mening at bruge nogle tricks, men at simulere noget som skal være f.ex. en del af en planet, som er en del af et solsystem... der bliver alligevel hurtigt en del nytte ved bare at kunne holde noget af det i nogle meget meget store tal, så nogle af disse ting kan udregnes rigtigt, i forhold til den egentlige virtuelle afstand mellem solsystems elementer
Java java.math.BigInteger og .NET System.Numerics.BigInteger bør kunne klare det.
Java har valgt at definere aat de kan håndtere op til 64 milliarder bits.
MS har valgt at definere at de kan håndtere indtil man løber tør for memory.
Den praktiske forskel er næppe stor.
#28: .NET's decimal er 128 bit, men det er ikke grunden til at den er mere pålidelig end en float/double. Grunden til dette er, at den er Base10, mens de andre er Base2. Dvs. at sålænge man holder sig under dens præcision, er der ikke nogle tal, der ikke kan repræsenteres.
Prisen er, at den er meget langsommere end de andre datatyper, da der ikke findes mainstream CPU'er med native support for den slags beregninger. Ligesom der skal allokeres mere hukommelse til den.
Prisen er, at den er meget langsommere end de andre datatyper, da der ikke findes mainstream CPU'er med native support for den slags beregninger. Ligesom der skal allokeres mere hukommelse til den.
#33 Ja, lagerplads og cpu cycles er billige i dag.
Men jeg vil fastholde at der stadig er en case for floats. De giver plads til dobbelt så mange værdier i cache, og der kan presses dobbelt så mange igennem en given båndbredde, sammenlignet med double. En moderne processor har tit så meget fart på at det reelt er cache og båndbredde betragtninger der begrænser.
Men jeg vil fastholde at der stadig er en case for floats. De giver plads til dobbelt så mange værdier i cache, og der kan presses dobbelt så mange igennem en given båndbredde, sammenlignet med double. En moderne processor har tit så meget fart på at det reelt er cache og båndbredde betragtninger der begrænser.
#35
Der er naturligvis en effekt.
viser en effekt 0-50% afhængig af N.
Men det er ret nemt at komme i problemer med regnenøjagtigheden med 32 bit FP. Det klassiske eksempel er varians beregning med et gennemløb.
Der er naturligvis en effekt.
#include <iostream>
#include <cstdlib>
#include <ctime>
using namespace std;
template <typename T, int N>
struct Test
{
static inline int Ix(int i, int j)
{
return i * N + j;
}
static void Run()
{
clock_t t1 = clock();
T *a = new T[N * N];
T *b = new T[N * N];
T *c = new T[N * N];
for(int i = 0; i < N; i++)
{
for(int j = 0; j < N; j++)
{
a[Ix(i, j)] = rand();
a[Ix(i, j)] /= RAND_MAX;
b[Ix(i, j)] = rand();
b[Ix(i, j)] /= RAND_MAX;
}
}
for(int i = 0; i < N; i++)
{
for(int j = 0; j < N; j++)
{
c[i * N + j] = 0;
for(int k = 0; k < N; k++)
{
c[Ix(i, j)] += a[Ix(i, k)] * b[Ix(k, j)];
}
}
}
delete[] a;
delete[] b;
delete[] c;
clock_t t2 = clock();
cout << sizeof(T) << " byte FP : " << (t2 - t1) << " clock ticks for dimension " << N << endl;
}
};
int main()
{
srand(1234567);
Test<float, 500>::Run();
Test<double, 500>::Run();
Test<float, 1000>::Run();
Test<double, 1000>::Run();
Test<float, 2000>::Run();
Test<double, 2000>::Run();
return 0;
}
viser en effekt 0-50% afhængig af N.
Men det er ret nemt at komme i problemer med regnenøjagtigheden med 32 bit FP. Det klassiske eksempel er varians beregning med et gennemløb.
#37 Aktiveringsfunktionen i neurale netværk kunne beregnes fint med float. Her er der tale om slag på tasken off, midt imellem eller on. Præcision er ligegyldig. Men så kunne man argumentere for at gå ned i endnu færre bit end 32-bit float.
RGB pixel værdier, audio samples, kunne være andre eksempler. Det er ikke altid at der er brug for en masse præcision.
RGB pixel værdier, audio samples, kunne være andre eksempler. Det er ikke altid at der er brug for en masse præcision.
#38
Ja. Men pas på.
Til ksræk og advarsel:
Ja. Men pas på.
Til ksræk og advarsel:
#include <stdio.h>
#include <math.h>
static float stddev1(float xf[], int n)
{
int i;
float sum, mean, stddev;
sum = 0;
for(i = 0; i < n; i++)
{
sum = sum + xf[i];
}
mean = sum / n;
sum = 0;
for(i = 0; i < n; i++)
{
sum = sum + (xf[i] - mean) * (xf[i] - mean);
}
stddev = sqrt(sum / n);
return stddev;
}
static float stddev2(float xf[], int n)
{
int i;
float sum1, sum2, mean, stddev;
sum1 = 0;
sum2 = 0;
for(i = 0; i < n; i++)
{
sum1 = sum1 + xf[i];
sum2 = sum2 + xf[i] * xf[i];
}
mean = sum1 / n;
stddev = sqrt(sum2 / n - mean * mean);
return stddev;
}
static void test(float xf[], int n)
{
printf("%.1f = %.1f\n", stddev1(xf, n), stddev2(xf, n));
}
int main()
{
float xf1[] = { 1, 2, 3 };
float xf2[] = { 101, 102, 103 };
float xf3[] = { 10001, 10002, 10003 };
test(xf1, 3);
test(xf2, 3);
test(xf3, 3);
return 0;
}
#40 Du beregner standard afvigelsen på to måder. Med to passes hvor der først beregnes gennemsnit, eller i ét pass med summen og kvadrat summen. Sidstnævnte går galt i tredje test pga. floats begrænsede opløsning.
Meget interessant.
Men double er bare et par niveaer væk fra samme problem:
int main()
{
double xf3[] = { 10001, 10002, 10003 };
double xf4[] = { 100001, 100002, 100003 };
double xf5[] = { 1000001, 1000002, 1000003 };
double xf6[] = { 10000001, 10000002, 10000003 };
double xf7[] = { 100000001, 100000002, 100000003 };
double xf8[] = { 1000000001, 1000000002, 1000000003 };
test(xf3, 3); //0.816 = 0.816
test(xf4, 3); //0.816 = 0.816
test(xf5, 3); //0.816 = 0.816
test(xf6, 3); //0.816 = 0.820
test(xf7, 3); //0.816 = 0.000
test(xf8, 3); //0.816 = 0.000
return 0;
}
Her er output fra float eksperimentet for the record:
test(xf1, 3); //0.816 = 0.816
test(xf2, 3); //0.816 = 0.817
test(xf3, 3); //0.816 = 0.000
(jeg har sat lidt ekstra decimaler på i print)
Meget interessant.
Men double er bare et par niveaer væk fra samme problem:
int main()
{
double xf3[] = { 10001, 10002, 10003 };
double xf4[] = { 100001, 100002, 100003 };
double xf5[] = { 1000001, 1000002, 1000003 };
double xf6[] = { 10000001, 10000002, 10000003 };
double xf7[] = { 100000001, 100000002, 100000003 };
double xf8[] = { 1000000001, 1000000002, 1000000003 };
test(xf3, 3); //0.816 = 0.816
test(xf4, 3); //0.816 = 0.816
test(xf5, 3); //0.816 = 0.816
test(xf6, 3); //0.816 = 0.820
test(xf7, 3); //0.816 = 0.000
test(xf8, 3); //0.816 = 0.000
return 0;
}
Her er output fra float eksperimentet for the record:
test(xf1, 3); //0.816 = 0.816
test(xf2, 3); //0.816 = 0.817
test(xf3, 3); //0.816 = 0.000
(jeg har sat lidt ekstra decimaler på i print)
#42
Det er et eksempel på en udregning hvor det går galt allerede når tal når halvdelen af FP præcisionen.
Mekanismen er helt den samme uanset 32, 64 eller 128 bit.
Og det kritiske er usikkeheden på virkelige tal i input.
32 bit FP => 7 cifre => går galt 4 cifre
64 bit FP => 15 cifre => går galt 8 cifre
128 bit FP => 33 cifre => går galt 17 cifre
Det vil være uhyre sjældent at man kan måle med 8 cifres nøjagtighed.
Men med omhyggelighed vil man godt kunne måle med 4 cifres nøjagtighed.
Det er et eksempel på en udregning hvor det går galt allerede når tal når halvdelen af FP præcisionen.
Mekanismen er helt den samme uanset 32, 64 eller 128 bit.
Og det kritiske er usikkeheden på virkelige tal i input.
32 bit FP => 7 cifre => går galt 4 cifre
64 bit FP => 15 cifre => går galt 8 cifre
128 bit FP => 33 cifre => går galt 17 cifre
Det vil være uhyre sjældent at man kan måle med 8 cifres nøjagtighed.
Men med omhyggelighed vil man godt kunne måle med 4 cifres nøjagtighed.
#43 Ja. Der er jo helt op til use casen. Jeg har lige for 30 min siden implementeret en algoritme der reelt kun har brug for et par decimalers nøjagtighed, og kun laver max 10 regneoperationer. Men den kører kun en gang i sekundet eller noget i den stil. så jeg tog bare en double... Frås! :)
larsp (44) skrev:
Ja. Der er jo helt op til use casen.
Ja. Men det er værd at bemærke at forskellene i algoritmers følsomhed er langt større end forskellene i måleusikkerhed.
larsp (44) skrev:
Jeg har lige for 30 min siden implementeret en algoritme der reelt kun har brug for et par decimalers nøjagtighed, og kun laver max 10 regneoperationer. Men den kører kun en gang i sekundet eller noget i den stil. så jeg tog bare en double... Frås! :)
Ligesom alle andre.
IEEE har faktisk defineret 16 bit FP populært kaldet half precision FP.
Men meget lille interesse fra CPU producenterne. ARM har vistnok lidt support (support for konvertering fra og til).
Men soft er der muligheder: http://half.sourceforge.net/
larsp (38) skrev:RGB pixel værdier, audio samples, kunne være andre eksempler. Det er ikke altid at der er brug for en masse præcision.
Lige netop med lyd kan man også rende ind i problemer hvis man f.eks. laver et peaking eq filter med + gain ved 20 Hz. Det resulterer i filterkoefficienter der ligger tæt på 1, så afrundingsfejl bliver hørbare i form af støj. I yderste konsekvens kan det gøre et ellers stabilt filter ustabilt.
Ifht. performance så kan det også gøre også en stor forskel om compileren er sat op til at bruge fast eller precise floats:
https://software.intel.com/content/www/us/en/devel...
Deaktivering af denormal numbers gør også en stor forskel på performance, dog mister man muligheden for at arbejde med meget små tal:
https://software.intel.com/content/www/us/en/devel...
Gode pointer. Vidste ikke at visse floating point tal (denormal numbers) kunne medføre hundredevis af ekstra CPU cycles.
Når det kommer til stykke bør man vel skelne mellem den floating point præcision der bruges til beregninger hvor f.eks. et ekstremt peaking filter har brug for meget høj opløsning.
.. og så den opløsning der er nødvendig når beregningerne er klaret og data skal gemmes eller sendes videre. Her kan man måske gå helt ned i half precision floats. De kan vel ses som en form for metode til data komprimering, da de ikke er praktiske at beregne med.
Når det kommer til stykke bør man vel skelne mellem den floating point præcision der bruges til beregninger hvor f.eks. et ekstremt peaking filter har brug for meget høj opløsning.
.. og så den opløsning der er nødvendig når beregningerne er klaret og data skal gemmes eller sendes videre. Her kan man måske gå helt ned i half precision floats. De kan vel ses som en form for metode til data komprimering, da de ikke er praktiske at beregne med.
larsp (47) skrev:Gode pointer. Vidste ikke at visse floating point tal (denormal numbers) kunne medføre hundredevis af ekstra CPU cycles.
Når det kommer til stykke bør man vel skelne mellem den floating point præcision der bruges til beregninger hvor f.eks. et ekstremt peaking filter har brug for meget høj opløsning.
.. og så den opløsning der er nødvendig når beregningerne er klaret og data skal gemmes eller sendes videre. Her kan man måske gå helt ned i half precision floats. De kan vel ses som en form for metode til data komprimering, da de ikke er praktiske at beregne med.
Moderne CPUer er ret effektive til at håndtere 32 bit FP, f.eks. ved brug af SSE på x86 som giver mulighed for at udføre en operation på 4x 32bit FP tal parallelt. Men der er god mening i at bruge double precision floats internt i et filter og så bruge single alle de ikke-kritiske steder.
#denormaliserede
IEEE denormaliserede FP er en håbløs "design by committee" feature.
VAX hidden bit FP var langt simplere.
Det er muligt på x86-64 at undgå performance tab ved at bede CPU betragte dem som 0.
Men man skal gøre sig klart at man allerede var i problemer. Denormaliserede FP har færre cifres præcision end normaliserede FP. Så ikke nok med at beregningerne var langsomme - de var formentligt også unøjagtige.
IEEE denormaliserede FP er en håbløs "design by committee" feature.
VAX hidden bit FP var langt simplere.
Det er muligt på x86-64 at undgå performance tab ved at bede CPU betragte dem som 0.
Men man skal gøre sig klart at man allerede var i problemer. Denormaliserede FP har færre cifres præcision end normaliserede FP. Så ikke nok med at beregningerne var langsomme - de var formentligt også unøjagtige.
demolition (46) skrev:
Ifht. performance så kan det også gøre også en stor forskel om compileren er sat op til at bruge fast eller precise floats:
https://software.intel.com/content/www/us/en/devel...
Ja.
Det var Intel compilere.
GCC:
https://gcc.gnu.org/wiki/FloatingPointMath
LLVM:
https://llvm.org/docs/LangRef.html#fast-math-flags
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund