Apu's Hardware interview met Sean Stanek

Apu's Hardware heeft een interessant interview afgenomen met Sean Stanek, voormalig code optimalisatie goeroe bij AMD en verantwoordelijk voor de Athlon-optimized RC5 core. Sean ventileert zijn mening over het gebrek aan goede x86 compilers en spreekt over de voordelen van 'post-RISC' processors zoals de Athlon tegenover pure CISC en RISC CPU's. Dit keer geen standaard gekanker op de zogenaamde superieuriteit van RISC:

What do you see as the major bottleneck in computers today?

A combination of memory speed and poor compilers makes up the largest bottleneck. For things like high-speed graphics, the AGP bus did wonders for speeding up memory, and since graphics need a lot of memory, speeding up the memory helps to eliminate one bottleneck. And compilers for the x86 instruction set are generally very poor. Having a CISC instruction set is wonderful to write in, and you can do many RISC operations in just a single CISC operation. And because processor like the Athlon can execute several CISC instructions in a single clock, they can run several times faster than RISC processors. However, compilers understand RISC far better than CISC, and so compilers aren't very good, even hand-coded x86 assembly really isn't very hard to write (despite all criticism), and, at least for me, it's far easier to use than languages like C/C++. Either a good compiler is needed, or else more good assembly programmers should be introduced into the programming community. Well written assembly code can be anywhere from 10% to 500% faster than C/C++ compiled code. In fact, in real-world applications, I've *never* seen C/C++ code outperform well-written assembly code.

So, you're saying a CISC architecture is far superior to RISC?

A combination of a CISC instruction set and a post-RISC CPU core is better than both CISC and RISC. CISC is a bit large to put in all silicon, and RISC cannot scale very far because you'd have to be supplying the instruction decoders with a large number of instructions every clock. The Athlon and most x86 CPUs from the Pentium onward use the best of both worlds to create a superior CPU.

Reacties (6)

[Verwijderd]

Ik ben het helemaal met die man eens

Maar eh, heel leuk als je programma's in assembler schrijft, maar waar je zeker weten tegen aanloopt (eigen ervaring ) is als dat je er NIETS meer van begrijpt als je code na 2 dagen te hebben laten liggen weer opent

[update]
M'n Nederlands is niet alles, nu waarschijnlijk nog niet
[/update]

[ShadowLord]

Valt wel mee... Zolang je maar GOED documenteerd wat je doet en waar, valt er best nog uit te komen
Ook eerst goed plannen wat je wil maken en hoe dat zou moeten werken. Dat zij toch wel de basics als je iets (serieus) wil gaan Coden.

En over het algemeen, als je met een project in assembler bezig bent, werk je daar niet een half dagje aan, om dan maar weer 2 dagen wat anders te doen.

<UPDATE>Damn typo's. T'is al laat :)</UPDATE>

[Verwijderd]

Er zijn natuurlijk mensen die elk weekend ook gewoon doorwerken.

Plus dat een projectje in assembler natuurlijk al standaard minstens 40 keer langer duurt dan een projectje in C/C++. Voor een commercieel bedrijf die een product op de markt moet brengen dus niet echt een reele optie.

Misschien dat na profiling kleine stukjes herschreven kunnen worden in assembler.

[arnob]

Misschien dat AMD (hij?) dan eens de banden moet aanhalen met de bedrijven die compilers maken. Of een GNU compiler zelf een (stukje) veranderen, dan gaan anderen misschien nadenken.
Ik ben bang dat er anders echt niets veranderd. Het zal eerder gebeuren dat de compiler bedrijven onder 'manual optizer hints' zullen zetten dat je je CPU kunt overklokken

[farlane]

Coderen in assembler ? Back to basics zal ik maar zeggen ? Nee, dat is echt geen optie; en wel om redenen waarvoor al die andere hogere talen zijn bedacht.

Hij zegt er ook bij dat het voor hem het makkelijkst is om in assembler te coderen. Volgens mij is dit het probleem van de programmeur die iets erg goed kan en geen nieuwe dingen wil (?) leren omdat het ' langzamer is' en 'asm economischer is'. (Probleem is dan ook, hijzelf vindt het makkelijker, maar het grootste gedeelte van de rest van de wereld niet.)

Misschien dat je het wel 'vastgeroest' kunt noemen, alhoewel dat een erg gewaagde uitdrukking is.

[Verwijderd]

De enige plaats waar asm nog veel voorkomt is de crackscene en daar zit echt een stel geniale wizzards bij. Bij spellen is het tegenwoordig niet echt meer nodig omdat die zo'n 80% of meer van hun tijd gewoon de 3d drivers draaien. Dus kun je dan maar 10-20% van de tijd winnen. Ik weet alleen niet hoe het staat met de asm-skillz bij nvidia en 3dfx.

Wat ik nog wel zie gebeuren is dat met de nieuwe 64 cpu's, sse2 etc. nog wat asm coders nodig zijn omdat het altijd even duurt voordat daarvoor compilers zijn, en dan nog is een stukkie hand-optimized critical path veel sneller.