Information Technology Reference
In-Depth Information
einen wurden 16-Bit Fixpunktzahlen mit festen Exponenten
verwendet, zum anderen wurde keine automatische Expo-
nentenanpassung beim Verlassen des durch den Exponenten
gegebenen Zahlenbereichs durchgeführt.
Die Synapse-1 speicherte alle Zahlen intern im F16 For-
mat ab. Bei diesem Format wird eine 16-Bit Mantisse für jede
Zahl benutzt. Diese Mantisse wurde im Zweierkomplement
interpretiert und deckte den Wertebereich −32768 ≤
x
≤ 32767
ab. Die spezielle Form der Arithmetik erzeugte eine spezielle
Vorverarbeitung der Trainingsdaten, sodass sie bei gleichen
Exponenten mit ausreichender Genauigkeit dargestellt wer-
den konnten.
Allerdings zeigte die Geschichte der Synapse wieder ein-
mal, wie falsches Marketing und dadurch bedingt, an den Be-
dürfnissen der Benutzer vorbeigehende Weiterentwicklungen,
zu einem Scheitern eines Erfolges zukunftsträchtiger Projekte
führen. Die Hardware-Architektur bedingte im praktischen
Einsatz eine Reihe von Schwachpunkten:
Der Neuro-Computer Synapse-1 wurde mittels eines VME-
Bus Adapters an einen Host-Computer (Workstations der Fir-
men SUN oder SGI) angeschlossen. Die Synapse-1 des Ins-
tituts für Informatik an der Universität Münster war z. B. mit
ihrem VME-Bus an eine Sbus-Steckkarte einer SUN Sparc-
Station 4 angeschlossen. Über diese Schnittstelle erfolgte der
komplette Datenaustausch zwischen Synapse und dem Host.
Die Datentransferrate betrug dabei maximal 1 MB/sec.
Diese relativ niedrige Geschwindigkeit zwang den Pro-
grammierer, den Datenaustausch zwischen Synapse und
Host so gering wie möglich zu halten. Bei Echtzeitanwen-
dungen mit großem Datenaufkommen (z. B. Verarbeitung
eines Bilddatenstroms mit über 10 MB/sec.) wirkte sich
dieser „Flaschenhals“ jedoch unweigerlich negativ auf die
Gesamtleistung des Systems aus. Neben großen Datenmen-
gen konnte auch der Kommunikationsoverhead, der einen
kompletten und fehlerfreien Datentransfer sicherstellte, als
„Bremse“ wirken - ein weiterer Grund, bei der Programmie-
rung die Nebenbedingung eines geringen Datenaustauschs
zu berücksichtigen. Da vonseiten der Firma Siemens keine
Modiikation dieser Schwachstelle geplant wurde, wurde in
der Arbeitsgruppe von
J. K. Anlauf
an der Universität Bonn
zeitweilig die Konstruktion eines schnelleren Interfaces er-
wogen. Die zu erwartenden Kosten verhinderten jedoch eine
Realisierung des Projektes.
Die Synapse unterstützte alle benötigten Matrixopera-
tionen. Dabei war allerdings zu beachten, dass sich einige
Operationen nur zwischen bestimmten Speichern ausführen
ließen. Aus diesem Grund war es nicht immer zu vermei-
den, dass Matrizen zwischen den Speichern kopiert werden
mussten, bevor eine bestimmte Operation ausgeführt werden
konnte.
Da die Synapse-1 nicht als Standalone-System lauffähig
war, musste die Steuerung immer von einem Host aus erfol-
gen. Es waren also Programme oder Softwareschnittstellen
notwendig, um mit der Synapse-1 zu arbeiten. Mit ECANSE
existierte eine graische Oberläche für die Synapse-1, die
dem Anwender kostenlos zur Verfügung gestellt wurde. Die
Oberläche ECANSE lief auf dem Host und schirmte den Be-
nutzer weitgehend von der Synapse-1 ab. Die für ECANSE
zur Verfügung gestellten Synapse-Programme waren aller-
dings direkte Umsetzungen der „gewöhnlichen“ Algorithmen
und nutzten die Möglichkeiten der Synapse nicht aus.
Es war prinzipiell möglich, solche ECANSE-Programme
selbst zu schreiben. Allerdings benötigte dann jeder Benutzer
des Programms eine ECANSE-Lizenz, die nur rechnerbezo-
gen vergeben wurde. Da sich zudem die Programmierung des
Systems als sehr umständlich erwies, wurde auf die Verwen-
dung dieser proprietären graischen Benutzeroberläche von
den Anwendern größtenteils verzichtet.
Für den Programmierer stand die C++-Bibliothek nAPL
(
n
eural
A
lgorithms
P
rogramming
L
anguage) zur Verfügung.
Die Bibliothek stellte die Synapse-1 Objekte, insbesondere
Matrizen und LookUp-Tabellen als neue Datentypen bereit.
Die Programmierung des Synapse-1 Rechners erfolgt aus-
schließlich durch die Verwendung der Objekte und Metho-
den der nAPL. Im Laufe der Arbeit mit der Bibliothek stellte
sich jedoch für die Benutzer heraus, dass die von Siemens
mitgelieferte Dokumentation der nAPL Klassen an manchen
Stellen unvollständig bzw. fehlerhaft war. Zudem arbeiteten
auch einige Methoden der nAPL offenbar nicht korrekt. Die
Implementierung von Algorithmen auf der Synapse-1 erfor-
derte daher die intensive Auseinandersetzung mit der nAPL
anhand empirischer Studien.
Obwohl die Konzeption der Synapse theoretisch für eine
optimale Unterstützung der Implementierung von Neuronalen
Netzen ausgelegt wurde, zeigten die praktischen Erfahrun-
gen, dass die oben aufgeführten Schwachstellen in der Praxis
zu einer Reihe von Problemen bei der Implementierung führ-
ten. Die Verbesserungsvorschläge, die vonseiten der Anwen-
der eingebracht wurden, wurden von Siemens jedoch nicht
umgesetzt, da man aus „kaufmännischer“ Sicht zunächst die
Investitionskosten wieder einholen wollte. Da durch diese
Entscheidung die Kunden nicht zufriedengestellt werden
konnten, blieb der Synapse der nachhaltige Erfolg versagt.
Weitere Entwicklungen gab es zur gleichen Zeit von den
Firmen Hitachi (
WSI, MY-NEUPOWER
), IBM (
ZISC
) und
Philips (
LNeuro
).
Die Europäische Union hat im Jahre 2006 ein auf vier
Jahre ausgelegtes und mit rund zehn Millionen Euro geför-
dertes Projekt zur Entwicklung eines Neurocomputers mit
einer halben Million Nervenzellen und einer Milliarde Ve r -
bindungen (Synapsen) gestartet. Fünfzehn europäische Grup-
pen aus den Bereichen Neurobiologie, Informatik, Physik
und Elektrotechnik arbeiten unter Leitung des Heidelberger
Kirchhoff-Instituts für Physik an diesem FACETS-Projekt,
wobei FACETS für „Fast Analog Computing with Emergent
Transient States“ steht.
