Warum hat die Dezimalarithmetik VisiCalc verlangsamt?
Es gibt einen ausgezeichneten Artikel über VisiCalc , der alle Details darüber enthält, was passiert ist und warum. Er ist sehr zu empfehlen, wenn Sie sich für diesen Teil der Computerhistorie interessieren. Ich habe diesen Abschnitt gelesen:
Im Mittelpunkt von VisiCalc stehen Zahlen. Eine der ersten Entscheidungen, die wir getroffen haben, war die Verwendung von Dezimalarithmetik, damit die Fehler dieselben sind, die ein Buchhalter mit einem Dezimalrechner sehen würde. Im Nachhinein war dies eine schlechte Entscheidung, da sich die Leute als egal herausstellten und die Berechnungen dadurch viel langsamer wurden, als sie es in Binärform gewesen wären.
Und nickend, ja, die Nachfolger von VisiCalc sind in dieser Hinsicht zurückgefallen; Bis heute ist das Internet voller Fragen und Antworten darüber, warum Excel Anomalien mit Zahlen wie 0,1 und binären Gleitkommazahlen aufweist, die nicht den Erwartungen entsprechen. VisiCalc hätte zu diesem Zeitpunkt wirklich eine Werbekampagne starten sollen, in der auf die ...
... Warte eine Minute. Kühlschranklogik.
Berechnungen viel langsamer gemacht?
VisiCalc wurde auf dem 6502 geschrieben, der BCD-Arithmetik unterstützt. Sie müssen nur den Dezimalmodus aktivieren, und die CPU fügt BCD-Bytes mit genau der gleichen Geschwindigkeit hinzu wie binäre Bytes.
Die meisten Zahlen in einer Tabelle sind jedoch einfach, wenn sie in Dezimalzahlen ausgedrückt werden. Eine Zahl wie 1234.56 benötigt drei Bytes in BCD, wobei acht Bytes in binärem Gleitkomma mit doppelter Genauigkeit benötigt würden. Das spart nicht nur Speicher, sondern spart auch Zeit, wenn Ihre Berechnungsroutinen (die in der Software ausgeführt werden müssen - die Maschine hatte keine FPU) die Gelegenheit zum vorzeitigen Beenden nutzen. Die Berechnung von Zahlen, die normalerweise in Tabellenkalkulationen vorkommen, sollte daher schneller in Dezimalzahlen erfolgen.
Und kleine Tabellenkalkulationen verbringen viel Zeit damit, die Anzeige zu aktualisieren. Das Konvertieren einer Zahl von der internen Darstellung in ASCII zur Anzeige ist wesentlich schneller, wenn die interne Darstellung dezimal war.
Warum hat er gesagt, dass Dezimalzahlen die Berechnungen verlangsamen?
Antworten
Eine Zahl wie 1234.56 benötigt drei Bytes in BCD, wobei acht Bytes in binärem Gleitkomma mit doppelter Genauigkeit benötigt würden.
Im Allgemeinen ist dies nicht der Fall. Wenn Sie eine Datenbankfelddefinition mit insgesamt 6 Stellen haben, 4 vor der Dezimalstelle, 2 nach nur positiven Zahlen, dann können Sie 1234,56 in 3 8-Bit-BCD-Bytes darstellen lassen. Aber wenn, wie es typischer ist:
- Sie erlauben jeder Zahl, viel mehr Ziffern zu haben - z. B. sind 8 Ziffern ein Minimum, nur um bis zu 1.000.000 US-Dollar pro Penny zuzulassen (aber nicht einzuschließen). Typischer wären 10 oder 12 oder mehr.
- Sie erlauben eine unterschiedliche Anzahl von Stellen nach der Dezimalstelle in verschiedenen Feldern - z. B. 2 für US-amerikanische (und viele andere) Währungswerte, aber 6 oder mehr für Stückkosten (z. B. Kosten für kWh für Stromrechnungen).
- Sie erlauben negative Zahlen.
Dann gehen Sie sehr schnell über 3 Bytes hinaus. 8 Bytes werden zu einem vernünftigen Minimum .
Selbst für die Speicherung (ohne Berücksichtigung der Berechnung) funktionieren 3 Bytes für die 6-stellige Zahl nicht, da irgendwo definiert werden muss, dass diese Zelle eine positive 3-Byte-Zahl mit dem Dezimalpunkt vor den letzten 2 Ziffern hat. Das dauert ein Byte, also sind wir jetzt bei 4 Bytes.
Darüber hinaus wird der Code, der für die zusätzlichen Manipulationen benötigt wird (numerische Formate mit unterschiedlicher Länge codieren / dekodieren), in den sehr begrenzten 64-KB- Code + Daten verarbeitet, die auf typischen 8-Bit-Systemen verfügbar sind. Es könnte leicht der Fall sein, dass der Platz, der durch Variieren der Größe (und hoffentlich im Durchschnitt viel kleiner) numerischer Zellen in einer Tabelle für Werte eingespart wird, normalerweise durch den zusätzlichen Code aufgewogen wird, der im Speicher benötigt wird, um die Anzeige, Manipulation und Berechnung dieser Zahlen zu unterstützen .
6502 unterstützte SIMPLE BCD-Arithmetik. Ich würde wetten, dass die VisiCalc-Leute diese Funktion am Ende nicht einmal genutzt haben und das Ganze von Grund auf neu geschrieben haben. Es gibt nicht nur Addition und Subtraktion, sondern auch Multiplikation und Division, und VisiCalc war Gleitkomma (nur Dezimalgleitkomma).
Der Grund, warum die Dezimalmathematik langsamer ist, ist einfach der gleiche, warum "niemand" heute Dezimalmathematik verwendet, sondern binäre Mathematik. Bei der binären Mathematik ist jedes Bit eine Ziffer. Bei der Dezimalrechnung sind 4 Bits eine Ziffer. Mehr Speicher für weniger Präzision, die Mathematik ist nur langsamer, es ist nur viel mehr Arbeit für den Computer, sogar für den 6502 mit aufkommender Unterstützung.
(Und ja, Dezimalmathematik wird überall an verschiedenen Orten verwendet, aber es ist die Ausnahme, nicht die Regel.)
Da Dezimaloperationen selbst beim 6502 langsamer sind, gibt es Prozessorunterstützung für 8-Bit-BCD-Addition und -Subtraktion, aber das war's.
Der Code für die Dezimalmultiplikation, Division, Verschiebung, Gleitkomma-Normalisierung und möglicherweise sogar für den Vergleich ist etwas größer und langsamer als bei Binärdaten.
Zum Beispiel erfordern Verschiebungs- und Subtraktions-Teilungsroutinen eine Unterroutine, um den Wert zu halbieren. In der Binärdatei ist dies trivial. Am Beispiel eines 8-Bit-Werts:
LSR
Im Dezimalmodus ist es ungefähr so (mit freundlicher Genehmigung von "Multiplizieren und Dividieren im Dezimalmodus" ):
ROR
N08 PHP
BPL HALF2
SEC
SBC #$30
HALF2 BIT N08
BEQ HALF3
SEC
SBC #3
HALF3 PLP
Code wie dieser würde sich in der inneren Schleife einer Dezimalteilungsroutine befinden. Die Geschwindigkeitsstrafe ist erheblich.