PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Hardwaresierung einschätzen bitte


Gast
2007-11-26, 20:25:23
Helft mir mal bitte beim Verständnis, liebe Experten. Ich weiß, dass die CPU möglichst für alles ausgelegt ist und dabei hautpsächlich bei einer Aufgabe schnell ist. Die GPU kann mittlerweile nicht nur für Grafik benutzt werden und ist bei bestimmten Operationen, die gut parallelisierbar sind schnell. Es gibt aber auch z.B. einen Chip, der H.264 encoden kann. Dieser Chip verbraucht einen Bruchteil einer normalen CPU und kann trotzdem FullHD in Echtzeit encoden.

Ich dachte früher, dass z.B. das encodieren von H.264 etwas ist, das man nicht in Hardware gießen kann, weil dabei viele verschiedene Funktionen benutzt werden.

Wie erkenne ich also bei einem eigenen Projekt und eigenem Code, ob es möglich wäre, diesen in einen Chip zu gießen bzw. einen speziellen Chip zu bauen, der diese Aufgabe extrem schnell bei geringem Verbrauch ausführen kann?

Monger
2007-11-26, 21:05:37
Keine unberechtigte Frage.


Der Unterschied zwischen Hard- und Software ist eigentlich gar nicht so groß. Jeder Algorithmus der sich per Software darstellen lässt, lässt sich grundsätzlich mal auch in Hardware gießen. Der Vorteil ist schlicht die Masse bzw. die Flexibilität der Software: du kannst viele verschiedene Probleme auf dem selben Chipsatz abbilden.

Wenn du immer wiederkehrende Aufgaben hast - wie zB. recodieren eines Bildes, einer Frequenz - und das für dich performancekritisch ist, kannst du darüber nachdenken dafür extra Hardware zu bauen. Dazu musst du natürlich vorher erstmal eine Analyse machen, wo denn überhaupt deine Flaschenhälse liegen.

Ein MP3 Player hat z.B. im wesentlichen zwei Aufgaben: decodieren und encodieren. Die Wahrscheinlichkeit ist außerordentlich gering, dass man das jemals um irgendwas erweitern will. Die Hardware dazu ist vergleichsweise billig, und gemessen am Takt ungeheuer performant. Aber Software ist halt im Entwicklungsprozess wesentlich billiger! ;)

Gast
2007-11-26, 21:06:01
Helft mir mal bitte beim Verständnis, liebe Experten. Ich weiß, dass die CPU möglichst für alles ausgelegt ist und dabei hautpsächlich bei einer Aufgabe schnell ist. Die GPU kann mittlerweile nicht nur für Grafik benutzt werden und ist bei bestimmten Operationen, die gut parallelisierbar sind schnell. Es gibt aber auch z.B. einen Chip, der H.264 encoden kann. Dieser Chip verbraucht einen Bruchteil einer normalen CPU und kann trotzdem FullHD in Echtzeit encoden.

Ich dachte früher, dass z.B. das encodieren von H.264 etwas ist, das man nicht in Hardware gießen kann, weil dabei viele verschiedene Funktionen benutzt werden.

Wie erkenne ich also bei einem eigenen Projekt und eigenem Code, ob es möglich wäre, diesen in einen Chip zu gießen bzw. einen speziellen Chip zu bauen, der diese Aufgabe extrem schnell bei geringem Verbrauch ausführen kann?

Das macht das Betriebsystem und die entsprechenden Treiber für dich bzw. den Anwender deiner Software.

Gast (TE)
2007-11-26, 22:27:13
Das macht das Betriebsystem und die entsprechenden Treiber für dich bzw. den Anwender deiner Software.
Du scheinst mein Interesse missverstanden zu haben. :wink:


Keine unberechtigte Frage.


Der Unterschied zwischen Hard- und Software ist eigentlich gar nicht so groß. Jeder Algorithmus der sich per Software darstellen lässt, lässt sich grundsätzlich mal auch in Hardware gießen. Der Vorteil ist schlicht die Masse bzw. die Flexibilität der Software: du kannst viele verschiedene Probleme auf dem selben Chipsatz abbilden.
Genau in dieser Flexibilität habe ich das Problem in der Hardwarelösung gesehen. Ich glaube, dass manche Algorithmen, die man in Software in relativ vertretbarer Zeit schreiben könnte und die brauchbar auf x64 laufen würden, als eigener Chip ein 1 Mrd. Transistor-Monster wäre. Deswegen verstehe ich es, wenn Du sagst, dass es theoretisch immer geht, aber praktisch sehe ich ganz klare kaum zu überwindende Hürden.

So wie ich es verstehe "liegt" die Hardwareimplemenation manchen Problemstellungen sehr gut und es lässt sich mit wenig Aufwand ein Chip produzieren, der trotz eher geringer Taktrate durch einen eher älteren Fertigungsprozess immer noch schneller als ein normaler Prozessor arbeitet und dabei sehr viel weniger verbraucht. Und wie man feststellt, welche Aufgaben so gut liegen, das würde mich interessieren. :wink:

Wenn du immer wiederkehrende Aufgaben hast - wie zB. recodieren eines Bildes, einer Frequenz - und das für dich performancekritisch ist, kannst du darüber nachdenken dafür extra Hardware zu bauen. Dazu musst du natürlich vorher erstmal eine Analyse machen, wo denn überhaupt deine Flaschenhälse liegen.
Bei wiederkehrenden Aufgaben lohnt es sich natürlich eher, aber es kommt ja auch auf die Art der Aufgabe an, wie ich es oben meinte. Meine Idee war, dass man es vielleicht an der Art der Berechnungen und ihrer Struktur irgendwie festmachen könnte. Ist da was dran? Also geht das relativ konkret?

Ein MP3 Player hat z.B. im wesentlichen zwei Aufgaben: decodieren und encodieren. Die Wahrscheinlichkeit ist außerordentlich gering, dass man das jemals um irgendwas erweitern will. Die Hardware dazu ist vergleichsweise billig, und gemessen am Takt ungeheuer performant. Aber Software ist halt im Entwicklungsprozess wesentlich billiger! ;)
Klar, aber gerade um diese Performanz geht es mir. :smile: Und es ist vorerst nur eine theoretische Überlegung. Ich habe nicht vor morgen eine Fab dafür hochzuziehen. :wink:

Gast
2007-11-26, 22:35:39
Du scheinst mein Interesse missverstanden zu haben. :wink:

....
Klar, aber gerade um diese Performanz geht es mir. :smile: Und es ist vorerst nur eine theoretische Überlegung. Ich habe nicht vor morgen eine Fab dafür hochzuziehen. :wink:

Huhu,

ich denke, ich habe dich richtig verstanden: Theoretisch. :)

Gast
2007-11-26, 23:07:31
Warum baut man eigentlich keinen Chip der AES sehr schnell via Brute Force entschlüsseln kann?

Trap
2007-11-26, 23:12:44
Deswegen verstehe ich es, wenn Du sagst, dass es theoretisch immer geht, aber praktisch sehe ich ganz klare kaum zu überwindende Hürden.
Man muss ja nicht zwangsläufig alles in Hardware implementieren, oft mischt man Hardware und Software indem man einfache Prozessoren auf dem Chip oder auf dem Board integriert.

In Hardware lohnt sich vor allem Zeug, dass CPUs schlecht können:
-Parallelisierung sehr vieler, einfacher Operationen
-branching
-spezielle Speicherzugriffsmuster

Außerdem gibt es auch einen Zwischenschritt zwischen Hardware und Software: programmierbare Hardware - FPGAs. Die bestehen aus einheitlichen programmierbaren Logikzellen und einem programmierbaren Verbindungsnetz zwischen den Logikzellen. Die Programmierbarkeit kostet den überwiegenden Teil der Chipfläche und dadurch auch deutlich Geschwindigkeit. Dafür bekommt man FPGAs in sehr moderner Fertigungstechnik, die man für einen eigenen echten Chip oft nicht bezahlen könnte.

Trap
2007-11-26, 23:31:21
Warum baut man eigentlich keinen Chip der AES sehr schnell via Brute Force entschlüsseln kann?
Weil die Technik dafür nicht reicht. 2^128 mögliche Schlüssel = 3,4*10^38.

Nehmen wir für "sehr schnell" mal 1 Jahr ~ 3*10^7 Sekunden, bleiben 10^31 Schlüssel pro Sekunde, bei 1 Schlüssel pro Takt und 10 GHz Takt bräuchte man 10^21 parallele Schlüsselknackeinheiten. Die größten Chips haben ~ 1 Mrd. Transistoren, wären bei 1 Transistor pro Schlüsselknackeinheit (rechnen wir mal sehr optimistisch) immernoch 10^12 nötige Chips.
Das sind mindestens 6 dezimale Größenordnungen zuviel (also mindestens 20 Jahre Hardwareentwicklung). Wenn man länger Sicherheit haben möchte kann man auch 192 oder 256 bit Schlüssel nehmen.

Gast
2007-11-27, 00:07:30
Danke Trap!

@Threadstarter: Wer hat welche Intention nicht verstanden?

PatkIllA
2007-11-27, 01:07:27
Genau in dieser Flexibilität habe ich das Problem in der Hardwarelösung gesehen. Ich glaube, dass manche Algorithmen, die man in Software in relativ vertretbarer Zeit schreiben könnte und die brauchbar auf x64 laufen würden, als eigener Chip ein 1 Mrd. Transistor-Monster wäre. Deswegen verstehe ich es, wenn Du sagst, dass es theoretisch immer geht, aber praktisch sehe ich ganz klare kaum zu überwindende Hürden.Du musst ja nicht alles in feste Hardware gießen. Du kannst ja weiterhin Teile programmierbar lassen und nur für performancekritische Dinge spezielle Schaltkreise entwickeln.
Du kannst den Algorithmus normalerweise eh nicht komplett in eine Schaltung packen. Also in dem Sinne von einer mathematischen Operation, wo du oben die komplette Eingabe reingibst (z.B. ein Bitmap-Bild) und unten das Ergebnis (ein JPEG) rausfällt.