Vinnaren i pepparkakshustävlingen!
  • 1
  • 2
2022-06-16, 02:46
  #13
Medlem
Om man läser om vad som skrivs om ämnet så har nog TS missuppfattat vad dessa forskare skriver.
I själva verket handlar det om att ibland undvika floats helt och hållet, således så skrivs en hel del problem om så att man bara använder integers eftersom integer-aritmetik är mycket snabbare än motsvarande floats.
Eller så kan man använda speciella datatyper med fixerad decimalpunkt.
Eller till exempel BCD, Binary Coded Decimal, som tar 4 bitar för varje siffra 0-9, en omsorgsfullt designad sådan kod kan räkna exakt rätt i större delen av fallen, och i en mindre del ge rätt så små räknefel.
Tror faktiskt att Excel använer den datatypen.

Ett annat angreppssätt är att räkna om datasettet till att bli ett linjärt problem istället. Alla flyttal logaritmerades istället, och då blir det huvudsakligen addition och subtraktion som blir de flesta numeriska operationerna. Alltså mycket snabbare.

Fast då fick man hitta på något sätt att beteckna noll, 0, eftersom logaritmen för noll är -oändlighten.
Redan hos 1950-talets tidiga datapionjärer så sysslade man med detta för att förenkla beräkningarna.

Mycket riktigt så hittar man flera ställen där de refererar till att den förlust av precision som sker med att bara deklarera 16-bits floats att den kan komma att bita dig rejält i röven i slutändan ändå.

Ytterligare ett annat angreppssätt är att utöka precisionen till 128-bit, dvs long double, och räkna om allting och jämföra med resultatet vid 64-bit, och man kan där uppskatta hur stort beräkningsfelet blir.

Området är mycket bredare än att bara handla om 16-bits Minifloats.
En annan möjlighet är att använda i princip oändlig precision och det finns en hel del C++ libs som förmår räkna numeriska tal med en hög förinställd precision

Men tex i grafikberäkningar där man ska vrida perspektivet eller objekt i det tänkta 3D-rummet genom att göra koordinattransformeringar med tex matrisoperationer så räcker det inte alltid
ens med 32-bit floats.

Sedan så finns det sådana problem där man kan använda bitoperationerna & | osv för att göra jämförelser, dessa är förstås snabba som blixten.

Artiklarna som tar upp problemet förbiser problemen med många operationer efter varandra.
Det är viktigt att läsa vad de påstår, de påstår inte att 16-bits floats skulle vara användbara överallt.
Snarare tvärtom.
Dessa problem förstås bättre av dem som sysslat med till exempel numerisk analys och linjära/icke-linjära ekvationssystem som löses på dator.
Och inte sådana som enbart har IT-utbildning.

C++ har en klass BIGNUM som kan räkna med godtycklig precision och kan dessutom räkna rätt, och med korrekt avrundning.

Det finns andra rätt så udda knep, till exempel om man har talbasen 36, där tecknena 0-9, A-Z representeras talen 0-36, och man kunnat ur dessa konstruera andra slags floats som inte representeras av IEEE 754.
Sedan kan man rentav designa datatyper som kan representera bråktal exakt.
Alltså rationella tal
Citera
2022-06-16, 06:59
  #14
Medlem
Offices avatar
Citat:
Ursprungligen postat av NegerStryparen
Om man läser om vad som skrivs om ämnet så har nog TS missuppfattat vad dessa forskare skriver.
I själva verket handlar det om att ibland undvika floats helt och hållet, således så skrivs en hel del problem om så att man bara använder integers eftersom integer-aritmetik är mycket snabbare än motsvarande floats.
Eller så kan man använda speciella datatyper med fixerad decimalpunkt.
Eller till exempel BCD, Binary Coded Decimal, som tar 4 bitar för varje siffra 0-9, en omsorgsfullt designad sådan kod kan räkna exakt rätt i större delen av fallen, och i en mindre del ge rätt så små räknefel.
Tror faktiskt att Excel använer den datatypen.

Ett annat angreppssätt är att räkna om datasettet till att bli ett linjärt problem istället. Alla flyttal logaritmerades istället, och då blir det huvudsakligen addition och subtraktion som blir de flesta numeriska operationerna. Alltså mycket snabbare.

Fast då fick man hitta på något sätt att beteckna noll, 0, eftersom logaritmen för noll är -oändlighten.
Redan hos 1950-talets tidiga datapionjärer så sysslade man med detta för att förenkla beräkningarna.

Mycket riktigt så hittar man flera ställen där de refererar till att den förlust av precision som sker med att bara deklarera 16-bits floats att den kan komma att bita dig rejält i röven i slutändan ändå.

Ytterligare ett annat angreppssätt är att utöka precisionen till 128-bit, dvs long double, och räkna om allting och jämföra med resultatet vid 64-bit, och man kan där uppskatta hur stort beräkningsfelet blir.

Området är mycket bredare än att bara handla om 16-bits Minifloats.
En annan möjlighet är att använda i princip oändlig precision och det finns en hel del C++ libs som förmår räkna numeriska tal med en hög förinställd precision

Men tex i grafikberäkningar där man ska vrida perspektivet eller objekt i det tänkta 3D-rummet genom att göra koordinattransformeringar med tex matrisoperationer så räcker det inte alltid
ens med 32-bit floats.

Sedan så finns det sådana problem där man kan använda bitoperationerna & | osv för att göra jämförelser, dessa är förstås snabba som blixten.

Artiklarna som tar upp problemet förbiser problemen med många operationer efter varandra.
Det är viktigt att läsa vad de påstår, de påstår inte att 16-bits floats skulle vara användbara överallt.
Snarare tvärtom.
Dessa problem förstås bättre av dem som sysslat med till exempel numerisk analys och linjära/icke-linjära ekvationssystem som löses på dator.
Och inte sådana som enbart har IT-utbildning.

C++ har en klass BIGNUM som kan räkna med godtycklig precision och kan dessutom räkna rätt, och med korrekt avrundning.

Det finns andra rätt så udda knep, till exempel om man har talbasen 36, där tecknena 0-9, A-Z representeras talen 0-36, och man kunnat ur dessa konstruera andra slags floats som inte representeras av IEEE 754.
Sedan kan man rentav designa datatyper som kan representera bråktal exakt.
Alltså rationella tal
Du verkar ju ha bra koll på mycket men läser du någon annans inlägg någon gång?

Det finns säkert tillfällen när dina superspecialdatatyper kan bli användbara men jag tycker det är rätt uppenbart att TS har sett specifikationer på grafikkort som säger att lägre precision är ger fler beräkningar per tidsenhet.

Och man behöver inte vara nån övermänniska för att hitta information om detta:
https://keras.io/api/mixed_precision/
Citat:
Using mixed precision can improve performance by more than 3 times on modern GPUs and 60% on TPUs.

Today, most models use the float32 dtype, which takes 32 bits of memory. However, there are two lower-precision dtypes, float16 and bfloat16, each which take 16 bits of memory instead. Modern accelerators like Google TPUs and NVIDIA GPUs can run operations faster in the 16-bit dtypes, as they have specialized hardware to run 16-bit computations and 16-bit dtypes can be read from memory faster. Therefore, these lower-precision dtypes should be used whenever possible on those devices.
Citera
2022-06-16, 19:56
  #15
Medlem
Citat:
Ursprungligen postat av Office
Du verkar ju ha bra koll på mycket men läser du någon annans inlägg någon gång?

Det finns säkert tillfällen när dina superspecialdatatyper kan bli användbara men jag tycker det är rätt uppenbart att TS har sett specifikationer på grafikkort som säger att lägre precision är ger fler beräkningar per tidsenhet.

Och man behöver inte vara nån övermänniska för att hitta information om detta:
https://keras.io/api/mixed_precision/

Äh, det verkar vara gamla metoder som man bara har gett nya namn. Det nya är att en hel del av dessa operationer kan genomföras parallellt. Men det kunde man redan tex på 1950-talet också.
Fast då med manuella eller mekaniska räknemaskiner förstås.
Men visst finns det ett tänkbart försäljningsknep att när man räknar GFlops för 64 bits double,
så med 16-bits blir siffran 4 ggr bättre förstås
Förutsatt att man bortser från förlusten i precision i varje beräkningssteg.
Det är ju intressant att GPU-tillverkarna gjort det möjligt att adressera datat på det viset,
helt klart.
Detta finns förklarat i många kurser i till exempel numerisk analys.
Böckerna Numerical Recipes in C och Numerical Recipes in Fortran tar upp många av dessa problem, tex felpropagering och trunkeringsförluster mm.
Till exempel om hur många databittar man bör ha i en float. Intels kretsar kör internt med 80 bittar vilket är 16 bittar fler än 64 bits, och håller nere sådana fenomen.
__________________
Senast redigerad av NegerStryparen 2022-06-16 kl. 20:24.
Citera
2022-06-17, 01:12
  #16
Medlem
Citat:
Ursprungligen postat av Office
Du verkar ju ha bra koll på mycket men läser du någon annans inlägg någon gång?

Det finns säkert tillfällen när dina superspecialdatatyper kan bli användbara men jag tycker det är rätt uppenbart att TS har sett specifikationer på grafikkort som säger att lägre precision är ger fler beräkningar per tidsenhet.

Och man behöver inte vara nån övermänniska för att hitta information om detta:
https://keras.io/api/mixed_precision/

Ska kanske förtydliga att uppgiften är helt korrekt. Men det är också ett försäljningsknep att säja att nästa veckas grafikkort är 4 ggr snabbare än denna veckas. Nu vet jag inte men skulle gissa att de kan vara optimerade för tex 32-bits float eller 64-bits float.

IEEE 754 är verkligen en genial bitrepresentation av ett flyttal, men det finns säkert ämnesområden/numeriska områden där andra talrepresentationer kan visa sig
mycket mera användbara.
Vetenskapligt sett så ville man väl ha minst 10 siffrors noggrannhet, och då duger inte float32.

Många vanliga kalkylatorer brukade ha BCD, Binary Coded Decimal även på decimalsiffrorna.
BCD ger dock en prestandaförlust jämfört med IEEE 754, men kommer inte ihåg hur stor den är.
Lagringsmässigt så ger den dock en förlust så stor som 37 %.
Ett av de effektivaste sätten att lagra decimaltalen är att lagra dem i 1024-bitars chunks, dvs 128 bytes åt gången. Det ger en förlust på bara 2 %.
Citera
2022-07-08, 22:16
  #17
Medlem
Citat:
Ursprungligen postat av Office
Mycket data -> Många operationer -> TS tänker att 16-bitars flyttalsprecision kommer öka prestandan? Är det verkligen så långsökt (även om trådtiteln kanske inte var så bra formulerad)?

Ja, det kan vara värt att undersöka: https://keras.io/api/mixed_precision/

Men det är inte det första man trixar med precis. Det är nog i ganska få fall en vanlig människa kommer få ut något betydande av att laborera med det där. Försök få till så att beräkningarna sker på GPU:n, då kan du träna stora modeller förvånansvärt snabbt.

Om många operationer måste göras efter varandra på samma data så är bfloat16s i extrem underkant. Kan du inte normalisera dina data kring tex bfloats16 så är det i princip inte ens lönt att försöka.
Men somliga typer av tex glesa matriser, med glesa menar jag att antalet element i matriserna som är lika med noll är många kan gå att normalisera kring tex integers, eller bfloat16s.

Även om det kan ge en stor prestandavinst så kan man tvingas att räkna om datasettet med högre precision, tex då framförallt doubles och se om hur stora felen är i resultatet.


Finns inget annat sätt än att köra om beräkningarna med högre precision. Har man förmånen att kunna använda ett optimiserat float-lib med godtycklig precision så kan man räkna om med successivt högre precision och se om resultatet konvergerar mot ett stadigt värde.
I så fall kan man anta att modellen är korrekt, dvs matematiskt korrekt.
Det blir bara ett sk induktivt bevis och man kan inte generellt anta att värdena alltid konvergerar.

Det är mera av ett försäljningsknep att säga att nyaste FPU/GPUn räknar 4 ggr fortare räknat i FLOPS,
med bfloat16s. Fast det är också sant,ingen tvekan om det.
GPUer är ju designade att kunna bearbeta stora datavolymer parallellt.

Det finns mycket att läsa om särskilda datatyper, till exempel en av de äldsta är COMPLEX i Fortran.
Och en av de mest använda är BCD, Binary Coded Decimal:
https://en.wikipedia.org/wiki/Binary-coded_decimal
En mycket utförlig artikel som där en byte, 8 bittar, kan representera två decimala siffror 0-9.

Vissa datorer har byggts med detta i åtanke, tex här:
https://en.wikipedia.org/wiki/Decimal_computer
Där talen representeras inte binärt i första hand, utan decimalt istället.

Intels x86/x87 FPU som sitter i alla PCs räknar med 80 bittar IEEE 754 flyttal internt. 80 bittar motsvarar cirka 18 decimala siffrors noggrannhet. Det ger i regel så bra utfall att 64-bitars double räknade i dessa FPUs att samtliga beräkningar lär bli korrekta.
Och designen på dessa är sådan att de kan konverteras till decimaltal i textformat och tillbaks igen till binärt format och att konversionen ger ett helt identiskt resultat.
En dold men mycket viktig styrka hos IEEE 754 formatet.

OBS - Kom ihåg att avrundning är inte normen i datasammanhang, utan normen är trunkering, resterande siffror kapas bara bort.

IEEE 754 formatet för flyttal är framtaget för att man ska kunna skicka data mellan olika system och vara säker på att konversionerna alltid ger helt identiskt resultat.

Här finns förklarat om 80 bits extended precision som används generellt i x87 FPUer:
https://en.wikipedia.org/wiki/Extended_precision

Och här förklaras beräkningar med helt godtycklig precision, som sätts typiskt vid runtime, vilket kan bli mycket värdefullt när man rör sig mycket nära noll, eller riskerar overflow/underflow:
https://en.wikipedia.org/wiki/Arbitr...ion_arithmetic
Dvs när man hamnar i matematikens riktiga tassemarker och man vanligen bara har matematikens standardmetoder att använda, som då inte är tillräckliga.

En hel del jobb ska också ha lagts ner för att skapa sådana libs för att hantera matriser, med de vanliga matrisoperationerna, invertering, multiplicering mm.

Som en avstickare till detta så finns det till exempel klassen "rationella tal" där vissa matrisoperationer kan göras helt exakt utan några avrundningsfel.
Dessa libs har av förklarliga skäl inte särskilt bra prestanda, men man får anta att resultatet är så viktigt att man struntar i prestandan.

Och tex spektraldata i IR, och Raman-spektrum plus många andra vågrörelsefenomen har beräknats med sådana speciallibs vilket också har bekräftat de experimentella data mot beräkningarna.
Man har också kontrollräknat fluid-dynamics modeller med sådana libs med utökad precision.
Ett svårt område när man börjar närma sig turbulenta områden.

AI skulle visst kunna användas för att bevisa/motbevisa till exempel Riemanns hypotes, men det blir bara då ett induktivt bevis. När man utökar datasettet så är det inte säkert att din AI kommer att ge rätt svar. AI blir tydligen inte bättre än dess indata, dvs datasettet. Om Riemanns hypotes här:
https://en.wikipedia.org/wiki/Riemann_hypothesis

Ett enkelt exempel vore att träna din AI på de 100 000 första primtalen och se om den kan gissa nästa primtal, dvs nr 100 001.
De flesta matematiker menar att det inte går, därför att det finns ingen funktion som kan generera primtal bara så där, utan de måste prövas ett och ett.
Det induktiva beviset är egentligen inte särskilt värdefullt, eftersom ett enda värde som inte är ett primtal skulle kullkasta AIns pålitlighet.
Och det är ett analytiskt bevis som vore den verkligt heliga Graalen.

Ett annat problem vore att träna en AI på decimalutvecklingen av talet Pi, om man matar den med
en miljon decimaler, och den kan leverera en ny miljon korrekta decimaler så vore det ett intressant
experiment i så fall ?

Vad är då kontentan av allt det här ?
- Tja 16 bits float, bfloats16 och AIs algoritm blir bara användbara så länge dess dynamiska sifferomfång inte överskrides eller underskrides.
- Dvs om sifferomfånget inte räcker så blir AIn oanvändbar, enligt devisen garbage in -> garbage out. Och man kan inte lita på vad den spottar ut.
Det är lite långt utanför vad trådens ämne är, men kan ändå vara av något intresse.

NB: x87 står för Intels FPU i Intels x86 CPU-generation. FPU = Floating Point Unit. Alla av dagens PCs har sådana. Gårdagens 386a hade dock i regel en separat FPU. Först med 486an kom bägge att integreras på samma chipp.
Citera
  • 1
  • 2

Stöd Flashback

Flashback finansieras genom donationer från våra medlemmar och besökare. Det är med hjälp av dig vi kan fortsätta erbjuda en fri samhällsdebatt. Tack för ditt stöd!

Stöd Flashback