Ha én azt mondom a szakácsnak, hogy oldja meg, hogy X-1 köbméter gázból finomabbat főzzön, mint múltkor, akkor a szaktudását arra fogja használni, hogy ezt megtegye. Kivéve, ha a szakács hupu, mert akkor megmagyarázza, hogy igazából X+1 köbméter gázból kéne főzni és a közízlés szerint nem úgy finom, ahogy én akarom. Mindezt azzal fűszerezi meg, hogy mit ugatok bele, amikor amúgy se értek a főzéshez. Ha meg igen, akkor főzzek én.
Ha meg kevesebb gázt használ, mert kínkeservesen megoldja, amit szeretnél, de közben hibázik és ezért lesz rossz a leves, akkor meg az a bajod.
A Meltdown és a Spectre pont azért keletkezett, mert a CPU gyártók igyekeztek több teljesítményt kihozni ugyanannyi energiából (ugye OPS/kWh), csak közben nem voltak eléggé körültekintőek, de akkor meg az a bajod, hogy miért csak annyit tudnak a CPU-k, mint azok a CPU-k, amelyeknél nem növelték a hatékonyságot.
Tulajdonképpen neked nem lehet olyan levest főzni, amivel elégedett lennél és te magad se tudsz főzni, csak olyan módon kritizálni, hogy közben képtelenségeket és hülyeségeket beszélsz, mert van egy rögeszméd, amitől nem tudsz szabadulni.
Nem fér bele és az ezután következő "CPU/memória optimalizáció egymást zárják ki" című idealista közhelyből sem kérek, köszönöm.
Ezt beszéld meg azokkal is, akik értik a rendszerek működését.
Ha memóriára optimalizálsz, akkor tömör kódot írsz és a lehető legtöbb dolgot a szükséges időben kiszámolod és nem tárolod le, hanem eldobod és később újra-és-újra kiszámolod; ennek az ára az, hogy több CPU erőforrás szükséges a futása közben. Ha CPU-ra optimalizálsz, akkor a ciklusokat kifejted ismétlődő kódrészletekbe, előre kiszámolt táblázatokkal dolgozol, amelyeket indításkor betöltesz vagy kiszámolsz, nem optimalizálsz agresszíven újrafelhasználható kódrészletekkel és figyelembe veszed az éppen használt hardver jellemzőit; ennek az ára az, hogy több memóriát szükséges a futása közben. A két véglet között tudsz programokat fejleszteni, nincs olyan program, ami egyszerre nyújtja a lehető legtömörebb kód- és adat-memória igényt, miközben olyan gyors, mint a CPU-ra optimalizált kód. Ilyen csak a fejedben létezik.
Én írtam programot 8 bites uC eszközre, ahol mindössze 384 bájt volt a program számára használható ROM és 16 bájt az adatok számára használható RAM és írtam már programot olyan uC eszközre is, ahol volt 64 kB RAM, teljesen más elvek mentén optimalizál az ember a két eszközre. És persze írtam programot szerver oldalra, ahol egyedül az számított, hogy mennyi az OPS/kWh arány. És olyan programot is írtam, amelyik nem volt optimalizálva, mert hamar kellett és csak egyszer volt rá szükség.
Nem is mondtam, hogy azért írják oda, ellenben nem mutattál más helyről servlet mérést, csak innen.
Te hány helyről mutattál eddig mérést? Nekem vannak saját méréseim is, amit mutattál például, azt lemértem magamnál is és megnéztem a mérés körülményeit is.
Ha adsz egy tool-t, amivel a teáltalad elfogadott, mérnöki™ sztenderdek szerint meg tudom mérni, hogy adott, Windows XP-n futó grafikus desktop alkalmazás mennyi idő alatt rajzolja le a widget-jeit, és mindezek függvényében mennyi CPU-t és memóriát zabál, akkor kapsz róla mérést. Ha ilyet nem tudsz adni, elég az is, ha mutatsz nekem egy GUI-s torrent klienst, amit szerinted jó (nem C-s logikájú) Java programozók írtak és emiatt gyorsabb és kevesebb memóriából elvan, mint a vele azonos alapfunkcionalitású natív C/C++ torrent kliens. Akkor elhiszem, hogy az én "világomban" is megáll a "Java tud gyorsabb lenni a C++ -nál". Addig nem. Természetesen, továbbra is elhiszem, hogy a szervervilágban tud gyorsabb lenni a Java. Csak éppen annak a világnak a céljai is mások, a jellege és a technológiája is más, a felhasználási módja meg végképp.
http://a.te.ervelesi.hibad.hu/bizonyitasi-kenyszer-atharitasa