Fidelity Elite Avant Garde Version 5
| Fidelity Elite Avant Garde Version 5 | ||
|---|---|---|
 C Foto von Sascha Warnemünde | ||
| Hersteller | Fidelity | |
| Markteinführung | 1990 | |
| CElo | 2050 | |
| Programmierer | Spracklen, Dan & Kate | |
| Prozessor | 2x 68000 | |
| Prozessortyp | 16 Bit | |
| Takt | 16 MHz | |
| RAM | 24 KB + 192 KB für Hash Tables | |
| ROM | 128 KB | |
| Bibliothek | 64.000 Positionen | |
| Einführungspreis | 2998 DM | |
| Rechentiefe | ||
| BT-2450 | - | |
| BT-2630 | - | |
| Colditz | - | |
| Verwandt | Fidelity Elite Avant Garde Version 2 | |
| Zugeingabe | Magnetsensoren | |
| Zugausgabe | 64 Feld-LEDs | |
| Display | 4-stellige 7-Segment Anzeige (LED) | |
| Stromversorgung | 9V~ / 1,1A | |
| Spielstufen | beliebig viele | |
| Maße | 45,5 x 48,5 x 4 cm; Spielfeld = 35,5 x 35,5 cm | |
| Sonstiges | ||
 | ||
1990 versuchte sich Fidelity an ihrem ersten und einzigen Mehrprozessorsystem, dem Elite Avant Garde Version 5. Der AVG V5 war der erste kommerzielle Schachcomputer mit 2 Prozessoren (Master/Slave-Prinzip). Das Programm basierte auf der Version 2, programmiert von Dan & Kathe Spracklen, allerdings mit etwas mehr Speicher versehen. Obwohl das Gerät über ein gutes Preis-/Leistungsniveau verfügte, wird jedoch angenommen, dass nur 50 Exemplare von der Version 5 gebaut wurden. Der Geschwindigkeitszuwachs wurde seitens Fidelity mit ~70% im Vergleich zur Version 2 angegeben, SSDF-Tests ergaben einen durchschnittlichen Geschwindigkeitszuwachs von 59%.
Dem Handbuch der Version 5 wurde ein Schreiben des Programmierer-Ehepaars zur Erläuterung der Funktionsweise des Dual-Systems beigefügt:
A letter from Dan and Kathe Spracklen to the Elite Avant-Garde Multi-Processor Owner
Congratulations on the purchase of your new Elite Avant-Garde Multi-Processor unit. It is our hope that you will thoroughly enjoy your new chess computer, which is one of the finest and strongest available. Because the multi-processor concept is new, we have included the following technical information regarding your unit.
NOTES ON MULTI-PROCESSING
If you play with Option E3 (described on the Instruction Manual Addendum Sheet), giving the same positions to the machine in both Single Processor Mode and Multi-Processor Mode, you may notice that the multi-processor is about 1.7 times as fast as the single processor. Perhaps you were wondering why it isn't twice as fast, since two processors are dividing up the work. Here are a few notes on how the multi-processing in your new Elite works.
TERMINOLOGY
Let's start with a little terminology. The processor that reads the keys and lights the LEDs on your Multi is called the master. The processor that helps out with the work of deciding on a move is called the slave. The process of deciding on a move is called a search. The job of the master is to divide up the search, sharing the work load with the slave and deciding on the best move. In most positions, there are many possible moves and the search must decide which is best.
DIVIDING UP THE MOVE LIST
A simple and obvious way of dividing up the search would be to give the master and the slave each a move to work on. As soon as one is finished, it could be given the next move on the list and so on, until all the moves have been examined. This method is feasible and gives typical speed-ups of about 1.4 times as fast as one processor working alone. Why so slow? The reason lies in the nature of the Alpha-Beta Search itself. Without going into a lengthy explanation of this process, suffice it to say that the first move examined normally lakes far longer than any of the other moves. The reason for this is that the first move establishes a score which can be used in the examina-tion of the other moves. When the move list is divided up, with both the master and the slave processing a different move, neither processor has an established score to work with and both are working on a long, difficult job. This means a lot of wasted effort and an overall result that is less than impressive. Nor would it help for the slave proces¬sor to sit idly by and wait for the master to finish the first move, which gives about the same results
PVS TREE SPLITTING
A far superior method of dividing up the search was presented by Professor Tony Marsland of the University of Alberta. His system, the one which we use, involves sharing the work of the long, difficult first move and then dividing up the rest of the moves. In this system, the master gives the slave assignments to search parts of the tree needed to complete the examination of the first move. The results are the impressive 1.7 speed-up that you see in your Multi.
WHERE THE REMAINING TIME IS LOST
There are four types of overhead in a multi-processor system. Each contributes to frustrate the attempt to reach the ideal speed-up of 2.0 times faster.
Communication Overhead
This is the time lost when the two processors must talk to each other and send messages back and forth to one another. One processor must compose messages telling the other about the direction or results of a search. The other processor must read and act on the messages. This is Communication Overhead.
Synchronization Overhead
To understand synchronization overhead, we must think about what happens when the search is nearly finished. Let's say the master is thinking about the last move, and the slave is thinking about the next-to-the-last move. One will finish before the other and will have nothing to do. The time one processor must sit idly by and wait for the other to finish a task is called Synchronization Overhead.
Divided Search Overhead
Think back to our discussion of dividing up the search using the you-take-one, I’ll-take-one approach. We said that the reason this method didn't work out so well was that the score established by examining the first move helps the rest of the moves go by faster. In fact, the better the score, the faster the rest of the moves go by. If, for example, our first move wins the enemy's Queen, we won't pay much attention to the rest of the moves that win less material or win nothing at all. If, on the other hand, our first move can only get us a little better position for some piece, we will have to look longer at the other possible moves. Usually, thanks to sorting, the first move on the list will be the best move. Sometimes it happens that a move further down on the list will turn out to be better. When that happens, the score established by the first move is not as helpful to the other moves as the score established by the new move. The processor that found the better move will begin at once to use the new score. The other processor is still stuck working with the old score until it finishes the move it is currently examining. The loss of efficiency due to the inability to promptly share score information is called Divided Search Overhead. An interesting side effect of Divided Search Overhead shows up in test results using composed chess problems. Usually, the idea behind using chess problems to compare the performance of different chess computers is that there is one clear-cut winning move, which is difficult to find. Testers can measure how long it takes a particu¬lar computer to spot the winning move, and that will often be a fair measure of how fast and powerful the chess computer is. By their very nature, however, chess problems involve positions where the best move is almost never the first move examined. Thus, they are positions which are artificially high in Divided Search Overhead. For this reason, when researchers want to test the performance of their tree-splitting problems, they are better advised to use positions taken at random from master games than to use these chess problems, since the chess problems will cause the multi-processor to appear worse than its true performance.
Split Hash Overhead
A hash table is a large area of memory into which a processor can store information it has gained during the search. If the same position turns up again, the processor can look up the result in the hash table instead of computing it all over again. Hash tables are particularly effective in the endgame, where they can make a search run many times as fast as a program without them. This is because repeated positions show up so often in the endgame. Split Hash Overhead comes about because each processor has its own private hash table. The master can't see into the slave's hash table, and the slave can't see into the master's hash table. If one gets a position that the other has already examined, it is stuck computing the result all over again. In the opening, the middlegame, and even the early endgame, this is not so serious. But when the number of pieces on the board drops way down, Split Hash Overhead can cripple the effectiveness of the multi-processor system. Occasionally, endgame positions having only Kings and Pawns may even take longer td run than they do on a single processor. It was the debilitating effect of Split Hash Overhead that put us into a scramble for a way around it. We held off the Sales Department with one arm, while we searched for and found a way around the problem: If splitting the hash tables was the problem, we reasoned, why not look into the idea of Shared Hash Tables. In this implementation, both processors would share the same hash table (the master's would be used, since it is larger). The draw¬back here is that the Communication Overhead would increase due to the necessity of passing hash table information back and forth. In the hardware configuration originally designed for the Multi, this approach would not be feasible, because the processors had no way to "tap one another on the shoulder" to say, "Give me some hash information" or "Here is some hash information for you". Each processor would waste so much time waiting for the other to get around to reading its request, that the resulting Communication Overhead would be worse than the Split Hash Overhead. This approach would be feasible if the hardware design were changed to allow the slave processor to interrupt the master to retrieve or store hash table information.
We fought for more time with the Marketing Department, and teamed up with the Engineering Department. Yes, with an ingeniously simple modification to the design, we could have interrupts! The rest, as they say, is history. Instead of slowing down in the endgame; your Multi now boosts speed-ups of 1.5 to 1.6!
Now you have an idea of what the software and hardware engineers at Fidelity Electronics have been doing to increase your enjoyment of computer chess. We hope you will enjoy the exciting advances in multi-processing as much as we have enjoyed bringing them to you.
Sincerely,
Dan and Kathe Spracklen
Fidelity Electronics International, Inc.
Fidelity Rückblick
von Larry Kaufman aus "Computer Chess Reports" 1990 / Vol. 1 No. 2
Das einzige neue Modell seit dem letzten Bericht ist Elite Version 5, der erste kommerzielle Schachcomputer mit zwei Prozessoren. Es hat Fidelitys Vorhersage von 80-90% Geschwindigkeitssteigerung gegenüber der Version 2 (der ansonsten ähnlichen Einzelprozessorversion) nicht ganz erfüllt: das Handbuch behauptet 70%, was ich als einen guten Durchschnitt in gewöhnlichen Stellungen bestätigen konnte, obwohl es von unter 40% bis über 100% variiert. Das Handbuch sagt, dass die Geschwindigkeitssteigerung in Endspielen und in taktischen Problemen geringer ist, und in der Tat zeigen Tests anhand einer großen Anzahl von Problemen durch den schwedischen Computerschachverband, dass die durchschnittliche Geschwindigkeitssteigerung 59% beträgt, während im Mattlösemodus die Geschwindigkeitssteigerung mehr ist, wenn es kein Matt gibt, fast 90%. Der Geschwindigkeitszuwachs ist fast, aber nicht völlig gleich - bis jetzt habe ich nur ein Problem beobachtet, bei dem der Dual einen zusätzlichen Ply benötigte, um die Lösung zu finden. Unter Berücksichtigung aller Faktoren entspricht dies wahrscheinlich einem kostenlosen Geschwindigkeitszuwachs von 3-2 gegenüber der Version 2, während ein weiterer Geschwindigkeitszuwachs von 3-2 für die Version 5 sie etwa gleichwertig mit der Version 6 machen würde. Es ist auffällig, dass die Preise für die verschiedenen Eliten (2, 5, 6, 9) nahezu proportional zu ihren effektiven Geschwindigkeiten sind. Dies scheint eine gute allgemeine Regel für die Bewertung eines Speed-Up zu sein. Da alle Elite mit Ausnahme der Geschwindigkeit gleich sind, sind die Geschwindigkeit und der Preis wirklich die einzigen Faktoren, die bei der Auswahl berücksichtigt werden müssen. Bei der Stärke sollte der Dual etwa in der Mitte zwischen den Versionen 2 und 6 liegen, etwa 40 Punkte von beiden entfernt, aber beim Preis liegt er näher an Version 2. Version 5 ist etwa so stark wie Mephisto Portorose 16 bit und etwas preiswerter, so dass sie als preiswert angesehen werden muss. Während also der Mach III und die Version 2 Elite ihre 2265 CRA-Bewertung nicht wirklich verdienen (basierend auf nachfolgenden Tests in vielen Ländern), verdient die Version 5 wahrscheinlich doch ihre 2265.
Bei meinem Gerät leuchteten gelegentlich unbesetzte Felder auf, was durch Rücknahme korrigiert werden konnte. Ich weiß nicht, ob dieses Problem auch bei anderen Geräten auftritt. Was die Lernfunktion betrifft, die allen Elite Geräten gemeinsam ist, so funktioniert sie, wenn man dieselbe Eröffnung wiederholt, aber manchmal braucht man viele Partien, um einen Fehler zu korrigieren. Alles in allem ist es eine nette Funktion, aber kein Allheilmittel. Alle neuen Elite Geräte (und Mach III & IV) spielen ein einigermaßen menschenähnliches, aggressives Spiel mit einem guten Endspiel. Die Eliten haben ein erweitertes Eröffnungsbuch, wählen aber selbst im Turnierbuchmodus gelegentlich eine schlechte Eröffnungsvariante.
Die Fähigkeit, lange Matts im tatsächlichen Spiel schnell zu erkennen, ist unübertroffen. Das positionelle Spiel ist nicht schlecht, aber meiner Meinung nach schlechter als das von Mephisto Portorose und Polgar. Die Taktik ist ausgezeichnet, das Endspiel ist für Computerverhältnisse gut. Die Eliten haben ein leicht verbessertes Programm gegenüber dem ursprünglichen Mach III, aber Version 2 scheint etwas langsamer zu laufen als das Designer Mach III.
Die verschiedenen Elite- und Mach-Geräte haben an einer Reihe von 40/2 (und 60/2) Menschenturnieren auf der ganzen Welt teilgenommen, daher hier eine kurze Zusammenfassung der Ergebnisse, die anhand der "Ply"-Tabelle auf USCF-Niveau angepasst wurden. Version 9 Elite erzielte 2388 in 7 Partien in Österreich und 2287 in 11 Partien in Frankreich, was einen Durchschnitt von 2326 in den 18 Partien ergibt. Version 6 und Mach IV erzielten 2378 in Schweden aus 19 Partien, 2284 in Holland aus 12, 2229 in Deutschland aus 5 und 2172 in Frankreich aus 9, was einen Durchschnitt von 2295 für die 45 Partien ergibt, was zusammen mit den 48 CRA-Partien zu 2325 einen Gesamtbetrag von 2311 für die 93 Partien ergibt. Für die Version 2 und Mach III haben wir 2268 für 25 Spiele in Schweden, 2200 für 35 in Holland, 2208 für 52 in Frankreich, 2124 für 33 Spiele in England und 2346 für 9 in Deutschland, was insgesamt 2206 für die 154 Spiele ergibt, was zusammen mit den 48 CRA-Spielen zu 2265, 2220 für die 202 Spiele ergibt. Die 6097 LA Version steht bei 2151 nach 75 Partien in England, Holland und Deutschland, während die Par Excellence (Designer 2100) ein Ergebnis von 2029 aus den drei großen Bewertungstests (USA, Großbritannien, Frankreich) aufweist. Alle fünf Ergebnisse liegen sehr nahe an den Schätzungen des CCR-Computers, was mich in meinem Vertrauen in unsere Methodik bestärkt.
Spracken Interview zur Version 5
DOPPELT HÄLT BESSER - DIE SPRACKLENS ÜBER MEHRPROZESSOR-SYSTEME
In PLY 1/90 berichten die Schweden über einen Geschwindigkeitsvergleich von 24 Teststellungen zwischen einem Elite Nr.2 und der Doppelprozessor-Version. Das Ergebnis: der Elite Nr.5 war einmal sogar um 8% langsamer, dann wieder bis zu 118% schneller als die Einprozessor-Version! (Der durchschnittliche Geschwindigkeitszuwachs betrug 59%.) Woher diese unterschiedlichen Werte? In der Bedienungsanleitung geben Dan und Kathe Spracklen selbst Antwort auf diese Frage. Wir haben ihre kurze Einführung in die Problematik der Mehrprozessor-Systeme so interessant gefunden, dass wir Fidelity um die Erlaubnis zum Nachdruck ersucht haben, die uns auch erteilt wurde. Wir danken der Firma für ihr Entgegenkommen.
Wenn Sie den Elite Nr.5 die gleichen Stellungen einmal im Einprozessor-Modus und dann im Doppelprozessor-Modus berechnen lassen, werden Sie feststellen, dass die Doppelprozessor-Version etwa 1,7mal so schnell ist die der Einfachprozessor. Vielleicht fragen Sie sich, warum sie nicht genau doppelt so schnell ist, wo sich doch zwei Prozessoren die Arbeit teilen. Daher wollen wir im Folgenden ein paar Anmerkungen zur Funktionsweise des neuen Elite-Doppelprozessors machen.
Beginnen wir mit ein wenig Terminologie! Der Prozessor, der bei einem Schachcomputer die Tasteneingaben registriert und die LEDs aufleuchten lässt, wird auch "Meister" genannt. Der Prozessor, der ihm bei. der Auswahl eines Zuges assistiert, heißt "Sklave". Den Vorgang, bei dem ein Zug ausgewählt wird, nennt man "Suche". Die Aufgabe des "Meisters" ist es, die Suche zu verteilen, d.h. die Sucharbeit gemeinsam mit dem "Sklaven" durchzuführen und über die Auswahl des besten Zuges zu entscheiden. In den meisten Stellungen gibt es viele mögliche Züge, und die suche muss darüber entscheiden, welcher der Beste ist.
Eine einfache und naheliegende Art, die Suche aufzuteilen, wäre, den Meister und den Sklaven an je einem Zug rechnen zu lassen. Sobald einer der beiden mit seinem Zug fertig ist, könnte er mit dem nächsten Zug auf der Liste beginnen und so weiter, bis alle Züge untersucht worden sind. Diese Methode ist durchaus anwendbar und ergibt eine Geschwindigkeitssteigerung von etwa 1,4 im Vergleich mit einem allein arbeitenden Prozessor. Warum so wenig? Der Grund liegt in der Natur des Alpha-Beta-Algorithmus. Ohne auf lange Erörterungen dieses Verfahrens einzugehen, kann man vereinfacht sagen, dass der erste Zug, der untersucht wird, wesentlich mehr Zeit in Anspruch nimmt als irgendeiner der übrigen Züge. Der Grund dafür ist, dass die Untersuchung des ersten Zuges eine Bewertung ergibt, die für die verkürzte Bearbeitung der folgenden Züge angewendet werden kann. Wenn die Zugliste aufgeteilt ist, wobei Meister und Sklave jeweils an verschiedenen Zügen arbeiten, dann fehlt beiden Prozessoren dieser Vergleichswert, und sie sind zu einer langen und schwierigen Arbeit verurteilt. Das bedeutet viel nutzlosen Aufwand, und das Endergebnis ist alles andere als beeindruckend. Es würde auch nichts helfen, den Sklaven untätig abwarten zu lassen, bis der Meister den ersten Zug durchgerechnet hat; das Ergebnis wäre in etwa das gleiche.
Eine weitaus effektivere Methode zur Aufteilung der Suche wurde von Professor Tony Marsland von der University of Alberta vorgeschlagen. Seine Methode, die auch von uns angewandt wird, beruht darauf, dass die Arbeit der langwierigen ersten Zugberechnung gemeinsam durchgeführt und erst dann der Rest der Züge aufgeteilt wird. Bei dieser Methode gibt der Meister dem Sklaven den Auftrag, gewisse Teile des Suchbaums zu bearbeiten, die für die Berechnung des ersten Zuges benötigt werden. Das Ergebnis ist die beachtliche Verschnellerung auf das 1,7-fache, die von unserem Doppelprozessor erreicht wird.
Unter "Overhead" versteht man den Zeit- bzw. Leistungsverlust, der bei der Anwendung eines bestimmten Programmierverfahrens auftritt. Bei einem Mehrfachprozessor-System gibt es vier Arten von "Overhead", die alle dazu beitragen, dass die ideale Geschwindigkeitssteigerung um den Faktor 2 nicht erreicht werden kann.
1. Bei der KOMMUNIKATION: Das ist die Zeit, die verloren geht, weil die beiden Prozessoren miteinander in Kontakt treten und Informationen austauschen müssen. Der eine Prozessor muss Meldungen erstellen, die den anderen über die Richtung und die Ergebnisse der Sucharbeit informieren sollen. Der andere Prozessor muss diese Meldungen entgegennehmen und darauf reagieren. Das nennt man den "COMMUNICATION OVERHEAD".
2. Bei der SYNCHRONISATION: Um diesen Begriff zu verstehen, müssen wir uns überlegen, was passiert, wenn die Suche beinahe zu Ende ist. Nehmen wir an, dass der Meister gerade über den letzten und der Sklave über den vorletzten Zug nachdenkt. Einer von den beiden wird früher fertig sein als der andere und danach "arbeitslos" sein. Die Zeit, die ein Prozessor untätig damit verbringen muss, auf den anderen zu warten, nennt man den "SYNCHRONIZATION OVERHEAD"
3. Bei der ARBEITSTEILUNG: Denken wir noch einmal an das, was wir über die Aufteilung der Sucharbeit nach der Methode "Du nimmst einen, ich nehm' einen" gesagt haben. Wir haben erwähnt, dass der Grund für die relativ geringe Effizienz dieser Methode darin liegt, dass die Bewertung, die bei der Untersuchung des ersten Zuges gefunden wird, die Bearbeitung der folgenden Züge beschleunigt. Je besser dieser erste Wert ist, desto schneller werden die anderen Züge abgearbeitet. Wenn z.B._ unser erster Zug die Dame des Gegners gewinnt, brauchen wir uns nicht lange mit den übrigen Zügen aufzuhalten, die entweder weniger Material oder gar keines gewinnen. Wenn hingegen unser erster Zug nur dazu führt, dass eine Figur ein wenig besser positioniert wird, dann müssen wir uns ausführlicher mit den anderen Zugmöglichkeiten befassen.
Infolge der ständigen Sortierung der Zugliste ist der erste Zug in vielen Fällen auch der beste. Manchmal kommt es aber vor, dass ein Zug, der auf der Liste weiter hinten steht, sich als besser erweist. Wenn das geschieht, ist die Bewertung, die im ersten Zug gefunden wurde, für die Bearbeitung der weiteren Züge weniger nützlich als die Bewertung des neuen Zuges. Der Prozessor, der den besseren Zug gefunden hat, wird daher sofort mit der neuen Bewertung weiterarbeiten. Der andere Prozessor muss hingegen mit dem alten Wert weitermachen, bis er mit der Bearbeitung des laufenden Zuges fertig ist. Der Leistungsverlust, der dadurch entsteht, dass die neue Bewertung nicht sofort beiden Prozessoren zur Verfügung steht, wird als "DIVIDED SEARCH OVERHEAD" bezeichnet.
Ein interessanter Nebeneffekt dieses Overheads zeigt sich bei Tests, die auf dem Lösen von Mattaufgaben beruhen. Der Grundgedanke bei der Verwendung von Mattproblemen zur Messung der Leistung von Schachcomputern ist, daß es einen eindeutigen, aber schwer zu findenden Gewinnzug gibt. Der Tester kann die Zeit messen, die der Computer braucht, um den Gewinnzug zu finden, und erhält dadurch einen meist recht vernünftigen Maßstab dafür, wie schnell und effizient der Schachcomputer arbeitet. Schachprobleme bestehen jedoch naturgemäß aus Stellungen, bei denen der beste Zug fast nie mit dem ersten untersuchten Zug übereinstimmt. Es sind daher Positionen mit künstlich erhöhtem Arbeitsteilungs-Overhead! Aus diesem Grund sollten Programmierer, die die Leistungsfähigkeit ihrer geteilten Suche testen wollen, besser beliebige Stellungen aus Meisterpartien verwenden als mit Mattproblemen zu arbeiten, bei denen sich der Mehrfachprozessor nicht von seiner besten Seite zeigt.
4. Bei der Aufteilung der HASH TABLES: eine Hash Table ist ein großer Speicherbereich, in dem ein Prozessor Informationen ablegen kann, die er während des Suchvorgangs gewonnen hat. Wenn die gleiche Stellung in einer anderen Variante wiederauftaucht, kann der Prozessor das Ergebnis in der Hash Table nachschlagen, statt mit der Berechnung von vorne beginnen zu müssen. Hash Tables sind besonders in Endspielen wirksam, wo die Suche mit ihrer Hilfe um ein Vielfaches schneller abläuft als ohne sie. Der Grund dafür ist, dass im Endspiel besonders oft Stellungswiederholungen auftreten. Der „SPLIT HASH OVERHEAD“ entsteht dadurch, dass jeder Prozessor seine eigene Hash Table hat. Der Meister kann nicht in die Tabelle des Sklaven schauen und der Sklave nicht in die des Meisters. Wenn einer von beiden daher eine Stellung erreicht, die in der Hash Table des anderen bereits gespeichert ist, muss er dennoch mit der Berechnung von vorne beginnen. In der Eröffnung, dem Mittelspiel und sogar dem frühen Endspiel macht das keinen entscheidenden Unterschied aus. Wenn aber die Anzahl der Figuren auf dem Brett stark reduziert ist, kann der Hash-Table-Overhead die Wirksamkeit eines Mehrfachprozessor-Systems drastisch verringern. In manchen Fällen brauchen Doppelprozessor-Systeme für Bauernendspiele sogar länger als Einfachprozessoren!
Eben diese lähmende Auswirkung des SPLIT TADLE OVERHEAD hat uns dazu veranlasst, nach Leibeskräften nach einem Ausweg zu suchen. Während wir uns die Verkaufsabteilung mit einem Arm vom Leibe hielten, suchten und fanden wir eine Lösung: wenn die Aufteilung der Hash Tables das Problem verursacht, so überlegten wir, warum dann nicht mit GEMEINSAMEN Hash Tables arbeiten? In dieser Ausführung würde nur eine einzige Tabelle verwendet werden (und zwar die des Meisters, weil sie größer ist). Der Nachteil dabei wäre ein erhöhter Kommunikations-Overhead, weil die beiden Prozessoren mehr Informationen über die Hash-Tables austauschen müssten. In der Hardware-Konfiguration, die ursprünglich für den Doppelprozessor vorgesehen war, wäre diese Methode nicht anwendbar gewesen, weil keiner der beiden Prozessoren die Möglichkeit hatte, dem anderen sozusagen "auf die Schulter zu klopfen" und ihm zu sagen: "Ich brauche Informationen über die Hash Tables" oder "Ich habe Informationen über die Hash Tables für dich". Jeder Prozessor hätte so viel Zeit damit verschwendet, darauf zu warten, dass der andere seine Aufforderung zur Kenntnis nimmt, dass der dadurch entstehende Kommunikations-Overhead schlimmer gewesen wäre als der durch die geteilten Hash Tables verursachte. Die Methode könnte aber funktionieren, wenn der Sklave eine Möglichkeit hätte, den Meister jederzeit durch einen "Interrupt" zu unterbrechen, um Hash-Tables-Informationen abzurufen oder zu speichern.
Während wir mit der Vertriebsabteilung um Terminaufschub kämpften, setzten wir uns mit der Technischen Abteilung zusammen. Ja, durch eine genial einfache Modifizierung des Designs würde es uns möglich sein, Interrupts zu verwenden! Wie man so sagt: the rest is history! Statt im Endspiel langsamer zu werden, kann der Doppelprozessor nunmehr stolz auf eine Verschnellerung um den Faktor 1,5 bis 1,6 verweisen.
Jetzt haben Sie eine Vorstellung davon, wie intensiv die Soft- und Hardware-Experten von Fidelity gearbeitet haben, um Ihnen noch mehr Freude am Computerschach zu vermitteln. Wir hoffen, dass Ihnen die aufregenden Fortschritte auf dem Gebiet der Mehrfachprozessoren genauso viel Spaß machen werden, wie es uns Spaß gemacht hat, sie Ihnen näherzubringen.
Dan & Kathe Spracklen
Fidelity Elite Avant Garde Versionen
| Version | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11* |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Nummer | 2265 | 2265 | 2265 | 2265 | 2265 | 2325 | 2325 | 2325 | 2325 | 2325 | 2325 |
| Model | 6114-1 | 6114-2 | 6114-3 | 6114-4 | 6114-5 | 6117-6 | 6117-7 | 6117-8 | 6117-9 | 6117-10 | 6117-11 |
| RAM (Hash Tables) | 128K | 128K | 512K | 1024K | 192K | 512K | 1024K | 640K | 1024K | 1024K | 2048K |
| Hash Table Stellungen | 16.000 | 16.000 | 64.000 | 128.000 | 24.000 | 64.000 | 128.000 | 80.000 | 128.000 | 128.000 | 256.000 |
| Programmgröße | 128K | 128K | 128K | 128K | 128K | 128K | 128K | 128K | 128K | 1024K | 1024K |
| Takt (MHz) | 16 | 16 | 16 | 16 | 16 | 20 | 20 | 20 | 32 | 25 | 66 / 72 |
| Prozessor | 68000 | 68000 | 68000 | 68000 | 68000 | 68020 | 68020 | 68020 | 68030 | 68040 | 68060 |
| Anzahl Prozessoren | 1 | 1 | 1 | 1 | 2 | 1 | 1 | 2 | 1 | 1 | 1 |
| Lernfähigkeit | nein | ja | ja | ja | ja | ja | ja | ja | ja | ja | ja |
| * Bei der sogenannten Version "11", welche keine offizielle darstellt, handelt es sich um einen Eigen- bzw. Umbau durch Herrn Bucke.
Weitere Informationen finden sich im Artikel von Alwin Gruber: | |||||||||||