Tudtommal az EPIC prefetch utasításai pont a cache problémák orvoslására szolgálnak (nevezetesen maga a gépi kód utasítja a cache-t hogy honnan és mikorra húzzon be adatokat) tehát ezzel nem értek egyet. A multiprocesszoros rendszerek cache problémáihoz pedig nem értek, ezért ezzel kapcsolatban nem is tudok véleményt nyilvánítani.
Azt hogy az EPIChez kézzel brutális kódot lehet írni, gondolom csak viccnek szántad. Ha van valami amihez szerintem rémálom lehet kódot írni az az EPIC. Ezt tényleg komolyan írtad!?
Mivel az EPIC VLIW-re alapul, ráadásul annak a változó szerkezetû verziójára, szerintem erre ember nem képes kódot írni (illetve egy nap alatt csinálna valamit ami fele olyan hatékony lenne mint amit a C compiler kinyom 1 mp alatt).
Figyelni kellene az elágazásoknál a szálak eredményeinek érvénytelenítésére, az utasítások jó VLIW csomagolására a prefetchre... brrrr.
A mag pedig nem rejti el a prefix problémát elõled. Hiába jó a mikro kód a magban, akkor is nagy overhead minden 64 bites utasítás elött a 3-4 felesleges byte.
A fordító már most olyan hatékony mint a RISC-esek, ami pedig már igen jónak mondható. A legjobb HP-s szakemberek dolgoztak rajta, persze biztos nem a legoptimálisabb, de a 10-év hatalmas túlzásnak tûnik.
Egyébként az hogy 'elég kevés 386-ra optimalizált kód rontja immár a levegõt' nem világos. Most MINDEN PC kód 386-os protected módban fut! Most akkor mire optimalizálnak szerinted???
A helyben fordítók pedig elõretörnek ezerrel (.NET és Java JIT), de nem értem hogy ennek mi köze lenne bármihez is...