nVidia GT300 (40nm) DirectX 11 [Speku-, News- & Diskussionsthread] [Part 1.1]

Status
Für weitere Antworten geschlossen.
Wundert mich ja eigentlich etwas das bisher niemand mit FPGAs bei GPUs arbeitet afaik. Optimaler ginge es ja eigentlich nicht mehr.

mr. dude schrieb:
Was nVidia hier mit Modularität genau meint, erschliesst sich mir nicht wirklich. Ich würde es einfach mal als PR unkommentiert stehen lassen. Gerade GPUs sind schon seit jeher recht modular aufgebaut. Wirklich neu ist das nicht. Und diese Vorgehensweise mit separaten SP und DP Einheiten nutzt ja ansonsten auch keiner der anderen GPU Hersteller, afaik.

Scheinbar ist es so. Etweder hat NV etwas bisher nicht bekanntes entwickelt oder es ist bloße PR schon eigesetzter Techniken.
Ich weiß nicht ob sich überhaupt bisher jemand mit der DP Fähigkeit von GPUs auseinandergesetzt hat, GPU Computing kommt ja gerade erst in Mode und erst durch die gestiegene Flexibilität in den letzten Jahren ist es überhaupt ein Thema.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Scheinbar ist es so. Etweder hat NV etwas bisher nicht bekanntes entwickelt oder es ist bloße PR schon eigesetzter Techniken.
Ich weiß nicht ob sich überhaupt bisher jemand mit der DP Fähigkeit von GPUs auseinandergesetzt hat, GPU Computing kommt ja gerade erst in Mode und erst durch die gestiegene Flexibilität in den letzten Jahren ist es überhaupt ein Thema.

GPGPU ist seit den ersten Tagen des G80 in der Presse... und wurde vor dem G80 auch schon mehr oder weniger viel durch die Presse geschickt...

Das sind immerhin schon 3 Jahre, aber passiert ist sogut wie noch gar nix... Vor allem im Endkunden Markt ;)


Das Problem ansich ist scheinbar, das eben die DP Funktion nur in sehr speziellen Einsatzgebieten gefragt ist, für den normalen Enduser eher nutzlos, ebenso für den Profibereich (also den Bereich mit den Quadro Karten)
Wenn man so will, für den kompletten Markt, der aktuell von GPUs gebrauch macht.

Im HPC Bereich muss sich das ganze erstmal etablieren und es müssen Anwendungen geschaffen werden...
 
Wundert mich ja eigentlich etwas das bisher niemand mit FPGAs bei GPUs arbeitet afaik. Optimaler ginge es ja eigentlich nicht mehr.
FPGA ist seit dem Wegfall von T&L hin zu universelleren Shadern ein zentraler Bestandteil von GPUs. Das ist mittlerweile wie lange her? Ein Jahrzehnt?
Es ist unwahrscheinlich, dass nVidia hier irgendwas entwickelt hat, auf das bisher noch niemand gekommen ist.
Aber ich merke schon, da ist bei dir der Wunsch der Vater des Gedanken. :) Oder um es mal mit einem Zitat auszudrücken, das Naheliegendste ist meistens auch das Wahrscheinlichste. Also PR, viel heisse Luft um nichts.

Ich weiß nicht ob sich überhaupt bisher jemand mit der DP Fähigkeit von GPUs auseinandergesetzt hat
DP bot schon der RV670. Das ist mittlerweile auch schon wieder 2 Jahre her. Die Technik dahinter wird also schon länger in den Entwicklungslaboren erforscht.
Mehr oder weniger in den Kinderschuhen steckt vielmehr GPU basiertes DP Computing, gerade was HPC und Supercomputer betrifft. Dafür muss erstmal eine entsprechende Infrastruktur geschaffen werden, sowohl was Hardware als auch Software betrifft.
 
mr.dude schrieb:
FPGA ist seit dem Wegfall von T&L hin zu universelleren Shadern ein zentraler Bestandteil von GPUs. Das ist mittlerweile wie lange her? Ein Jahrzehnt?
Es ist unwahrscheinlich, dass nVidia hier irgendwas entwickelt hat, auf das bisher noch niemand gekommen ist.

Ist mir ehrlich gesagt neu, aber man lernt ja nie aus.

mr.dude schrieb:
Aber ich merke schon, da ist bei dir der Wunsch der Vater des Gedanken. Oder um es mal mit einem Zitat auszudrücken, das Naheliegendste ist meistens auch das Wahrscheinlichste. Also PR, viel heisse Luft um nichts.

Tja, wahrscheinlich, die Erwartungen an NV sind hoch.

mr.dude schrieb:
DP bot schon der RV670. Das ist mittlerweile auch schon wieder 2 Jahre her. Die Technik dahinter wird also schon länger in den Entwicklungslaboren erforscht.
Mehr oder weniger in den Kinderschuhen steckt vielmehr GPU basiertes DP Computing, gerade was HPC und Supercomputer betrifft. Dafür muss erstmal eine entsprechende Infrastruktur geschaffen werden, sowohl was Hardware als auch Software betrifft.

Darafauf wollte ich nicht hinaus. Es gibt ja immer mal wieder Rechenzentren die auf extremen Lösungen basieren, zB damals die Flugsimulatoren von Boeing in denen die VSA100 in 32facher Ausführung Arbeiteten. Für solche Berreiche gibt es ja immer mal wieder Hersteller die solche Lösungen liefern. Ich hätte es jetzt also nicht für abwegig gehalten wenn man schon früher auf Basis von Unified Shaderchips von ATI oder NV eine solche Lösung für HPC angeboten hätte.
 
Zuletzt bearbeitet:
Man soviel Technikgeschnacke auf den letzten Seiten es wird Zeit, dass mal ein Bench rauskommt oder wenigstens ein fake Bench. Macht ja garkeinen Spass mehr hier reinzugucken. ^^
 
wenns danach ginge müssten die ganzen letzten paar seiten alle in den Technikthread verschoben werden. Aber wenns der Mod mitmacht, dann ists für uns ja nicht von Belangen.
 
Ist ja nicht schlimm nur raucht mir auch schon der Kopf von dem ganzen, was hier steht. :d
 
ja, ist ein guter Standard hier. Finde ich auch gut, denn so ist man wenigstens anständig informiert. ...Luxx :hail:
 
Also sprechen wir von FMA Einheiten die pro Taktzyklus eine Addition und eine Multiplikation durchführen können. Allerdings nach IEEE 754 Standart mit doppelter Precision als 8byte Zahl. Was also bei der Berechnung durch die späte Rundung zu viel Aufwand führt und zu längeren Zahlenwerten aber auch zu höhere Genauigkeit der Werte.

Aufwand ist ja relativ, kostet halt den Platz, um so breite Datenpfade und ALUs zu implementieren, nicht wahr :fresse:

Neurosphere schrieb:
Hätte ich also die Aufgabe 2^1/2 würde ich bei einfacher Genauigkeit einen Wert mit knapp 40 Nachkommastellen und in doppelter Prezision mit rund 300 Nachkommastellen.

Ich hätte also zum einen das Problem der längeren/aufwändigeren Berechnung und zum anderen der größeren Zahlenwerte die ich händeln muss.

Was für eine Aufgabe? Was ist an 2^1/2 denn eine Aufgabe? 2^1/2 lässt sich doch schon mit IEEE-754r (16 Bit) mehr als exakt darstellen (würde ja sogar mit einem Bit VZ, zwei Bit Exponent und ohne Mantissenbits gehen :d).

An der Stelle kommt mir spontan die Frage in den Sinn, obs auch Gleitkommazahlen mit einem Exponentenbit gibt und ob da der Bias ernsthaft 1 ist.

Neurosphere schrieb:
Wenn ich also nV wäre und die Fähigkeit meines Chips in DP steigere, steigere ich doch eigentlich auch automatisch die Leistung in SP, zumindest in der puren Berechnung der Zahlenwerte.

Mr.Malik schrieb:
Würde vermuten, dass es also durch die Verbreiterung auf 32-Bit diesen
Performanceboost bei DP gibt.

Ich weiß nicht, ob ich da gerade auf dem Schlauch stehe, aber wieso soll die Verbreiterung auf INT32 bei MUL etwas mit dem FP64-Durchsatz zu tun haben? Ich denke mal, Neurosphere liegt da schon ganz richtig, und wenn DP wirklich 1/2 von SP ist, riecht das doch einfach ganz gewaltig nach schlichter paarweiser Kopplung der ALUs. Setzt wohl eine gewisse Modularität beim Scheduling voraus (oder der Compiler macht hier seinen Job), aber ATi machts ja (fast) genauso.

Mr.Malik schrieb:

Klar, ich besorg mir gleich eine Hornbrille, damits authentisch wirkt. :d

fdsonne schrieb:
Aber ich könnte mir vorstellen, das man native DP Einheiten auch mit SP Aufgaben füttern kann, sollte theoretisch ja kein Problem darstellen... und somit die Leistung erhöhen.

Theoretisch schon, ist eigentlich nur eine Compilerfrage. Aber wer würde sowas in Zeiten von VLIW noch machen (falls einer auf die fixe Idee kommt, ja, ich weiß, dass es hier nicht um Instruktionen geht ;) )? Da laufen ja überwiegend nur Zero Bits durch das Schaltnetz. Das kann ich mir nicht vorstellen.

fdsonne schrieb:
Bei AMD arbeitet doch seit dem R600 eine komplette "5D ALU" an einem DP Operation, was bedeutet, das man nur ein fünftel der SP Leistung für DP hat...
Bei NV geschieht dies doch derzeit durch mehrere Durchläuft durch die SP Einheiten + das bisschen, was die nativen DP Einheiten können, soweit ich weis...

Das wäre mir neu, nach meinem Kenntnisstand sind die Transcendentals in jeder Vektor-ALU nicht DP-fähig (d.h. nicht für DP-Berechnungen nutzbar). Oder hab ich das falsch verstanden und die Einheiten sind zwar DP-fähig, aber es gibt nur keine DP für sine/cosine/sqrt/etc (Transcendentals eben)?

Neurosphere schrieb:
Wundert mich ja eigentlich etwas das bisher niemand mit FPGAs bei GPUs arbeitet afaik. Optimaler ginge es ja eigentlich nicht mehr.

mr.dude schrieb:
FPGA ist seit dem Wegfall von T&L hin zu universelleren Shadern ein zentraler Bestandteil von GPUs. Das ist mittlerweile wie lange her? Ein Jahrzehnt?

Ich wüsste nicht, dass jemand auf die Idee kommen sollte, FPGAs in GPUs einzubauen. Das ist ja so ziemlich das genaue Gegenteil eines ASIC. Und es hat auch einen Grund, warum man das nicht nutzt: Performance. Custom-made logic ist deutlich schneller als ein FPGA. Das sag ich aus zwei Gründen, erstens, weil das Board der ersten Revision beim Open Graphics Project auf einem FPGA basiert und ich mich gut an das Performance-Geschrei erinnern kann, was dadurch aufkam, und zweitens, weil ich das selber schon ausprobieren durfte (natürlich nicht an einer GPU, sondern an einem einfachen RISC-Mikroprozessor). Auch wüsste ich nicht, welche logischen Funktionen einer GPU man so gut minimieren kann, dass es sich lohnt (Primimplikanten haben die alle recht viele) und die vor allem auch noch so reichlich vorhanden sind, dass man dafür ein FPGA nutzen wöllte. Ist ja letztlich auch eine Platzfrage, denn wenn man nicht alle Knoten und Ports am FPGA belegt, verschwendet man selbigen nur.
Ich lass mich aber gern eines besseren belehren, wenn du konkrete Beispiele hast, wo ein FPGA in einer GPU eine Rolle spielt. Ich kanns mir nur wie gesagt nicht vorstellen.

Verschiebung in den Technikthread ist übrigens keine schlechte Idee, andererseits passt das ja auch prima hierhin. Sind eben mal gehaltvollere Spekus als "Ich will ne GTX380!!!!111einself".
 
Zuletzt bearbeitet:
Ich wüsste nicht, dass jemand auf die Idee kommen sollte, FPGAs in GPUs einzubauen.
Das wollte ich damit auch nicht sagen. Die Formulierung ist missverständlich. Ich wollte eher zum Ausdruck bringen, dass FPGA seit der Einführung von universellen Shadern bei GPUs ein Thema ist. Also die Forschung diesbezüglich, beides zu verbinden, exisitiert sicherlich nicht erst seit gestern. Es ist daher unwahrscheinlich, dass nVidia plötzlich jetzt mit irgendwelchen unbekannten Neuerungen daherkommt, auf die bisher noch niemand gekommen ist.
Inwiefern FPGA bereits jetzt oder in Zukunft in GPUs genutzt wird, ist wieder ein anderes Thema. Das ist aber der falsche Thread, um das zu diskutieren.
 
Lord schrieb:
Was für eine Aufgabe? Was ist an 2^1/2 denn eine Aufgabe? 2^1/2 lässt sich doch schon mit IEEE-754r (16 Bit) mehr als exakt darstellen (würde ja sogar mit einem Bit VZ, zwei Bit Exponent und ohne Mantissenbits gehen ).

Ist mir als erstes für ne unendliche Zahl eingefallen.

Lord schrieb:
Klar, ich besorg mir gleich eine Hornbrille, damits authentisch wirkt.

Yeah :d

Und mal zu den FPGAs, um zu wissen wie optimal oder eben nicht sie sind fehlt mir halt das tiefgreifende Wissen in der Materie, aber der Grundgedanke dahinter ist das ich durch sie eine sehr hohe Rechenleistung auf kleinstem Raum erreiche und durch die problemlose Parallelisierung von Aufgaben in einem FPGA sie sich ja irgendwo doch als GPU anbieten, bzw als ein Bestandteil. Auf der Hot-Chips Konferenz wurden ja einige interessante FPGA Modelle vorgestellt (not GPU!). Auch der Platzbedarf ist ja eigentlich recht gering. War nur eine Idee nebenbei und das man sie heute schon in GPUs einsetzen würde wie dude meinte wage ich irgendwie zu bezweifeln.
 
Zuletzt bearbeitet:
Ist mir als erstes für ne unendliche Zahl eigefallen.

Uha, da hatte ich wohl irgendeinen Denkaussetzer, das stimmt natürlich. Bin irgendwie von 2^(-1) ausgegangen :fresse: Asche auf mein Haupt. Aber wie kamst du dann auf 40 bzw 300 Dezimalstellen?

Zum FPGA, meiner Ansicht nach ist eines der obersten Kriterien dort die Flexibilität, die man gewinnt. Man kann eben die Schaltung nachträglich rekonfigurieren, ohne sie neu zu designen. Das geht natürlich auf Kosten der Effizienz (eine LUT ist nunmal weder platzsparend noch schnell). Ich kann mir vorstellen, dass man FPGAs vielleicht benutzt, um Designs vorher auf einer logischen Ebene auf Korrektheit zu testen, weil das vergleichsweise einfach geht und man sich eben sparen kann, das Design schon umzusetzen, um dann aufwändig von Hand Fehler auszumerzen. Aber in fertigen GPUs? Eher nicht.
 
Zuletzt bearbeitet:
Laut wiki ist die höchst mögliche Zahl in DP 1.79769 * 10^308 und für SP 3,4 * 10^38. Obwohl ich da auch noch nicht wirklich dahinter gekommen bin da für den Exponenten in SP zB 8bit zur verfügung stehen was auf 2^8 Möglichkeiten für den Exponenten schließen würde also 256 mögliche. Allerdings befindet sich das ganze ja im Hexadezimalen System weshalb ich nicht weiß wie es dort ausschaut. Ich gehe einfach mal davon aus das das jemand geschrieben hat der sich damit auskennt und übernehme das einfach mal.
 
eine LUT ist nunmal weder platzsparend noch schnell.
Kommt drauf an. Platzsparend ist sie sicherlich nie, schnell kann sie aber durchaus sein.

@Neurosphere
Du musst immer zwischen Darstellung und eigentlichem Wert unterscheiden. Die Wertebereiche, die du angegeben hast, sind in dezimaler Darstellung. Der eigentliche Wert hat hingegen keine Darstellung bzw basiert auf dem binären System.
Die Mantisse repräsentiert sozusagen immer den Teil vor dem Komma. Ist der Exponent positiv, wird die Mantisse entsprechend viele binäre Stellen nach links verschoben. Ist er negativ, nach rechts.
Und genau hier sollte auch die Bedeutung der 8 Bit bei SP klar werden. Damit ist ein Exponent von 127 positiv und negativ möglich. Was von binär in eine dezimale Darstellung eben in -38 bis +38 resultiert. Mal vereinfacht ausgedrückt, bei Basis 10 muss man eben weniger nach links und rechts schieben als bei Basis 2, um den gleichen Wert darzustellen.
Das gleiche gilt für DP, nur dass dort Mantisse und Exponent breiter sind.
 
Zuletzt bearbeitet:
Kommt drauf an. Platzsparend ist sie sicherlich nie, schnell kann sie aber durchaus sein.

LUT?

@Neurosphere
Du musst immer zwischen Darstellung und eigentlichem Wert unterscheiden. Die Wertebereiche, die du angegeben hast, sind in dezimaler Darstellung. Der eigentliche Wert hat hingegen keine Darstellung bzw basiert auf dem binären System.
Die Mantisse repräsentiert sozusagen immer den Teil vor dem Komma. Ist der Exponent positiv, wird die Mantisse entsprechend viele binäre Stellen nach links verschoben. Ist er negativ, nach rechts.
Und genau hier sollte auch die Bedeutung der 8 Bit bei SP klar werden. Damit ist ein Exponent von 127 positiv und negativ möglich. Was von binär in eine dezimale Darstellung eben in -38 bis +38 resultiert. Mal vereinfacht ausgedrückt, bei Basis 10 muss man eben weniger nach links und rechts schieben als bei Basis 2, um den gleichen Wert darzustellen.
Das gleiche gilt für DP, nur dass dort Mantisse und Exponent breiter sind.

Danke ;)
 
ich wär dafür die diskussion mal auzugliedern, ich glaub ausser den diskuteeuren steigt da eh keiner durch....
 
Natürlich. Sofern wir über das gleiche sprechen, also Lookup Tables. Oder war mit der Abkürzung etwas anderes gemeint?

Naja, aber Speicherplatz ist doch auf einer GPU nicht gerade exorbitant vorhanden. Allerdings geht es in einer LUT ja gerade darum das sie schnell ist.

ich wär dafür die diskussion mal auzugliedern, ich glaub ausser den diskuteeuren steigt da eh keiner durch....

Naja, wir sind durchs FPGA etwas abgedriftet. Soll Lord entscheiden ob ers verschiebt...mom, ich rette das Thema, NV verwendet bestimmt FPGAs im neuen CHIP :d;)
 
Die Mantisse repräsentiert sozusagen immer den Teil vor dem Komma. Ist der Exponent positiv, wird die Mantisse entsprechend viele binäre Stellen nach links verschoben. Ist er negativ, nach rechts.
Und genau hier sollte auch die Bedeutung der 8 Bit bei SP klar werden. Damit ist ein Exponent von 127 positiv und negativ möglich. Was von binär in eine dezimale Darstellung eben in -38 bis +38 resultiert. Mal vereinfacht ausgedrückt, bei Basis 10 muss man eben weniger nach links und rechts schieben als bei Basis 2, um den gleichen Wert darzustellen.
Das gleiche gilt für DP, nur dass dort Mantisse und Exponent breiter sind.

Nein, die Mantisse repräsentiert immer den Teil nach dem Komma. ;) Wenn die Zahl als Festkommazahl gegeben ist, wird so lange geshiftet, bis die linkeste (höchstwertigste) 1 vor dem Komma steht und genau dann wird der Nachkommaanteil als Mantisse gespeichert (soweit eben Platz ist), die Anzahl an Shifts als Exponent (der noch um den Bias verschoben wird, weil negative Exponenten im Gleitkommaformat nicht zulässig sind).
8 Bit Exponent gehen übrigens von -128 bis +127, das ist nicht symmetrisch. Ist ja auch logisch, schließlich werden 256 Werte ermöglicht.
Die größtmögliche Zahl in DP besteht folglich aus 53 Einsen (52 nach dem Komma), bei der dann der Dezimalpunkt um 1024 Stellen nach rechts verschoben wird (2^(11-1)).

Neurosphere schrieb:

Ja, LookUp Table ist gemeint. :)
 
Zuletzt bearbeitet:
so hab meine geforce...äh fermi GTX 380 nun mal getestet und ich muss sagen ...der wahnsinn!

locker 20% schneller als die ATI
 
mmmkay, geforce ... :fresse:
 
Now while all of that is interesting, it does point out one thing. The GT300 appears to have been pushed back from the original production date. We have heard that originally GT300 was supposed to launch around the end of October. Now the time for the public launch is sometime in the middle of November. This could be the reason for the early demo of the Fermi Architecture instead of an actual launch.

Launch mitte November....naja wer es glaubt....aber ich hoffe das die Jungs mal gas geben , ich will ne neue graka nur bevor ich nicht weiss was die NV kann will ich mir keine kaufen:fresse:

http://www.tweaktown.com/news/13299/nvidia_partners_order_large_numbers_of_fermi_gpus/index.html
 
nehmen wir an, die schaffen das den 27.11 (ThanksGiving) den sie sich als Releasetermin vorgenommen haben einzuhalten. Wird dann nicht erst USA und Japan beglückt und dann wir!? War doch immer so, oder irre ich? Ergo mitte Dezember für uns zu haben ?!
 
Naja, aber Speicherplatz ist doch auf einer GPU nicht gerade exorbitant vorhanden. Allerdings geht es in einer LUT ja gerade darum das sie schnell ist.
Ich verstehe gerade nicht, was du genau willst. Inwiefern widerspricht das meiner Aussage?

Nein, die Mantisse repräsentiert immer den Teil nach dem Komma.
Stimmt auch nicht ganz. ;) Ok, wenn es schon so pedantisch sein muss, die Mantisse beginnt an der Stelle vor dem Komma. Allerdings ist dieses Bit implizit. Gespeichert wird letztendlich nur, was danach kommt.

weil negative Exponenten im Gleitkommaformat nicht zulässig sind.
Allerdings sollte man bedenken, dass der Exponent mit Offset 127 codiert ist.

8 Bit Exponent gehen übrigens von -128 bis +127, das ist nicht symmetrisch.
Ich wollte es nicht noch weiter verkomplizieren. Wie der Wertebereich von 8 Bit signed Werten im Zweierkomplement ausschaut, wird wohl jeder wissen, der sich schon mal mit dem binären System befasst hat. Exakt geht der Exponent übrigens von -126 bis +127.
 
Stimmt auch nicht ganz. ;) Ok, wenn es schon so pedantisch sein muss, die Mantisse beginnt an der Stelle vor dem Komma. Allerdings ist dieses Bit implizit. Gespeichert wird letztendlich nur, was danach kommt.

Da konntest du es ohne Krümelkackerei nicht lassen, was? :) Das, was als Mantisse gespeichert wird, sind die Nachkommabits, wie ich oben schrieb.

mr.dude schrieb:
Allerdings sollte man bedenken, dass der Exponent mit Offset 127 codiert ist.

Klugscheißerfight, Teil 2, der "Offset" heißt offiziell Bias. Und beschreibt genau das, was ich sage, nämlich, dass negative Exponenten nicht zulässig sind. Genau deswegen gibts ja den Bias.

mr.dude schrieb:
Ich wollte es nicht noch weiter verkomplizieren. Wie der Wertebereich von 8 Bit signed Werten im Zweierkomplement ausschaut, wird wohl jeder wissen, der sich schon mal mit dem binären System befasst hat. Exakt geht der Exponent übrigens von -126 bis +127.

Dass du es nicht weiter verkomplizieren wolltest, kannst du dir nach der Sache oben doch schenken :d Abgesehen davon, dass Korrektheit ja wohl vor Einfachheit geht, insbesondere, weil mir gerade auch nicht klar ist, warum eine korrekte Bereichsangabe es komplizierter macht. Dass es noch Infinity, NaN etc. gibt, ist wohl klar, aber Fakt ist, dass 8 Bit Exponent erstmal die Werte von -128 bis +127 codieren.

Ich schlage aber trotz allem vor, dass wir das Feld jetzt wieder den kauffreudigen Spekulanten überlassen, weil die Zahlendarstellung in Rechnersystemen dann doch relativ weit weg vom GT300 ist.
 
Zuletzt bearbeitet:
Da konntest du es ohne Krümelkackerei nicht lassen, was? :) Das, was als Mantisse gespeichert wird, sind die Nachkommabits, wie ich oben schrieb.



Klugscheißerfight, Teil 2, der "Offset" heißt offiziell Bias. Und beschreibt genau das, was ich sage, nämlich, dass negative Exponenten nicht zulässig sind. Genau deswegen gibts ja den Bias.



Dass du es nicht weiter verkomplizieren wolltest, kannst du dir nach der Sache oben doch schenken :d Abgesehen davon, dass Korrektheit ja wohl vor Einfachheit geht, insbesondere, weil mir gerade auch nicht klar ist, warum eine korrekte Bereichsangabe es komplizierter macht. Dass es noch Infinity, NaN etc. gibt, ist wohl klar, aber Fakt ist, dass 8 Bit Exponent erstmal die Werte von -128 bis +127 codieren.

Ich schlage aber trotz allem vor, dass wir das Feld jetzt wieder den kauffreudigen Spekulanten überlassen, weil die Zahlendarstellung in Rechnersystemen dann doch relativ weit weg vom GT300 ist.

:stupid:, na endlich....
 
Status
Für weitere Antworten geschlossen.

Ähnliche Themen

Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh