🚀 go-pugleaf

Patrick Kormann wrote:

> Am 20.04.12 15:32, schrieb Mario Rothacher:
> 
>> Das mit dem mehrere Cores gleichm�ssig zu befeuern passiert eben quasi
>> automatisch, da selten nur ein Prozess auf einer Kiste l�uft. Insofern
>> sollte das nicht so wirklich kompliziert sein.
> 
> Ausserdem meinte ich auch andere Dinge. Mal schauen ob ich die richtigen
> Begriffe zusammenkriege. Der Compiler sortiert ja z.B. je nach dem
> Befehle, die voneinander unabh�ngig sind so um, dass m�glichst wenige
> Wartezyklen entstehen (der Pentium 4 hatte ja irgendwie ne unendlich
> lange prefetch Queue) , sorgt daf�r, dass Funktionseinheiten, die
> 
Der P4 war auch ne Elektroheizung mit Abrechenleistung, die Verantwortlichen
die DAS verbrochen haben m�ssten echt mal �ffentlich bestraft werden :-|

> parallel betrieben werden k�nnen (das ist nicht dasselbe wie
> 
Superskalare CPUs

> Multithreading) auch dementsprechend Daten kriegen etc. etc.
> Ich stell mir das schon noch sau kompliziert vor.
> 
Der Compiler ist das eine, vieles wird aber immer noch von der CPU
optimiert, merkt man gut am Atom. Der hat keine Out of Order Execution (Das
heisst die CPU kann Befehle nicht umsortieren um die Auslastung der
Pipeline zu verbessern), dementsprechend bringt Hyperthreading (welches
einen zweiten CPU-Kern simuliert, welcher die freien Funktionseinheiten
nutzt) viel mehr (relativ gesehen) als auf anderen Intel-Chips.
Allgemein kann man sagen, das heutige CPUs extrem gut sind darin das was an
Code ankommt optimal umzusortieren und bei Spr�ngen richtig zu sch�tzen.
Ansonsten w�rde wesentlich weniger von der theoretischen Rechenleistung
beim Anwender ankommen.
Ich habe mal ein interessantes Paper zu dem ganzen gelesen, finde es aber
nicht mehr. Als Nicht-Proprammierer liest sich das immer sehr interessant,
aber hat wenig Einfluss auf meine Arbeit als Sysadmin.

Was heute zusehends wichtiger wird sind die ganzen SSE-Instruktionen als
Erg�nzung zu x86, da muss man glaub ich aber auch Quellcode teilweise etwas
pr�parieren, damit der Compiler das nutzt. Abgesehen von wenigen Ausnahmen
(Irgendwie muss Intel ja demonstrieren, wozu man das braucht) werden die
Funktionen im Massenmarkt gesch�tzt 10 Jahre nach Markteinf�hrung genutzt,
damit garantiert jeder potentielle Kunde auch kompatible Hardware hat.
Eine interessante Ausnahme ist die AES-Verschl�sselung, welche Intel in den
Core i eingef�hrt hat, und welche vom Markt sehr schnell aufgenommen wurde.

>> Aber so tief mit Hardware habe ich mich seit �ber 20 Jahren eigentlich
>> nicht mehr befasst. Damals als die Prozessoren noch im 1-2 stelligen
>> MHz-Bereich getaktet wurden, spielte die Ausf�hrungszeit nat�rlich noch
>> eine viel wichtigere Rolle als heute... Da darf man ruhig in
>> Hochsprachen entwickeln die dann wieder interpretiert werden (Analog
>> Commodore Basic) wie zum Beispiel Java. Ein Compiler der in
>> Maschinencode �bersetzt ist meiner Meinung trotzdem vorzuziehen, zum
>> Beispiel C,C++ oder das untersch�tzte Delphi.
> 
> Ich weiss nicht, Java fand ich immer schon grottig.
> 
Ich wundere mich immer, wieso die ganzen Hersteller von Hardware Java nicht
noch mehr pushen. Das Zeugs scheint immer wahnsinnig viel CPU und Ram zu
fressen, zumindest verglichen mit C-Programmen.

Gruss,
Peter