microsoft windows 10 opsplitte opdele opdateringer sikkerhedsopdateringer funktioner / Newz.dk

Microsoft

Microsoft dropper 32bit Win10

- Via Bleeping Computer - , indsendt af arne_v

Microsoft vil begynde en langsom udfasning af 32bit applikationer i Windows 10, begyndende i maj måned.

Ændringen skal ske efter udgivelsen af version 2004 af Windows 10 – herefter vil der ikke være 32bit-versioner af Windows 10 installationer tilgængelig. Det bliver med andre ord herfra kun muligt at installere Windows 10, i 64bit udgaven.

Brugere med ældre hardware eller med eksisterende installationer, bliver i denne omgang ikke berørt og der vil være begrænset support af disse installationer og hardware, i noget tid endnu.

Statistikken fra spilplatformen Steam, som Bleeping Computer har listet, viser at meget få computere i dag bruger Windows 10 32 bit – ud af alle Windows computere er det 0,2% der benytter Windows 10 32bit, mens 86,02% benytter 64bit udgaven af samme.

Apple udførte den samme overgang, med introduktionen af OSX Catalina (udgivet oktober 2019) – hvormed Mojave blev det sidste MacOS der understøtter 32bit.

 





Gå til bund
Gravatar #1 - jespersen.thomas
15. maj 2020 07:15
Ok den Steam statistik. Jeg kan ikke forestille mig mange gamere der bruger systemer der ikke kan køre 64-bit.
Gravatar #2 - Ni
15. maj 2020 07:51
#1 Nej, jeg tænker også mest, at det er produktionscomputere som køre 32bit

Det er skægt, at MS ikke selv har en statistik over, hvor stor en del af deres installationsbase som køre 32bit
Gravatar #3 - Jelle
15. maj 2020 09:38
#2 Det har de skam. De har bare ikke offentliggjort den, så vi må ty til Steam for at vurdere hvor stor (eller rettere:lille) impact det forventes at have.
Gravatar #4 - larsp
15. maj 2020 10:18
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?
Gravatar #5 - arne_v
15. maj 2020 11:13
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.
Gravatar #6 - MiKr
15. maj 2020 11:26
#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.
Gravatar #7 - kblood
15. maj 2020 15:55
#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.
Gravatar #8 - kblood
15. maj 2020 15:56
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.
Gravatar #9 - CBM
15. maj 2020 18:06
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
Gravatar #10 - brostenen
15. maj 2020 20:59
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.
Gravatar #11 - arne_v
15. maj 2020 22:40
#10

128 bit er nødvendig når 64 bit ikke længere er nok for programmer.

Nuværende x86-64 understøtter kun 256 TB virtual address space, men arkitekturen kan understøtte op til 16 EB virtual address space.

Jeg tror det varer lidt inden behovet opstår.
Gravatar #12 - arne_v
15. maj 2020 22:43
#10

Med hensyn til skift fra 32 til 64 bit, så er server jo langt foran PC med hensyn til memory behov.

Og når man bruger samme CPU arkitektur til server og PC så vil man have en del år hvor PC ikke bruger CPU'en fuldt ud.
Gravatar #13 - Chucara
15. maj 2020 22:54
#9: Æh nej. 128 bit betyder at der er dobbelt så meget bits at flippe. Det ville bare gøre det hele marginalt langsommere, ikke hurtigere. Jeg tillader mig her at antage at du ikke har 4 petabyte RAM i din maskine :)
Gravatar #14 - kblood
15. maj 2020 23:14
#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.
Gravatar #15 - arne_v
16. maj 2020 00:32
#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

Gravatar #16 - demolition
16. maj 2020 14:18
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.
Gravatar #17 - larsp
16. maj 2020 15:36
16-bit adresserum er fint. 32-bit er stadig ødsel i de dybeste lag af forståelse i min hjerne.

64 bit? Hvor herre bevares. Men sådan går det jo når script kiddies laver electron apps.
Gravatar #18 - arne_v
16. maj 2020 16:22
#17

Da 64 bit kom frem i 90'erne var en af driverne bag skiftet behov fra Oracle DB.


Gravatar #19 - larsp
16. maj 2020 17:50
#18 Database servere med kæmpe kapacitet, yes, det giver mening.

Men til en smartphone der kan vise emails og tage billeder og dele på facebook? 64 bit og 12 GB ram? Det er bindegalt.

Jeg klager ikke, jeg er bare forundret :)
Gravatar #20 - kblood
17. maj 2020 02:52
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å.
Gravatar #21 - larsp
17. maj 2020 09:18
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.
Gravatar #22 - larsp
17. maj 2020 09:27
#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.
Gravatar #23 - arne_v
17. maj 2020 12:46
#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.
Gravatar #24 - arne_v
17. maj 2020 12:55
#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.
Gravatar #25 - arne_v
17. maj 2020 12:58
#22

Floating point er en helt anden boldgade.

64 bit FP er det normale og 32 bit FP er undtagelsen.

Hvis man skal sætte det på spidsen så har 32 bit FP været forældet i 25 år.
Gravatar #26 - arne_v
17. maj 2020 13:07
#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

Gravatar #27 - arne_v
17. maj 2020 13:08
#23

Nogle sprog har iøvrigt næsten uendeligt størrelse integers.
Gravatar #28 - kblood
17. maj 2020 13:20
#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
Gravatar #29 - arne_v
17. maj 2020 13:29
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.
Gravatar #30 - arne_v
17. maj 2020 13:35
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.
Gravatar #31 - larsp
17. maj 2020 13:35
@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.
Gravatar #32 - arne_v
17. maj 2020 13:39
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.
Gravatar #33 - arne_v
17. maj 2020 13:43
#31

Der var engang hvor memory og diskplads var vanvittigt dyrt, så man måtte spare på pladsen.

Årstal med 2 cifre. Singe precision fremfor double precision FP. 16 bit integer fremfor 32 bit integer.

Men tiderne har ændret sig.
Gravatar #34 - Chucara
18. maj 2020 06:11
#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.

Gravatar #35 - larsp
18. maj 2020 07:31
#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.
Gravatar #36 - arne_v
18. maj 2020 11:52
#34

Decimal er faktisk standardiseret siden 2008 udgaven af IEEE 754.

Og understøttes af Power og z CPU'er.

(bemærk at der er er så nogle små forskelle mellem .NET decimal og IEEE decimal128)

Gravatar #37 - arne_v
18. maj 2020 16:54
#35

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.
Gravatar #38 - larsp
19. maj 2020 07:18
#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.
Gravatar #39 - Chucara
19. maj 2020 10:12
#36: Det var derfor, jeg skrev mainstream CPUer ;)
Gravatar #40 - arne_v
19. maj 2020 17:53
#38

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;
}
Gravatar #41 - larsp
20. maj 2020 06:14
-
Gravatar #42 - larsp
20. maj 2020 06:18
#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)
Gravatar #43 - arne_v
20. maj 2020 11:36
#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.

Gravatar #44 - larsp
20. maj 2020 12:20
#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! :)
Gravatar #45 - arne_v
20. maj 2020 16:46
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/



Gravatar #46 - demolition
21. maj 2020 05:02
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...
Gravatar #47 - larsp
21. maj 2020 07:51
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.
Gravatar #48 - demolition
21. maj 2020 11:39
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.
Gravatar #49 - arne_v
21. maj 2020 14:29
#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.
Gravatar #50 - arne_v
21. maj 2020 15:55
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
Gå til top

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.

Opret Bruger Login