TILE64 - 10mal schneller und 30mal kühler als ein DC-Xeon [Archiv]

AnarchX

2007-08-20, 16:33:19

Tilera Corporation today launched the TILE64™ processor, the first in a family of Tile Processor™ chips based on a revolutionary architecture that can scale to hundreds and even thousands of cores. The TILE64 processor contains 64 full-featured, programmable cores - each capable of running Linux - and delivers 10X the performance and 30X the performance-per-watt of the Intel dual-core Xeon, and 40X the performance of the leading Texas Instruments DSP*. Initial target markets for the TILE64 processor include the embedded networking and digital multimedia markets. [...]
http://www.vr-zone.com/articles/Tilera_64_Cores_CPU_10X_Faster%2C_30X_Cooler_than_Dual_Core_Xeon/5167.html

Hier noch die News in Deutsch @ PCGH:
http://www.pcgameshardware.de/?article_id=610254

Mit $435 doch gar nichtmal so teuer. Fragt sich nur wo er 10mal schneller sein soll? ;)

Godmode

2007-08-20, 16:42:24

Ich denke das ist sowas wie Polaris und nicht mit einer normalen x86-CPU vergleichbar. Hört sicher aber interessant an.

Stone2001

2007-08-20, 16:59:53

Ich denke das ist sowas wie Polaris und nicht mit einer normalen x86-CPU vergleichbar. Hört sicher aber interessant an.
Interessant ist der Chip sicherlich, auch wenn seine Konzepte schon recht alt sind.

Die Rohleistung mag mit 64 Kernen zwar gewaltig sein, aber wieviel kommt am Ende beim Benutzer an? Wenn man die Anwendung nicht in gleichgroße Stücke zerteilen kann und im Prinzip eine Softwarepipeline aufbaut, wird man die Peek-Performance wohl nicht erreichen.

Aber ich würde echt gerne mal Benchmarks sehen und dann wie man das Teil programmiert hat? Ich schätze, das da recht viel Assembler im Spiel ist.

Coda

2007-08-20, 18:03:06

Wieso Assembler?

Anarchy-HWLUXX

2007-08-20, 20:09:06

Also mit den 64 "Cores" und integrierten NICs hört sich das nach UltraSPARC T2 an ... Hm ?

(ne ich hab mir das ganze nicht durchgelesen ;) )

Stone2001

2007-08-20, 20:41:58

Wieso Assembler?
Wieso denn nicht?

Polaris wird ja auch größtenteils in Assembler programmiert.

Ich müsste mal nachschauen, ob es für den MIT-RAW einen brauchbaren C-Compiler existiert. Auf der anderen Seite, für den Cell-Prozessor existiert auch noch keinen brauchbaren.

Mit einem T2 würde ich diese Architektur nicht vergleichen. T2 ist ein normaler CMP (die Prozessoren können über eine Crossbar auf den Speicher bzw. den Cache gleichberechtigt zugreifen).
TILE64 oder Polaris sind dagegen Prozessoren die über ein NoC miteinander und mit dem Speicher verbunden werden.

Tesseract

2007-08-20, 21:48:17

diese "unsere äpfel sind 1000 mal schneller als die birnen der anderen" vergleiche sind immer wieder geil.

"10 mal schneller" mit 64 cores bedeutet schonmal prinzipbedingt maximal 30% der pro-thread-performance des xeon. "ungeschönt" in der praxis wohl noch weit darunter.

Coda

2007-08-20, 22:02:07

Wieso denn nicht?
Ergibt keinen Sinn. Low-Level C reicht doch völlig. Assembler ist doch für heutige Problemstellungen praktisch nicht mehr anwendbar.

Ich müsste mal nachschauen, ob es für den MIT-RAW einen brauchbaren C-Compiler existiert. Auf der anderen Seite, für den Cell-Prozessor existiert auch noch keinen brauchbaren.
Für Cell existieren sehr brauchbare C-Compiler. Nur Autoparallelsierung funktioniert natürlich nicht gescheit.

Stone2001

2007-08-20, 22:31:58

Für Cell existieren sehr brauchbare C-Compiler. Nur Autoparallelsierung funktioniert natürlich nicht gescheit.
Ergo: Es gibt keinen gescheiten Compiler dafür. Ein Compiler zu entwickeln, der C oder eine andere Sprache in ein ausführbares Format übersetzt ist kein großes Problem mehr. Autoparallelisierung dagegen ist sehr wohl noch ein Problem.

Solange die c't noch ihre Apfelmännchen per Hand optimieren muss, damit sie richtig schnell sind, solange gibt es keine gescheiten Compiler für den Cell-Prozessor.

Oder wie es hier der Fall, die automatische Task und Kommunikations-Generierung dürfte auch noch ein großes Problem sein. Falls wirklich gut funktionieren würde, wäre morgen die MPI-Community arbeitslos.

Coda

2007-08-20, 22:43:22

Ergo: Es gibt keinen gescheiten Compiler dafür.
Nach der Logik gibt es auch keinen gescheiten Compiler für einen Core 2 Duo.

Und: Ich sage, dass es für Cell nie einen "gescheiten Compiler" nach deiner Definition geben wird.

Avalox/Gast

2007-08-21, 12:45:22

Wäre denn heute ein von Hand in Assembler produzierter Code überhaupt im Vorteil, vor dem was ein Vernünftiger C++ Compiler so hinbekommt?

Ich denke nicht. Jedenfalls nicht in irgendeinem vertretbaren Rahmen.

PHuV

2007-08-21, 16:56:37

Da lobe ich mir schon den neuen Sparc T2, siehe Heise-Artikel Prozessorgeflüster 18/07. (http://www.heise.de/ct/07/18/038/). Der läuft auf bereits bestehenden Solaris-Umgebungen.

Hvoralek

2007-08-21, 17:07:50

Ich finde die Formulierung "30- mal kühler" etwas ungeschickt. Das Teil soll die 30- fache Pro- Watt- Leistung erreichen, bei der 10- fachen Leistung also etwa 1/3 der Energie benötigen.

Blinx123

2007-08-21, 17:53:39

Ergibt keinen Sinn. Low-Level C reicht doch völlig. Assembler ist doch für heutige Problemstellungen praktisch nicht mehr anwendbar.

Naja. Ich finde schon,dass es Sinn macht. Assembler ist jedenfalls um einiges schneller als ein Low-Level C. Wenn Low-Level Contex,dann wohl D.

Avalox

2007-08-21, 18:14:20

Naja. Ich finde schon,dass es Sinn macht. Assembler ist jedenfalls um einiges schneller als ein Low-Level C. Wenn Low-Level Contex,dann wohl D.

Nein, das glaube ich nicht. Compiler erzeugen dermaßen optimierten Code, dass ich nicht denke, dass jemand von Hand dieses überbieten wird. Ein handwerkliches Problem der Übersicht. Natürlich könnte jemand in Assembler ..., es wird aber niemanden geben, der sowas über längere Strecke durchhält.

Bei den vielen Systemaufrufen heutiger Software und ist Ausführungsgeschwindigkeit eh nahezu egal. Ich gehe jede Wette ein, dass unter Visual Basic.Net ebenso Anwendungs schneller Code erzeugt wird, wie mit C++ oder C.
Na ja, Spiele und irgendwelche Anwendungen mit grosser Datenlast mögen da noch Unterschiede machen. Aber absolut zählen mehr Punkte wie Übersichtlichkeit, Mächtigkeit und Verbreitung. Das sind die Vorteile von C++.

Aber Assembler ist nun wirklich nicht mehr im Fokus.

Je mehr Kerne hinzu kommen und je spezieller diese vielleicht auch noch sind, so mehr wird es eh zu einer automatisierten Parallelisierung in der Anwendungsentwicklung kommen. OpenMP oder MPI oder wer weiss was.
Der Overhead ist Preis der Entwicklung. Alles einfach um den Überblick zu behalten.

Coda

2007-08-21, 18:17:14

Assembler ist jedenfalls um einiges schneller als ein Low-Level C.
Wenn der Compiler modern ist macht das nicht mehr viel aus. Glaub mir. Nur mal so als Beispiel: Seit der Version 2 der Unreal Engine ist kein Fitzel Assembler mehr enthalten.

Was heute noch benützt wird sind SSE-Intrinsics, die aber auch der Compiler dann noch nachoptimieren kann.

Blinx123

2007-08-21, 18:26:43

Wenn der Compiler modern ist macht das nicht mehr viel aus. Glaub mir. Nur mal so als Beispiel: Seit der Version 2 der Unreal Engine ist kein Fitzel Assembler mehr enthalten.

Was heute noch benützt wird sind SSE-Intrinsics, die aber auch der Compiler dann noch nachoptimieren kann.

Naja,ich bin wahrscheinlich auch zu altmodisch. Kann gut sein,dass die Compiler sich inzwischen gewandelt haben,zumal ein C Compiler ja auch in Assembler wandeln muss. Ist dann eben nur kein Handoptimierter Assembler Code mehr.

Eigentlich habt ihr ja recht,denn seit Basic eine ordentliche 32Bit MultiPlattform Version bekommen hat (sogar mehrere mit FreeBasic,PureBasic usw.) ist sogar diese Sprache ordentlich optimiert und kann gut gegen Assembler antreten.

Ganz verschwinden wird Assembler aber wohl trotzdem nicht so schnell. Denn man muss sich ja mal eins durch den Kopf gehen lassen: Wie werden diese guten und schnellen Compiler denn geschrieben bzw. optimiert? Eben mit handoptimieren Assembler.

Lord_X

2007-08-21, 18:44:38

Coda

2007-08-21, 18:47:49

Ganz verschwinden wird Assembler aber wohl trotzdem nicht so schnell. Denn man muss sich ja mal eins durch den Kopf gehen lassen: Wie werden diese guten und schnellen Compiler denn geschrieben bzw. optimiert? Eben mit handoptimieren Assembler.
Ein Compiler wird selber auch in C oder einer anderen Hochsprache geschrieben.

Avalox

2007-08-21, 19:00:01

Ich denke diese CPU wird vorwiegend in Setup-Boxen zum decodieren von
MPEG2 und H.264 Datenströmen genutzt werden.

Eine Home Box mit einer 450€ CPU. Nie im Leben. Im prof. Equipment vielleicht.

Blinx123

2007-08-21, 19:18:16

Ein Compiler wird selber auch in C oder einer anderen Hochsprache geschrieben.

Ja,aber dann größtenteils Assembler Handoptimiert. Zumindest in der FeatureList des FreeBasis Compilers ist sogar die Handoptimierung gelistet.

Coda

2007-08-21, 19:22:26

Ja,aber dann größtenteils Assembler Handoptimiert.
Nö. GCC ist in reinem C geschrieben, und ich glaube nicht, dass das bei Intel C++ oder Visual C++ anders ist.

Blinx123

2007-08-21, 19:25:16

Nö. GCC ist in reinem C geschrieben, und ich glaube nicht, dass das bei Intel C++ oder Visual C++ anders ist.

Wie gesagt,es gibt zumindest welche. Freebasic ist einer davon.

Coda

2007-08-21, 19:29:30

Bokill

2007-08-21, 19:46:45

Ich denke diese CPU wird vorwiegend in Setup-Boxen zum decodieren von
MPEG2 und H.264 Datenströmen genutzt werden.

Es sollen sich ja 2 H.264 Datenströme gleichzeitig decodieren lassen...
Habe leider die Quelle nicht zur Hand... Das steht sogar auf deren eigenen Webseite drauf! Allerdings wohl weniger Set-Top-Boxen, als genau am anderen Ende der Leitung ... zur Encodierung auf Produzentenseite. ;)

MFG Bobo(2007)

Haarmann

2007-08-21, 21:40:48

So gut wie Gigabooster?

*gähn*

ETH 4ever...

Blinx123

2007-08-21, 22:04:02

Das glaube ich nicht.

Compiler sind so schon komplex genug, da hat Assembler keinen Platz. Außerdem kommt es beim Kompilieren wohl kaum auf das letzte Quäntchen Performance an. Es kommt vielmehr drauf an wie gut der generierte Code ist.

http://www.freebasic.net/index.php/details?page=download&category=src&id=1
"Compiler's source-code, written completely in FreeBASIC, released under GPL."

Naja. Ist wie gesagt meine Meinung,dass Assembler noch lange überleben wird. Und was den Freebasic Compiler angeht,da habe ich mich wohl vertan. Aber schau mal auf die Original Freebasic Seite,da steht etwas vonwegen "Compiler erzeugt handoptimierten Assembler Code". Deswegen dachte ich,dass schon der Compiler selbst mit HandAssembler Code optimiert wurde.

EDIT: Hab leider nur das hier gefunden. Da steht zumindest etwas von einem Inline Assembler. Somit ist die Zukunft für Assembler ja gesichert:)

http://de.wikipedia.org/wiki/FreeBasic

Coda

2007-08-21, 22:09:19

Blinx123

2007-08-21, 23:02:24

Naja,aber in Basic Sprachen ist es eben noch sehr nützlich. Maus- und Tastaturaufrufe würde ich nur so ausführen. Ist einfach präziser und schneller geschrieben (soweit mans beherrscht).

Coda

2007-08-21, 23:07:46

Auf die Maus und die Tastatur hast du über Assembler in einem Protected Mode OS doch gar keinen Zugriff.

maximAL

2007-08-21, 23:24:46

Nach der Logik gibt es auch keinen gescheiten Compiler für einen Core 2 Duo.
gibt es auch nicht. mit C (und praktisch jeder anderen relevanten programmiersprache) muss man sich um die parallelisierung selbst kümmern. das ist bei wenigen threads vielleicht noch vertretbar, aber in bereichen von 64 oder mehr kernen lässt sich das nur noch in ausnahmefällen sinnvoll per hand umsetzen.
da bräuchte es schon komplett andere sprachen mit anderen programmiermodellen um das zu automatisieren.
und eben weil es das nicht gibt, wird für eine sinnvolle nutzung am ende doch wieder nur assembler bleiben. was eine sinnvolle nutzung natürlich gewissermaßen wieder eleminiert.

und diskussionen über assembler bei x86 programmierung sind hier einfach mal völlig fehl am platze.

Coda

2007-08-21, 23:31:26

und eben weil es das nicht gibt, wird für eine sinnvolle nutzung am ende doch wieder nur assembler bleiben. was eine sinnvolle nutzung natürlich gewissermaßen wieder eleminiert.
Was ist denn das für ein Unfug. Mit Assembler ist die Parallelisierung ja noch viel schwerer zu handhaben als mit C.

maximAL

2007-08-21, 23:41:06

Was ist denn das für ein Unfug. Mit Assembler ist die Parallelisierung ja noch viel schwerer zu handhaben als mit C.
wenn die parallelisierung über entsprechende opcodes unterstützt wird (dinge der marke "multipliziere 128 register gleichzeitig"), dann lässt sich das in C einfach nicht ausdrücken - zumindest nicht so, dass es der compiler dann auch wirklich immer macht.

Coda

2007-08-22, 00:47:02

Das hat das Ding aber nicht. Es sind einfach 64 getrennte Recheneinheiten.

Was du meinst sind Vektorprozessoren (der Earth Simulator hat z.B. solche Dinger) und für die gibt es in der Tat sehr gut optimierende Compiler. Multithreading ist deutlich schwieriger als sowas für den Compiler.

Blinx123

2007-08-22, 12:45:29

Einigen wir uns einfach darauf,dass wir uns uneinig sind:)

Du bist eben ein Fan von C Compilern und ich sehe Assembler eben als manchmal praktischer an.

Man hat übrigens Afaik Zugriff auf Maus und Tastatur über Assembler. Das war früher sogar mal die einzige Möglichkeit, schnelle Maus und Tastaturzugriffe unter Basic zu schreiben (früher in der großen Basic Welle).

Habs ausserdem schon selbst gemacht. Unter WinME.

Landmann

2007-08-27, 09:02:02

Es gibt ein paar Nischen, in denen Assembler durchaus noch Berechtigung hat, allerdings nicht so sehr aus Gruenden der Geschwindigkeit gegenueber compiliertem (C)-Code, sondern einfach, weil bestimmte Sachen vom Compiler nicht so uebersetzt werden (koennen), wie man es gerne haette.
Beispiel: Atomare Operationen. Ziemlich wichtig in der parallelen Programmierung. Auf manchen Systemen gibt es dafuer Pseudo-Intrinsics (Win32), extra bereitgestellte Funktionen (Cell) oder eben manchmal auch gar nichts. Mit etwas Glueck liefert ja in naher Zukunft C++0x selbst dafuer eine sprach-interne Erweiterung.
Mein letzter Test zu Autovektorisierung zwischen gcc, icc und haendischen Intrinsics ging zu Gunsten vom icc aus. Der generiert zwar x verschiedene Codepfade, weil man bestimmte Vorraussetzungen eben schlecht in C formulieren kann (und testet die Notwendigen Bedingungen wie Alignment, Elementgroessen, etc. zur Laufzeit), aber das Resultat war in allen Faellen das schnellste. Und auch auf einem Vektorprozessor (NEC SX Serie, Earth Sim) schreibt niemand User-Applikationen in Assembler. Man schaut einfach, ob der Compiler bei kritischen Schleifen Probleme mit der Autovektorisierung hat und formuliert entsprechend den Code um bzw. fuegt nicht-c-konforme Hinweise ein.

Avalox

2007-08-30, 02:12:01

Artikel im Technology Review

http://www.heise.de/tr/artikel/94948

"Tilera, eine Ausgründung von Forschern des MIT, hat einen Chip vorgestellt, der mit 64 einzelnen Prozessorkernen ausgestattet ist. Sein internes Design unterscheidet sich deutlich von der heute in PCs verwendeten Hardware."

Liszca

2007-08-30, 03:19:13

Liszca

2007-08-30, 03:22:31

Ich finde die Formulierung "30- mal kühler" etwas ungeschickt. Das Teil soll die 30- fache Pro- Watt- Leistung erreichen, bei der 10- fachen Leistung also etwa 1/3 der Energie benötigen.

nein das wären dann ein 1/30 der energie;D

lustiges marketing geblubber wenns nicht von intel, amd oder nvidia zu kommen scheint glauben es wohl doch alle^^

del_4901

2007-08-30, 05:06:50

Einigen wir uns einfach darauf,dass wir uns uneinig sind:)
Per Definition

Du bist eben ein Fan von C Compilern und ich sehe Assembler eben als manchmal praktischer an.

Praktischer die Zeit zu verplempern, oder praktischer beim verbuggen?

Man hat übrigens Afaik Zugriff auf Maus und Tastatur über Assembler. Das war früher sogar mal die einzige Möglichkeit, schnelle Maus und Tastaturzugriffe unter Basic zu schreiben (früher in der großen Basic Welle).

Da warst du doch noch Quark im Schaufenster.

Habs ausserdem schon selbst gemacht. Unter WinME.

Dann zeig uns mal dein Kunstwerk. Eigendlich interessiert mich ja nur das mit der Mouse.

T4ch0n4d3l

2007-09-01, 14:48:33

Das liegt wohl eher daran, dass unter ME noch direkter Hardwarezugriff möglich war. Außerdem werden die Basic Programme keine 32bit Programme sein. Unter XP wirst du da wohl Probleme bekommen, denn XP ist ein "reines" 32bit Protected Mode OS. Dort gibts überhaupt keinen direkten Hardwarezugriff mehr, nur noch als Emulation.

Gast

2007-09-02, 10:57:43

Mal ganz davon abgesehen das das in C genau so ginge, nur einfacher...

Ailuros

2009-10-30, 08:11:25

http://www.tilera.com/

http://www.semiaccurate.com/2009/10/29/look-100-core-tilera-gx/

Nasenbaer

2009-11-01, 15:49:27

Zumindest die x64-Compiler von Microsoft haben keinen Inline-Assembler mehr. Man kann natürlich noch externe Assembler verwenden.

Aber ernsthaft verwenden wird das heute keine Sau mehr, außer in extremen Spezialfällen.
Und wie sorgt man dann dafür, dass SSE usw. genutzt werden? Einfach auf die Fähigkeiten des Compilers vertrauen?
Ich lese da nämlich manchmal was von SIMD vectorization und hab nich so richtig ne Vorstellung wie man das macht.

Coda

2009-11-01, 16:01:50

Und wie sorgt man dann dafür, dass SSE usw. genutzt werden
Intrinsics.

pest

2009-11-01, 19:09:50

Intrinsics.

da kommt dir beim GCC aber der Hass ;)

FlashBurn

2009-11-01, 19:41:39

Ich wollte nur mal was zu dem Thema Hochsprache gegen Assembler beitragen ;)

Guckt euch FASM an im Vergleich zu NASM.

Wer sich schonmal mit dem Thema Betriebssystemprogrammierung auseinandergesetzt hat, weiß das Assembler nie aussterben wird. Genauso ist es am Anfang, wenn neue Features (wie AVX) eingeführt werden, einfacher dieser per Hand zu nutzen, als zu warten bis ein Compiler sie wirklich gut unterstützt.

Lange Rede kurzer Sinn, Assembler hat durchaus seine Daseinsberechtigung. Vorallem wenn etwas schnell und klein (Codesize) sein soll. Ein Compiler kann meistens nur eins.

Freakazoid

2009-11-01, 20:38:48

Ich finde die Formulierung "30- mal kühler" etwas ungeschickt. Das Teil soll die 30- fache Pro- Watt- Leistung erreichen, bei der 10- fachen Leistung also etwa 1/3 der Energie benötigen.

"ungeschickt"? Wenn wir von einer wissenschaftlichen Temperaturskala ausgehen, entspricht das minus-Celsius Temperaturen. Wir stecken Energie ins System und die Entropie nimmt ab :ugly: ein perpetuum mobile. hurra. :ugly: :ugly:
Das tut direkt weh den Augen.

Nasenbaer

2009-11-01, 20:39:46

Lange Rede kurzer Sinn, Assembler hat durchaus seine Daseinsberechtigung. Vorallem wenn etwas schnell und klein (Codesize) sein soll. Ein Compiler kann meistens nur eins.
Für "normale" Aufgabe ist diese Aussage total Schwachsinn. Den will ich sehen, der sich im produktiven Einsatz diese Mühe macht und seinem Chef erklären kann, dass das sinnvoll war es so zu machen.
Glaubt ihr etwa, dass ihr da 20% schneller sein könnt als hätte man nen Compiler drübergejagt? Außerdem ist es ja auch zeitlich viel aufwändiger nen Algo in ASM statt C etc. zu schreiben und zu debuggen.

Spezialanwendungen mag es geben aber nicht für typische Endanwenderprogramme. Und selbst bei Mikocontrollern geht man immer mehr den Weg zu Hochsprachen - und da hätte man nichtmal das Problem der Nichtportierbarkeit von ASM-Programmen, da die Hardware feststeht. Aber man ist schneller und fehlerfreier und beides bringt nunmal mehr Geld. Für Freaks, die Langeweile haben zählt das nich aber in der Wirtschaft schon. :D

RLZ

2009-11-01, 20:42:37

da kommt dir beim GCC aber der Hass ;)
Dafür brauchs aber keine Intrinsics. :weg:

Wer sich schonmal mit dem Thema Betriebssystemprogrammierung auseinandergesetzt hat, weiß das Assembler nie aussterben wird. Genauso ist es am Anfang, wenn neue Features (wie AVX) eingeführt werden, einfacher dieser per Hand zu nutzen, als zu warten bis ein Compiler sie wirklich gut unterstützt.
Falls man unbedingt nen Cutting Edge Befehlssatz auf x86 braucht, würde man sinnvollerweise halt den Intelcompiler nehmen. Wenn man leider an einen verkorksten Compiler gebunden ist, heissts halt manchmal back to the basics. :frown:
Von Effizienz redet man dann aber besser nimmer.

FlashBurn

2009-11-01, 21:38:37

Falls man unbedingt nen Cutting Edge Befehlssatz auf x86 braucht, würde man sinnvollerweise halt den Intelcompiler nehmen. Wenn man leider an einen verkorksten Compiler gebunden ist, heissts halt manchmal back to the basics. :frown:
Von Effizienz redet man dann aber besser nimmer.
Tja und bei OpenSource Projekte ist man meistens an den GCC gebunden und kann nicht einfach den IntelCompiler voraussetzen (man würde nicht mal auf die Idee kommen).

Wenn Assembler es nicht bringen würde, wieso nutzen dann z.B. die ffmpeg codecs noch Assembler (war jedenfalls so, wo ich mir das letzte mal den Code angesehen habe)? Auch sieht man gerade bei Videoanwendungen oft Assembler.

Coda

2009-11-01, 22:24:02

da kommt dir beim GCC aber der Hass ;)
Es war ja auch vom x64-Microsoft-Compiler die Rede.

Und bei GCC kommt einem auch bei Inline-Assembler der Hass ;)

Nasenbaer

2009-11-02, 17:46:36

Tja und bei OpenSource Projekte ist man meistens an den GCC gebunden und kann nicht einfach den IntelCompiler voraussetzen (man würde nicht mal auf die Idee kommen).

Ja das stimmt natürlich. Ich würde nichtmal auf die Idee kommen meine Studienarbeit mit irgendwas anderem als gcc oder msvc zu kompilieren. Ich meine SunStudio bringt ja anscheinend super debugging tools für Multiprocessing mit.
Leider bietet ATI keinen Treiber für OpenSolaris an. :mad:

Wenn Assembler es nicht bringen würde, wieso nutzen dann z.B. die ffmpeg codecs noch Assembler (war jedenfalls so, wo ich mir das letzte mal den Code angesehen habe)? Auch sieht man gerade bei Videoanwendungen oft Assembler.
Die Frage ist ob es was bringt oder ob die Entwickler so denken wie viele und meinen ASM wäre das nonplusultra.