Szoftver bloat érthetően

HUP cikkturkáló

Aki hajbazer kollégára számított, azoktól bocsánatot kérek. :)

Nikita Prokopov (Tonsky) írt egy nagyon jó blogbejegyzést a bloat témájáról. A megfogalmazása és érthetősége sokkal jobb, mint hajbazer dobálózása itt a HUP-on. (Lehet tanulni a normális megfogalmazást és nem csak dobálózni kellene azzal, hogy az XP jobb...)

http://tonsky.me/blog/disenchantment/

Egy-két dologgal azért én magam sem értek egyet, mint például amikor a Windows 95 és a Windows 10-et olyan egyszerűen hasonlítja össze, hogy mind a kettő ugyanazt csinálja mégis 133-szor nagyobb a 10 mérete.

  • 4542 megtekintés

( end | 2018. 09. 30., v – 10:24 )

Amit a "tonsky" programozói önostorozásként leír, az az emberi társadalom egyértelmű elhülyülésének eredménye. "Ha nincs ló jó a szamár is". Erre az elvre épül ma a világ fogyasztási mókuskereke. Nincs az emberekben önismeret, büszkeség, eltántoríthatatlan akarat a jobbra, az igényességre. (Ezeknek az erkölcsi kategóriáknak a helyét a programozóknál is az önfényezés vette át a szerepét.) A munkahelyeken a maximális minőségi kvalitásokat igénylő erőfeszítések után sem kapkodnak az emberek. Nem vívhatjuk ki a közösség elismerését a jól végzett munkákkal, de ha valaki véletlenül ezzel a szemlélettel próbálkozna a munkahelyén, az "plecsniként" gyorsan megkapja a hülye munkamániás jelzőt.

Nem akar senki világot megváltani, mint annak idején pl. Linus és a vele párhuzamos időben munkába álló emberek. Ma mindenki elégedett azzal ha pénzt keres, 3 évenként még nagyobb autót használhat. Nincsenek nagy célok. Csak pénzt érő blöffök. Ez az emberiség kipusztulása előtti utolsó nagy nihili korszaka. Nem véletlen, hogy nem a tanulásért és a világ megváltásáért harcolnak mozgalmak, pártok, de pl. a fű legalizálásáért, homoszexuálisok jogaiért, "ingyen sörért", stb., igen hangosan. Elhülyülni manapság igazán trendi dolog. (Véletlennek azt sem tarthatjuk, hogy a komédiák világa Melissa McCarthy-kért "esedez". Erre van tömegigény. - Szuper!)

...az az emberi társadalom egyértelmű elhülyülésének eredménye...

Minden szavad igaz, de ez az egész jelenség még jobban megérthető a gazdasági jelenségek, - és most itt hegyezzük ki - a szakmai folyamatok tükrében.

Volt először a hardver...
Nem a szoftver, hanem "a hardver futott". Ebben a korszakban a szakemberek számára szinte nulla volt a tévesztési lehetőség. Ez alatt természetesen nem azt értem, hogy nem tévedhetett egy ember, hanem a produktum nem tartmalazhatott hibákat.
A következő a gépi kód és assembler állomása. Ez még mindig hardver, csak flexibilis eszközök segítségével megfogalmazva. Ezzel párhuzamosan megjelent a szoftver is. Az assemblerben kivitelezett produktum, - mivel hardvert valósít meg - még mindig nulla közeli hibalehetőséget enged meg. De ugye, a szoftver már nem. ;)
Aztán jött a C, amely lehetővé tette a gépközeli programozást és szoftvertermékek előállítását is. Míg az assembler eleinte a hardverhez értő kevés szakember privilégiuma volt, a fejletteb nyelv már szélesítette az alkotásban résztvevők körét.
A C++ már igazi tömegek számára biztosított munkát. Ezzel egyúttal elindította a szakma felhígulását.
No, és hol tartunk most? Informatikus hiány van! Fluktuáció, nincs igény, tudás, hajlandóság az alapos munkavégzésre.
(Mielőtt bárki is belekötne, ez nem egy szoftvertörténelem óra, csak kiragadott példa.)

A dolog buktatója a hardver. Van egyszer a Moore-törvény, ami a sebesség exponenciális növekedését jósolta és az idő bebizonyította a sejtés működését.
Sajnos a szakma felhígulása, a szereplők (összefoglalásként) trehánysága, és az ilyen hozzáállással készült toolok használata a lassulásban magasabb negatív kitevőt eredményeznek.
Egyszer oktatás közben - régi szép időkről mesélvén - kaptam egy kérdést, hogy miként értékelem a fejlődést? Hiszen a "személyi számítógépek hajnala óta" a szakmában vagyok. Rövid fejszámolás után - amit extrapolálok a mai napra - a következő megállapítas tehető: Azóta a processzorok teljesítménye 5000000x (ötmillíószor) nagyobb, miközben ugyanazt a feladatot legalább egy kicsit lassabban végzik el.

A cikk írója szerint: That is not engineering. That’s just lazy programming. Engineering is understanding performance, structure, limits of what you build, deeply. Combining poorly written stuff with more poorly written stuff goes strictly against that. To progress, we need to understand what and why are we doing.
Ezt kellene megérteni néhány huptársunknak is, akik szerint én vagyok a rossz, amikor nem tudok, se nem is látom értelmét annak, hogy egy feladatot perlben oldjak meg.
Igen, már megint a hardvernél tartunk! Az OOP esetében fel kell fogni a sok absztaktció mellett azt az egyszerű tényt is, hogy bizony a 10x több memória megtöltése 10x annyi időbe kerül. Ez egy gyors gépen persze nem számít. Biztosan nem számít, hiszen ettől (is) lassabbak a programok. :-D És nem szabad beérni azzal, ha a fejlesztő gépén még elfogadható idő alatt lefut a feladat! Hiszen ma már kizárólag multitasking környezetben futnak a programok. A feleslegesen felhasznált erőforrások a többi program elől veszik el a lehetőséget.
Az ilyen dolgokat összevonva a hasonló elvek szerint készült libbel és a nem túl nagy kvalitású programozóval máris jól megdöntöttük a Moore-törvényt!

Sok esetben tapasztaltam, hogy egy rendszert modernizálva és korszerű gépen futtatva a jelentős mértékű lassulás mellett funkcióvesztés is fellép. Vagyok annyira szkeptikus, hogy előre meg tudom jósolni a romlás mértékét. De mindig bejön. ;)

I’ve been programming for 15 years now.
No, én meg 35. Nem dobálodzom azzal, hogy az XP jobb. Egyszerűen - előzetesen hozzáértő szakemberekkel konzultálva - nem vállalom fel a fenti jelenségek miatt keletkező extra szívást. Így aztán nyugodtabb az életem.

Az alapgondolatokkal egyetértek, de érzek túlzást a mondanivalódban. Azért ZX Spectrumon egy sin(x) függvény kirajzolása súlyos időbe telt, ellenben egy mai PC-n akár egy viszonylag lassú script nyelv felhasználásával is elenyészően rövid idő alatt megtörténik ez.

A mai gépek sokkal jobban használhatók, mint a régi picikék. Viszont az igaz, hogy közel sem nyújtanak a maiak akkora gyakorlati előnyt, mint ahányszoros a számítási kapacitásuk, s ebben a software-esek keze vaskosan benne van.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem is értem miért vetsz össze egy minimál kiépítésű 8 bites mikrogépet egy 32/64 bites pécével. Erről nem volt szó. A sin(x) egy mai, akár több fpu-t tartalmazó gépen nem gond.

A pici gépekre meg jó tréfa az Iron Sky, amiben okostelefonnal irányítják az űrhajót. ;) Megtehetik, hiszen milliószor nagyobb a számítási teljesítménye, mint az AGC-nek. A holdra szállás szkeptikusok meg mitsem értve ehhez, megkérdőjelezik a holdra szállást az alacsony számítási teljesítményre hivatkozva.

No, de mi a túlzás?

Ok, számoljunk!
Egy i8080 2MHz, egyelőre a "másik"* 4,2GHz: 2100x
Egy utasításhoz szükséges órajelek száma (átlagosan) 7 - 1: 7x
Egy ciklus alatt végrehajtott utasítások száma 1-6*: 6x
INT méret 8-32, legyen: 2x
Magok száma 1-8: 8x

Ez idáig: 1.411.200

* A "másik" cpu itt üldögél a szomszéd szobában, és 14 éve nem gyártják: IBM POWER4+
A csalások:
- A régi cpu csak 1,2GHz-es, megelőlegeztem neki a manapság egyáltalán nem kiugró 4,2GHz órajelet.
- Szintén megelőlegeztem a 8 magot és nem vettem figyelembe a "multiprogramozási veszteséget", bár jobb helyeken a multiprogramozás (pl. hyperthreading) vesztesége már régen 0.
- Nem vettem figyelembe, hogy a pc korszak kezdetén általában direktvideót használtak, míg a mai rendszereknél a gpu tehermetesíti a cpu-t.
- Az INT méretet 32 bitre 2x szorzóval vettem figyelembe. Ezen lehet vitatkozni, de manapság úgy is a 64 bit a divat. Valamint ->
- Szó sincs az egy utasítás hosszánál:
-- Az egy fpu utasítás elég sok 8080 utasítást ér.
-- Elég régen használnak altivec (MMX, 3Dnow!, stb.) egységet, ami órajelenként és magonként több utasítást képes egy órajel alatt végrehajtani.
-- Azt, hogy manapság a crypto engine, meg még jó néhány turpisság is teljesen természetes - már meg se említem. ;)

Szóval az 5M szorzót úgy is lehet érteni: nagyon-nagyon minimum. :-D
Ha úgy tetszik, a 4,7MHz-es pécét is veheted alapul, mert azzal is bőven el lehet érni ezt az arányt.
Legalábbis POWER platformon. Az Intel meg sokkal jobb, mint az IBM (egyes újságírók szerint), tehát biztosan! XD

Nem akartam egyből bézbólütővel jönni, ezért választottam egy 14 éves szerkezetet:
Ez egy kicsit jobb: https://en.wikichip.org/wiki/ibm/microarchitectures/power9
Itt is van altivec, de már régen sem volt bekötve a cpu-ba.

Ezzel már talán a 100M+ is bőven összejön, de nem tipikus desktop. ;)

A kedvecem az esemény-lavina. Pont most fogtam egyet. A vicc az, hogy a mai gépek annyira erősek, hogy sokszor észre sem vesszük - fejlesztőként - az ilyet. Főleg, ha mondjuk egy i7-en fejlesztünk kis adatbázisokkal, és aztán élesben egy Atomon futtatják nagy adatbázissal. Persze ha komoly dologról van szó, és mérünk meg minden, akkor nehéz benézni, de ha csak valamit gyorsan összeütünk, akkor előfordulhat.

A lényege az, hogy a mai GUI objektumoknál bevett gyakorlat, hogy listenereket aggatunk az értékekre: például ha megváltozik egy css bejegyzés, akkor újra kell rajzolni az általa érintett egyéb objektumokat. Ha a kiválasztott elem változik - pl egy listában a leveleink - akkor a hozzá tartozó információt - előnézetet - befrissítjük.

Na most ha nem vigyázunk, akkor lehet olyanokat csinálni, hogy egy változás miatt újrarajzolunk egy egész fát, de az újrarajzolás minden lépésére újrarajzolunk egy kisebb fát, aminek minden ágára újrarajzolunk egy ikont. (Persze vektorosan nagyfelbontásban, amit aztán leskálázunk kicsire, mert úgy a leghatékonyabb).

Ilyen módon simán lehet a modell elemszámával szorozni a futásidőt akár kétszer háromszor is. (n négyzet, n köb futásidő megvan egy pillanat alatt) Az ilyen gyakorlat alá lehetetlen elegendő vasat tolni. Ezzel még Moore is alig tudott versenyezni, és most hogy vége van, muszáj újra megtanulni programozni :-).

Á, ez nem esemény-lavina. Hanem az a hibahalmozási eset, amikor
- a fejlesztő gépe a leggyorsabb, és
- nem valós adatokon,
- nem a tényleges adatmennyiséggel dolgozik.
Az éles rendszer sebessége számítható. Nem is kell GUI, meg ilyen bonyolult felépítés ahhoz, hogy valami tényleg lassan fusson. Annak idején a "pécémen 100.000 adattal lefut..." számszerű értéke soha nem érdekelt, és nem is vettem át üzemeltetésre.

Abban nagy igazságod vagyon, hogy meg kell tanulni programozni. Aki nem tud, az i7 nélkül fel fogja adni, és nem fogja befejezni a munkát. A rutinos versenyző már előre elkerüli az önszopatást. ;)

Igen, de ha van egy algoritmus, amiről tudom, hogy lineáris, és tudom, hogy adatom nem lesz több 1000-nél, és mindez nem kritikus helyen fog futni, akkor előfordul, hogy nem mérek - értsd próbálom ki :-) - lassabb gépen. Mert minek, ha egy 8086-oson is elfutna kellemes tempóban? Kivéve, ha van egy eseménylavina, amire épp nem számítottam :-P

Erre még mindig áll a fenti dolog. Már megint nincs kedvem dolgozni, ezért mesélek két példát.

Hasonló elvekkel írtak meg egy programot és futtattak egy programrendszert. Az eltérés csak annyi, hogy 1000 helyett 3M adat és napi működés volt az előírás. A program egy formátumkonverter előtét volt. A teljes programrendszer tartalmazott néhány sort jellegű műveletet is, ami több szegmensre darabolt adatokkal (a sort így működik) szintén lineárisnak tekinthető. Az eredeti futásidő 4 óra körül alakult.
Telt-múlt az idő, és az adatok néhány százalékkal bonyolultabbak és lassanként több mint kétszer annyian lettek...A futásidő meg "lineárisan" tartott a napi 120-130 óra felé. ;)
Átraktam egy 4-8x gyorsabb gépre a cuccost. A főnököm megbízta a tojáshéjas új kislányt a 19 órás konverter program újrakomponálásával és csiszolgatásával. Specifikáltam a feladatot és az eszközöket, valamint az új gépen futtatott cat jellegű programmal végzett sebességmérés alapján a 19 óra helyett - az adatok harmadára =2M - 14 perces futásidőt. Azért is, mert a megnövekedett adatmennyiséget bizonyos korlátok miatt már 3 részre kellett osztani. Ez a felosztás az addig lineáris működésű sorttmp területet négyzetesen lassítja, tehát kicsit hangolni kellett a diszkeket. Az előállított adatok vidéki telephelyekre terjesztését is módosítottam 3-4 óráról 8 percre. A végeredmény stabil 2 órás futásidő lett, ami a 130-hoz képest nem is olyan rossz. :)
Az adatmennyiség további növekedése és az idő vasfoga miatt meglépett újabb gépcserénél a számított futásidő 17 perc, a mért 12 perc lett. Igaz, ekkor már 5 szegmesre kelett osztani a 6->14M adatot.
Szerintem nem túl gyakori az olyan megoldás, amikor az adatmennyiség nő, a gép is gyorsul és a futásidő csökken. ;)

A másik példa pedig nem az offline feldolgozás területe. Az alap egy sybase karbantartó rendszer, 30-50 felhasználó és napi adatexport. Az egészet több öreg profi tervezte. Az adatbázis mérete 1GB + 3GB "játszótér", amelyhez 256MB memória is kell. Az export ideje 2 óra. Hozzáértő szakember (matematikus, aki 10 évig vitte a rendszert) el is magyarázta, hogy ez egy cat szerű művelet, nem igazán lehet gyorsítani.
Nosza, modernizáljuk a rendszert a szabványos eszközökkel, és irdatlan mennyiségű erőforrással!
(Hülyevagynemérteszhozzá! Az óra-kell, meg a táblaterek... :))
A végeredmény elég jó lett:
- A hardver 22x gyorsabb.
- A diszk és ram mennyisége leírhatatlan. ;)
- Alkalmazásszerver, korszerű felépítés, vékony kliens, nagy biztonság, stb.
- A munkavágzés sebessége az eredeti töredékére lassult. A felhasználók több perces várakozások mellett dolgozhatnak.
- Az export idő 2->19 óra. Magyarázom: belelóg a munkaidőbe, ami alatt a felhasználók malmoznak. Bár ez egy agy nélkül betervezett tűzfal elhagyásával 11 órára csökkent. Igaz, néha megvadult és akkor a futásidő értéke beláthatatlan lett. :-D
- A költségek 300->1500MFt és a rendszer még nem készült el.

Hosszabb ideig dolgoztam külsősként a cégnek. Véletlenül mindig akkor tárgyaltam a főnökkel, amikor megjelent egy emberke: Írd már alá a memóriabővítést! :-D
A fenti projekt rengeteg üde színfolttal rendelkezett. A projektet országos hírű szakember vezette, az egyetemen adatbázist tanított! A pörformanszra* vonatkozó aggályaimat rendre, gúnyos magyarázatokkal le is szerelte. (Én meg az elmúlt 10 évben az adatbázisszervert üzemeltettem, hangoltam.) A későbbiekben kiderült, hogy a jelenlévő 30 főből a tender címét csak hárman ismerjük. XD

* Columbo felügyelőnek magyarázzák: Tudja, olyan pörformansz! Amikor a színpadon belehugyozik egy pohárba és utána megissza.

Mi ebből a tanulság? Az üzleti siker nem mindig párosul a kielégítő működéssel. A fiatalok nem buták, - hiszen egy ilyen kijelentés az emberi jogaikat sértené :) - csak nem tanulták meg az alapos munkavégzést. Ebben pedig semmi hiba, hiszen nincs is rá szükség.

Túl sokat emlegettem a catot. ;)
Ezzel csak a lineáris feldolgozás elméleti sebességét mértem, amit még szorozni kellett a szoftver "lassító hatásával".
A diszk sebsességét nyugodtan lehet szorozni 10-12 értékkel, mert a feldolgozás
- külső zónán,
- tükrözve 2 diszken, a sort 3 diszkes bufferre optimalizált stripe, és
- tömörített inputból ment - aminek a kifejtési ideje gyakorlatilag 0.
A tömörített adat általában "éppen most érkezett", ezért feldolgozáskor inkább a bufferben tartózkodott, mint a diszken. Ha ehhez hozzáveszed az 1,8GB/s memória sávszélességet, akkor még 1996-ban is elég gyorsan lehetett catolni. ;)

Már megint nincs kedvem dolgozni...

Látod-látod, az AIX-esek :-D

Viccet félretéve: az a különbség köztünk, hogy más problémákat szeretnénk megoldani. Azokat a problémákat, amelyeket a threadben felvetsz (pl. relatíve sok, de egy gépen belül elférő adat rendezése hatékonyan) bizonyára pont úgy kell megoldani, ahogy írod. Működik is jól, amíg:

- elfér az adatmennyiség a gépedben és/vagy a környékén (mondjuk néhány terabyte méretekig)
- a géped nem romlik el (azért nem teszed a vacak x86-ra az alkalmazást a kiváló Power helyett, mert gyakrabban romlik el).

Próbáld meg megoldani ugyanezt a problémát a gépeddel akkor, amikor az adatmennyiség mondjuk petabyte-okban mérhető. Egyáltalán nem lesz lineáris a sort algoritmusod, szűk keresztmetszet lesz pl. a processzorok darabszáma. Persze adódik a megoldás: több gép kell, szét kell osztani rájuk a terhelést. Az algoritmus ugyanaz, mint a sort mögött, csak most úgy hívják, hogy MapReduce és nem több processzorra, hanem több gépre tolja szét a terhelést.

Viszont ha ez így meg van oldva szoftverből, akkor miért is kell a nagyobb megbízhatóságú és drágább Power gépeket venni az x86-ok helyett? Ööö, nem kell. Olcsóbb, jobb, hatékonyabb.

És visszatérve az eredeti méretű problémához: ha van egy olyan jól működő módszer, amellyel akár három nagyságrenddel nagyobb méretű adatokon bizonyíthatóan működik minden, és nincs hátránya kicsiben is úgy csinálni, mint nagyban, akkor miért ne csinálnánk kicsiben is úgy?

Egy helyen egyébként feljebb csúsztattam. A Power gépek, amelyekkel találkozok a munkám során (E870-ek, 30-40 processzorral, 1-2 TB memóriával, van belőlük 3 db) konkrétan több gondot okoznak az üzemeltetésnek, mint pl. (az egyébként tényleg vacak) HP DL460c-k. Két okból:

- az egyik, hogy gyakrabban vannak hülye hibái a Power-es gépeknek (pl. failoverelt a storage? akkor megállok...), amelyet hogy-hogynem általában egy firmware frissítés javít meg (olyan, mintha nem kapna elég gyakorlati tesztelést a platform, és elméletem szerint a piaci elterjedtség alacsony volta miatt pont ez is van)
- a másik, hogy ha elveszítesz egy vasat (egy alkalommal fordult elő 4 év alatt), akkor elveszítetted az infrastruktúrád harmadát, ami fájdalmas (ellenben az x86-os blade-ek tényleg gyakrabban halnak meg, de pont nem fáj egyáltalán, ha elveszíted az infrastruktúra 0.3%-át...)

Vagy egy szavazásba vagy az itteni blogomba mindjárt csinálok egy kapcsolódó folytatást...

"Ez alatt természetesen nem azt értem, hogy nem tévedhetett egy ember, hanem a produktum nem tartmalazhatott hibákat."

Persze, ezért sípolt folyamatosan Apollo 11 leszállása közben a hibajelző, mert "régen minden jobb volt". :)

"A C++ már igazi tömegek számára biztosított munkát."

A C++ konkrétan az egyik legbonyolultabb programnyelv. Bár tény, hogy bizonyos dolgokra jobb absztrakciót adott, mint a C.

"miközben ugyanazt a feladatot legalább egy kicsit lassabban végzik el."

Kérdés, hogy hol húzod meg ugyanazt a feladatot. Szöveget lehet beírni egy dobozba? Szöveget lehet beírni egy dobozba, ahol automatikus helyesírás-ellenőrzés van és már a végső, nyomtatásban megjelenő formázási állapotával együtt látod? Mindkettő "csak" egy szövegszerkesztő.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nem ártana elolvasnod miről beszélsz. ;)
A szoftver pont jó volt, csak elfogyott a 64GB ram. :-D Különösen szép, hogy Win95 példa is van a végén.
Ugyanezt a FejlettFirefox olyan automatikusan oldja meg, hogy kiveheted a pipát - ha tudod mi szállt szét. Esetleg korábban feldob egy ablakot: Az oldalon script fut, de qrvalassan. Micsinájjak? (Futtasd gyorsabban!)

A C++ -ról véletlenül Bjarne Stroustrup egy mondatát idéztem. De nem ez volt a lényeg. Az úgy látszik nem jött át.

Példádban az "ugyanaz a feladat" legyen szövegbevitel. Manapság egy igen gyenge gép tőlem közben lefordíthatja akárhány nyelvre is. Rendelkezésre áll a technológia és elegendő erőforrás, hogy a szövegbevitel ne legyen lassabb. De nem így van.

És még meg is magyarázod: Ez az 1000LE teljesítményű autó azért megy feleolyan gyorsan, mint egy trabant, mert cédét is tud játszani. KETTŐT! :-D

Példádban az "ugyanaz a feladat" legyen szövegbevitel.

Nade nem ugyanaz a feladat. Bemész a boltba, és lassan már nem nagyon tudsz fullhd alatti felbontású monitort venni (vagy ha igen, azt nem akarod megvenni). Ergó az átlag felhasználó bizony a 25 évvel ezelőtti felbontásnak az n-szeresével nézelődik. Szigorúan grafikus felületen (ellentétben a 25 évvel ezelőtti átlaggal). És ha pixeles fontot tolsz az arcába, akkor még el is hányja magát, hogy mi ez a fos... Tehát míg 25 évvel ezelőtt 3 assembly utasítás volt kirajzolni egy betűt a DOS képernyőjére, ma az antialiasolt fonttal a betű kirajzolásán még a GPU is megizzad. Mert az "ugyanaz a feladat" valójában sokszorosára nőtt. Nőttek a lehetőségek - nőttek az igények is, sokszor öntudatlanul. Én sem szeretnék pixeles fontokat nézegetni ma már...

Az autós példa amúgy nagyon jó: már senki nem nagyon vesz 100 paci alatti autót - miért? mert min. 300kg-val nehezebb az átlagos autó a 25 évvel ezelőtti állapotokhoz képest. Mert valahová el kellett rakni a sok vasat, ami a töréstesztek szintén jogosnak tűnő igényei miatt kell. Ugyanaz a feladat? Hát igen, a-ból b-be... közben meg nem, mert időközben megnőtt az az igény, hogy egy átlagos balesetben ne dögöljön már meg számottevő eséllyel a fél család. Ja, és közben lehetőleg pöfögjön (= fogyasszon) kevesebbet a gép, mert megfulladni sem szeretne az emberiség.

Ebből is pont az látszik, hogy a hardver támogatás létezik. A 3 utasítás ideje alatt lefut (jó néhányszor) az a néhány száz utasítás, ami a mobilokban is jelen levő gpu felé tolja a feladatot.
Így időben ugyanott vagyunk, amikor ki kell írni egy karaktert. Továbbra is marad a kérdés, hogy a 3 régi utasításnyi időn kívül (az i8080 "néhány százezer" utasítás/s) mi a rosseb történik az 5Mx gyorsabb hardveren - amitől lassabb lesz?

Én teljes mértékben értően olvastam. Arról volt szó, hogy három assembly utasítás kirajzolni egy karaktert. Ja, hogy az a három sor egy függvényhívás, ami elvégzi a feladatot? Ja, akkor ennyi erővel bármilyen nyelven kiírni egy karaktert egy sor. Ami ugyanúgy egy függvényhívás. Ez mindössze ennyiről szól. Minden mást már te képzelsz hozzá.

--
https://iotguru.live

A karakter kiíratás az int10h volt. És ez, amit betettél, nem három utasítás, mert az int 21h (vagy az int 10h) egy eléggé terjedelmes kódot futtat. Az int 10h mögötti megszakításkezelő rutin forrása 2000 soros ass kód. Az int 21h mögötti kód ennél nagyságrenddel hosszabb.

Még annyit, hogy az int 21h az szoftveres megszakítás, míg az int 10h az hw-es volt, ha jól emlékszem...az int 21h 9h funkciója egyébként az int 10h megszakításkezelővel rakosgatja ki a karaktereket. Tehát az int 21h (vagy 10h) valóban egy utasítás...de csak egy kódot hív, mint a call pl.

Gondoltam szólok.

Az int10 BIOS hívás, az int21 DOS rendszerhívás. Mindegyik szoftveres, és funkcionálisan megfelel a következőnek: 

                PUSHF
                CALL vector (0..255)

Ez meg a "3 soros" program töredék, ami közvetlenül ír a video memóriába, monokróm vagy egyéb (CGA, VGA) képernyőre. (A teljesség igény nélkül.)
- a karaktert és az attribútumot beírja a video memóriába, a pointerét inkrementálja és menti
- inkrementálja a kurzor pozíciót (SET_CP) - de ez nem szükséges
Mondjuk a scroll és hasonló finomságok hiányoznak. 

                mov     ah,ATTRIBUTE
                mov     al,CHAR
                les     di,dword ptr VIDEO_OFFSET
                stosw
                mov     VIDEO_OFFSET,di
SET_CP:
                mov     dx,CRT_INDEX            ; MDA/EGA reg index
                mov     al,CRT_R14              ; cursor position hi
                out     dx,al
                inc     dx
                mov     ax,VIDEO_OFFSET
                shr     ax,1
                xchg    al,ah
                out     dx,al                   ; MDA/EGA indxd data
                mov     al,CRT_R15              ; cursor position lo
                dec     dx                      ; MDA/EGA reg index
                out     dx,al
                inc     dx
                xchg    al,ah
                out     dx,al                   ; MDA/EGA indxd data
                mov     ax,VIDEO_OFFSET
                shr     ax,1
                div     ROW_SIZE
                xchg    ah,al
                mov     CURSOR_LOC,ax

Nagyjából hasonló áll az int10 mögött (bár ez nem az). Az int21 először dekódolja a hívást, majd hívja az init 10-et egyszer vagy többször.

A DOS és BIOS megszakítások kódja lehet hosszú, de csak ilyen rövid kódrészletek futnak. Ennek ellenére a "3 utasítás" nem nagy túlzás akkor sem, ha 53. Az is hamar lefut.

Nagyjából. Csak jóval több, mert először megnézegeti a video hw típusát, beállítgatja a paramétereit, címeket, anyjakínját, stb., lekéredezi az aktuális videomódot, a kurzor pozícióját a lapozható videómemória esetén az aktív lap címét...stb...

Az az 53 is inkább egy nagyságrenddel, de lehet hogy kettővel több...ami már számít. Vagy ha ilyen lazák vagyunk, akkor tényleg a java egy utasítással ír a épernyőre.

Ez nem így van. Az alapadatokat gyakorlatilag a BIOS biztosítja, amit elég egyszer megkérdezni. 

VIDEO_SETUP     proc
                mov     ah,0f
                int     10                      ; get state, al=mode, bh=page
                mov     ORIG_VIDEO_MODE,al
                mov     ah,12                   ; check for VGA
                mov     bl,10
                int     10
                cmp     bl,10
                je      NOVGA
NOVGA:
                cmp     ORIG_VIDEO_MODE,MONO_MODE
                jne     COLOR_CARD
                mov     VIDEO_SEG,MONO_SEG
                mov     VIDEO_MODE,MONO_MODE
                jmp     TEST_CFG_EXIT
COLOR_CARD:
                mov     VIDEO_SEG,COLOR_SEG
                mov     VIDEO_MODE,COLOR_MODE
... és így tovább még egy oldalon keresztül...

Kikérem magamnak! Én csak állítottam valamit rutinból. Aki vitatkozott, az Te voltál. :)

A linkelt biosban a karakter kiírása mindennel együtt lineárisan 104 utasítás - ezek szerint ennél lehet egy kicsivel kevesebb is. A hívás előkészítéssel együtt kb. 107. Ez azért elég messze van a bepoénkodott 53 x egy-két nagyságrendtől.

A bemásolt kódrészletek egy bios extension-ként, vagy dos programként is futó Wyse60 terminálból származnak, amit - mivel nem általános feladatra készült - kicsit gyorsabbra írtam biosnál.

Aztán egy bios nem csinál nyarat. A rengeteg gyártónak rengeteg féle, akár az IBM specifikációnak nem megfelelő biosa van. Néha meg pont az IBM nem kompatibilis önmagávl. ;)

Nos, nem. A karaktert az ember a videómemóriába írással rajzolta ki. Karakteres üzemmódban egy betűt egy word beírásával lehetett megjeleníteni. Ez sorfolytonos megjelenítésnél a kiírandó adat betöltése (ideális esetben 1-2 utasítás), plusz egy szál stosw. Az előkészítés (szegmensregiszter feltöltése: 2 utasítás, címregiszter beállítása: 1 utasítás) sem egy "ökör ára", és az csak ritkábban kell.

Ez az int 21h-s, de még az int 10h-s amúgy fényévekkel lassabb volt.

Ez egészen a cga kártyákig volt igaz. A VGA megjelenésével viszont már kénytelen voltál az int-eket használni vagy a hordozhatóságról lemondani. A direkt írás addig volt menő, amíg nem létezett más videomemória cím, mint a B800h és a C800h (ha jól emlékszem). A VGA megjelenésével viszont annak saját biosa is működni kezdett...

Régen volt, kopott már ez a dolog sokat. :D

Karakteres std módokban nem külöbözik a VGA az egyszerűbb kártyáktól. A video memória címet meg az aktuális lapot (képernyőt) meg lehet szerezni, utána megy minden a megszokott módon.

A probléma akkor kezdődik, amikor egy direktvideós pc programot raksz át terminálra. A terminál optimalizálóhoz nem jut el az információ és mindig meg kell fejtenie mi történt. Ilyenkor a képernyő részlet megváltozása helyett gyakran törlődik, majd újraíródi az egész kép. És ez bizony nagyon csúnya a soros vonal alacsony sebessége miatt.

A standard DOS konzol CGA-kompatibilis karakteres módban ment, és én pont erről beszéltem (az átlag karakteres DOS-os program is pont ezt használta - mondjuk ha Turbo Visionben írtál valamit :-)

A palettás, 8-bites grafikus üzemmódban (ilyen ugye egy volt a standard VGA-ban) is lehetett hasonlóan direktben írni a memóriát, csak ott már egy pixel volt egy byte, ergó egy karakterhez sokkal több adatot kellett beírni...

Én nem igazán látom, hogy a "pl. a fű legalizálásáért, homoszexuálisok jogaiért" harcoló mozgalmak miben akadályoznák a "tanulást és a világ megváltását".

A tanulás többnyire szabadon hozzáférhető. Még ha az iskolai oktatás fizetős is, de az interneten szó szerint mindent megtalálsz, mindenhez _is_ találsz tananyagot ami a nulláról kb. egyetemi szintig elvisz, ingyen.
A világmegváltás pedig, hát az eléggé szubjektív. Vannak akik számára ebbe beletartozik az, hogy nem tiltanak neki olyan dolgokat, amivel senkinek se árt.

++ ahogy már írták is, Linus-nak meg se fordult a fejében a "világmegváltás", ő csak egy unix-like OS-t kezdett el farigcsálni hobbiból, mert meg akart ismerni egy procit.

( bucko | 2018. 09. 30., v – 13:55 )

Egy-két dologgal azért én magam sem értek egyet, mint például amikor a Windows 95 és a Windows 10-et olyan egyszerűen hasonlítja össze, hogy mind a kettő ugyanazt csinálja mégis 133-szor nagyobb a 10 mérete.

Ezt egy kicsit körülírhatnád!

Segítségül: Egy XP kb. 3GB. Amit használok, az pedig csak 1GB + >1GB utility.
A 10 éve, elég trehány módon belakott rendszeremnél a WINDOWS=3GB, a Program Files=11GB.
Bár itt azért anyai-apai is fel van még rakva. ;) (Fejlesztőrendszerek, toolok, driverek, stb.)

Érdekességképpen megnéztem, hogy a kb. fél éve telepített Windows 10-es PC-men mekkora könyvtárak vannak:

- Windows --> kb. 26 GB, ebből pl.:
--- WinSxS --> 9 GB (ez a Windows komponensek régi és aktuális verzióit tárolja - a régieket kipucolva kb. 4 GB maradna belőle)
--- System32 --> 8 GB (ez maga a rendszer, a legnagyobb része a 3.5 GB-os driver gyűjtemény)
--- SysWoW64 --> 1.6 GB (az előző kettő kombinációja :-p)
- Program Files (több könyvtár) --> 14 GB, ebből a legnagyobb:
--- NVIDIA Corporation --> 3 GB (videókártya driver és hozzá kapcsolódó dolgok)

Ez összesen valami 40 GB körüli rendszerméretet ad. Egy ekkora SSD-t kb. 8 ezer Ft-ért lehet kapni tetszőleges boltban. Ekkora HDD-t nem lehet kapni, csak tízszer ekkorát.

Akkor miért is érdekeljen a dolog?

Mert ezt az adatmennyiséget mozgatni is kell, nem csak tárolni. No, nem egyszerre. Azért az nVidia 3 GB elég erős. A nouveau Linux driver 600 kB nagyjából. Tartozik hozzá kb. 2 MB firmware is, de ez az összes hardware-re vonatkozik, egyszerre csak egy kell belőle. A Xorg részéről nem tudom, mennyi még, de hasonló nagyságrendre számítok.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Vigyázz, ez nemcsak a driver, hanem a körülötte lévő cuccok is. Mindenféle nagyfelbontású képek, videók (!), nagyméretű logok és hasonlók is vannak közöttük. Jó kérdés, hogy ezekre van-e szükség, és az a gyanúm, hogy kicsit odafigyelve fel lehet rakni ezek nélkül is a drivert. Ezzel spórolnék 3 gigát (400 Ft), cserébe befektetnék 5 perc munkát. Ennél jobb az órabérem, ennyiért nem dolgozom, és másnak sem célszerű...

A múltkor szedegettem össze egy HP-s laptop drivereit. Nem értettem, hogy a toszba lehet a touchpad drivere 200MB! Hát, voltak benne helyes kis Windows Movie File-ok, amik olyan nevekkel rendelkeztek, hogy balegérkattinás, jobbegérkattintás, scrollozás, meg hasonlók. Nem néztem beléjük, de biztos van valami GUI, ahol ezeket a műveleteket videó formájában mutatja meg a driver (mellé csomagolt progi), hogy a clueless felhasználó tudja, hogyan is kell használni egy szaros touchpadet. Na ettől lesz egy fostos touchpad driver 200MB B+

Mozgatni alatt mit értesz? Gigabites hálót kapok valami 4800 Ft/hó pénzért (Digi), az USB3-as vagy USB-C pendrive még gyorsabb, a diszken belül majdnem 1 GB/sec-cel tudok másolni. Ehhez képest nem méretek ezek.

Túl kell lépni azon az időszakon, amikor a PC egy drága és megbízhatatlan XT volt, béna MS-DOS oprendszerrel. Ha ma bemegyek egy Tesco-jellegű boltba és megveszem az első kezembe akadó PC-t 100 ezer Ft alatt, akkor is röhögve elbír ezekkel a mennyiségekkel. Ha értek hozzá és odafigyelek, hogy mit veszek, akkor meg még kevesebb gond adódhat...

Épp erről a hozzáállásról szól ez a topic. Az egy nagyon destruktív szemlélet, hogy a hardware elég gyors, a RAM meg a háttértár elég nagy, ne foglalkozzunk semmivel, ne számoljuk ki, pontosan mennyi RAM kell, foglaljunk le egy 10 MB-os blokkot, abba majd belefér ez a string, ami általában ugyan 5 karakter, de néha lehet nagyon sok is. Valahogy nem nagyon látom azt sem, hogy valaki ns-okban számolna kritikus helyen futásidőt. Legalább ott, ha máshol nem is.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Azért, mert a minőség rovására megy mind sebességben, mind tárhelyben. Ez ugyanaz az igénytelenség, amely máshol is tettenérhető, s a kapitalizmus következménye. Nagyjából a fogyasztási kényszer, pazarlás, környezetszennyezés. Mindent feláldozunk a gazdaságosság, a pénzügyi sikerek oltárán, s nem akarjuk észrevenni, hogy a gazdaságnak kellene szolgálni az embert, az emberi életminőséget, nem pedig az embernek a gazdaságot.

Jut eszembe, középiskolás koromban ZX Spectrumra Z80 assembly-ben 1313 byte-ban írtam meg egy Tetris játékot.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Megvannak. :D
En csak az ordog ugyvedjet jatszom ebben a topicban, ahol a bloat a tema. En meg megirom, hogy neha miert kell a bloat. Hogy egyszeruen hasznaljunk dolgokat, vagy mert ez a business igeny es kesz. Tetszik nem tetszik gyorsan es olcson kell szart lerakni az asztalra. :D

Aham!

Pont erről szól ez a topic.

Régesrég készítettünk egy terminálos rendszert. Kikértük egy okos ember véleményét a soros vonal sebességéről. Bizony, 9600bd volt a javaslata. Ha belegondolsz, 20kbd a sebességgel 1s alatt tele lehet írni az egész képernyőt, de a terminálon nem így működnek. A releváns adatok cseréje a másodperc töredéke alatt megtörténik. Csak gondolkodni kell!

Az a tény, hogy a fb képtelen működni kevesebb erőforrással nem igazán a fejlődés jele.

Az FB-nek van azért némi hozzáadott értéke egy terminalon megjelenő szöveghez képest. Jelentősen több információt nyom az arcodba egy képernyőn (pl. képeket), ehhez pedig tényleg több/jobb/gyorsabb gépezet szükséges. Ami nem is baj, mert ez a gépezet létezik, és még olcsóbb is, mint annak idején a terminal volt...

Nem is a terminált hasonlítottam össze a fb megjelenítéséhez szükséges erőművel.

A Monte Cristo grófja három kötetben 1 floppy szinte bármilyen formátumban. Ugyanezt az információt filmként is meg tudom jeleníteni akár streamelve is. A fb meg egy weboldal.

A gépezet olcsó. Az átlagfelhasználó véleménye: Már megint lassú a fb!
Azt persze tudjuk, hogy inkább az átlagos gép a lassú. A technológia nem képes kiszolgálni a felhasználói igényeket a technológia miatt. Kérdés?

Az AIX a saját memóriája helyett a Te agyadat használja. Az összes egyáltalán nem intuitív korlátozását a fejedben kell tartanod, ahelyett, hogy egy intuitívabb réteget alakítanának ki rajta. Az általa kiadott adatok általában tömörek, és a dekódolásukhoz gondolkodni kell.

Ezekkel mindig az a baj, hogy az "átlagember" nem tudja/akarja használni az agyát. Lehet sírni, hogy milyen rossz az élet amiatt, hogy ez így van, de én pl. nem szeretek ilyesmi miatt sírni. A világ egy ilyen egészen kegyetlen hely, és az optimális megoldások általában azok, amelyek a világ valóságát figyelembe veszik.

Rossz gondolat!
A divatot, irányzatokat nem lehet meghágni. Már Az összes egyáltalán nem intuitív korlátozását a fejedben kell tartanod... kijelentésre sem volt értelmes válaszom. Talán nem is értettem. Adva van egy olyan rendszer, ami több unix-féleség lehetőségeit tartalmazza. Ehhez társul egy olyan flexibilis kezelési lehetőség, amelyet más rendszerek meg sem közelítenek. A linux látszólagos flexibilitása mögött meg nincs tartalom és hardver. Aztán ott van az ipari szintű megbízhatóság, meg - ahogy manapság mondják ;) - skálázódás. Végül megemlítem, hogy az AIX az egyik legjobban dokumentált rendszer, amit idáig láttam. Ami alulról közelíti, az talán a RHEL. Mindenesetre csak a közel 20 éves AIX fejlesztői és üzemeltetői pályafutásom alatt részesültem abban a felhasználói élményben, hogy leülök és megoldom a feladatot. Mondom ezt annak ellenére, hogy előtte, alatta és utána is dolgoztam linuxon, sőt sco-n is.

A tök nehéz és drága embert találni az üzemeltetésére kijelentésben is van némi igazság. Nyilvánvalóan a linuxon és windowson szocializálódótt emberek között nem fogsz AIX üszemeltetőt találni. Ezek az emberek megszokták a kevésbé hatékony, bizonytalan kimenetelű munkavégzést. Természetes számukra, hogy megbízható dokumentáció hiányában fórumkat bújva jutnak hozzá a munkavégzéshez szükséges információhoz. Számukra még az sem újdonság, hogy egy frissítés után nem áll fel a gép - hiszen ez az élet része. És ez is a TCO része, pro és kontra módon is.

( cus | 2018. 09. 30., v – 14:04 )

Ugye programfejlesztéskor nem az efficiency, simplicity, and excellence a legfontosabb szempont, sokkal inkább a gazdaságosság, karbantarthatóság és a gyors fejlesztés. Szóval az előbbieket elvárni minden programozótól, amikor nem az a cél, naivitás. Ráadásul biztosan nem igaz, hogy nem kell géniusznak lenni, hogy gyors, egyszerű és szép kódot írj. Még a géniuszoknak sem megy gyakran csak kettő a háromból...

A probléma valós, de nem attól fog megoldódni, hogy rácsapunk az asztalra. Inkább arról kéne írni, hogy mitől változhatna ez meg, ha egyáltalán.

Ja meg hát szoftvert nem a szépségért szokás írni, hanem a business igényekre, ott meg szokták a költségeket is nézni, stb. stb. Ha valaki az én igényeimre ír valamit, nem érdekel a kód szépsége, max ha feltétel ez is. Addig elég ha karbantartó olcsón, meg hordozható, meg főleg olcsóbb, mint a szuperszép kód.
El lehet polemizálni ezen, de a prigramozókat az üzlet tartja el, nem a szépművészeti múzeum tárlatán mutogatják a kódjukat.
A bloatról még annyit, hogy ma már mindennel is kompatibilisnek kell/illik lenni, ezt meg nehéz 20 sorban megcsinálni.

Ez meg legyen a megrendelo baja. Ha o kifizeti, hogy az igy behuzott komplett framework miatt az alkalmazas lassabb lesz, hat tegye. Lehet ezzel viszont lerovidul a fejlesztes ideje egy-ket nappal, ami erosen sok penzt (is) jelnethet.
En uzleti szempotnok szerint nezem az alkalmazasfejlesztest. Neked masok a szempontjaid.
Mint alkalmazasfejleszto lehet jo is az, ha jon a dephell, mert tudok supportot adni. Meg egy uzleti szempont. Lehet nem is olyan idiotak am azok a fejlesztok. :D

( bb | 2018. 09. 30., v – 21:52 )

azért azt nem kéne elfelejteni, hogy azért ha valamiben sikerült előrébb lépnie a win7-10-nek, az a kompatibilitás. Pedig azóta sokkal több gyártó lett.
XP alatt azért ment a vadászat a driverekre, és elképzelhetetlen volt egy másik gépbe berakva működtetni egy Windowst mindenféle varázslatok nélkül.
Azért most túlnyomórészt megy.

Szerintem az MS legnagyobb púpja a visszafelé kompatibilitás, még ha már az elmúlt pár évben már azért fel-fel adna ezzel kapcsolatban elveket. Pl már nem kell IE6-al kompatibilisnek lenni, ami rég viszont rengeteg nagy cég MS (crm, navison) rendszereihez kellett.

XP alatt azért ment a vadászat a driverekre
Ez azért költői túlzás. Csak le kell tölteni a gyártótól.
Igaz, most már a rendszer magától kitalálja mit kell letölteni a MS-tól. Igaz, rosszabb esetben megbénul a wifi, a szoftverek fele, vagy aktiválodik az 1817-ben gyártott MS egér. Bár az is lehet, hogy csak rossz időben voltam rossz helyen. ;)

Másrészt bizonyos dll-ek úgy is a BIOS-ban vannak. (Remélem újat mondtam.)

Olvastam régen, hogy a winmodemek valójában csak A/D átalakítók voltak. Magát a modulációt/demodulációt pedig szoftver végezte - többnyire csak volna, mert akinek ilyenje volt, az úgyse használta vagy vett mellé egy rendes modemet :-P.

Persze meg lehetett volna ezt csinálni rendesen, egyszer elég lett volna írni egy működő szoftveres modemet, és ahhoz tényleg A/D átalakítóként - AKA hangkártya illeszteni a vasat, de ez csak egy álomvilágban működik így. A valóságban minden gyártó a saját driverébe tette bele a szoftver modemet, amik úgy-ahogy működtek Windowson, Linuxon meg leginkább sehogy.

Én 2003 környékén használtam ilyeneket, tudom akkor már ciki volt, de addigra egy erős géppel pont használhatóak voltak a connexant-os példányok. Volt amúgy a HSF mellett HCF példány, ami elvileg "csak" a soros portot emulálta szoftveresen és DAC mellett volt benne valamennyi DSP funkció is. Én elégedett voltam HSF-fel is, két hét alatt szedtem le az XP SP2-őt, de csak azért olyan lassan, mert 6-kor keltem és 7-ig volt kedvezményes a net, az FDM meg apránként lehúzta, közben még kicsit böngésztem is.

( asch v | 2018. 09. 30., v – 22:18 )

Jó cikk, sokmindenben igaza van. Szoftverfejlesztőként el kell gondolkodnom, hogy mennyire vagyok én is hibás.

( turul16 v | 2018. 10. 01., h – 10:55 )

Nem vagyok egyedul ;-)

A problema az hogy 16x novekedes tenyleg indokolt,
de valojaban 64x..256x szoros erroforras igeny van.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( gabrielakos v | 2018. 10. 01., h – 11:04 )

Elolvastam.

Van benne 1-2 értelmes gondolat meg egy csomó tévedés/baromság/csúsztatás.
Így aztán nem annyira jönnek ki a valóban jogos kritikák.

Szerintem amúgy a szakma akkor kezdett el lecsúszni amikor megjelent a php és a fejlesztése során használt ideológia.
Na meg az outsourcing se tett jót - ebből már kezdünk visszajönni talán.

--
Gábriel Ákos

( flimo | 2018. 10. 01., h – 11:42 )

Ezen rendszerszinten nem lehet változtatni. Mert tegyük fel MS ráállít tízszer annyi fejlesztőt a Word-re, cserébe kétszer gyorsabb lesz, tízszer annyiba kerül, és mellette nem jut ember Excel meg Outlook fejlesztésére. Így is programozóhiány van, és ez nem azon múlik, hogy ma hatékony kódot programozó lábbal keltem fel, hanem időn és azon, mennyi kész komponenst használunk fel. Ennyiféle informatikai termékre nem nagyon lehet jobbat, és azt a jobbat senki sem fizetné meg.

Hosszu a kifogas tar mi ;-)

A dolog az hogy a lassu szoftware rengeteg CI/QA timeot is elvesz,
azon kivul gyakran a tenyleges plusz ido raforditas csak +10..20% lenne.
Azon kivul, a feedback loop is hosszabb, lehet hogy egy 4 szer gyorsabb szoftware 4-edlei
a feedback loopot, 4-edeli a szukseges CI errofarasokat, es vegeredmenyben tobb featuret lehet
betolni ugyan azon ido allatt, mert kevesebbet varsz a `semmiert` .

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Inkább fordítva, 10-20% gyorsulás négyszer annyi ráfordítással. Mindezt úgy, hogy agilisek vagyunk, ami annyit jelent, hogy mindent megbecsülünk, de úgy hogy a nyakunkba liheg a PM, hogy csak kis számokat használjunk, mert szívbajt kap a megrendelő, utána meg a megrendelő a becslés alapján veri az asztalt. Jó, ha a legarcbamászóbb technical debtekre jut idő. Előző projecten tudtunk volna faragni havi cloud számlán pár ezer eurót, a költségek kb 10-20%-át. Jeleztük ügyfélnek, aki inkább fizette tovább a nagyobb havi számlát.

Igazából még a gépeken való spórolásnál is fontosabb, hogy az emberek munkáján is lehetne spórolni. Sőt! A fejlesztők munkáján, amiből kiindultunk, hogy az a drága.

Ha az alapok rendbe vannak rakva, akkor minden fejlesztő könnyebben dolgozik, sokkal produktívabb. Igazából ezekkel az újabb meg újabb layerekkel a fejlesztők erejét is pazaroljuk, nyilván nem lesznek attól gyorsabbak, hogy fogalmuk sincs mi történik a rendszerben, amin dolgoznak. Csak ez a projektek elején még nem nyilvánvaló, mivel prototípusokat még viszonylag gyorsan ki lehet köpni a rétegek egymásrarétegezésének módszerével.

Mondjuk nekem az első gépemen legalább fél percig indulgattak ilyenek, mint Word 97 meg Excel 97, most meg ha két másodpercet kell várni, akkor már azt mondom, hogy lassú.

De ugyanígy VC6, VS2008 vs VS2010+ Ég és föld az újak javára.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nekem is , de aztan 32MB RAMot lecserltem 128/256MB aztan jo lett, foleg a 2th inditas.
Win 9x (P1) idejen sok swappolas, ill lassu disk volt a problema, valamint a
dinamikus linkeles sem gyors aminek az aslr (vs prelink) sem tett jot.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( apostroph3 | 2018. 10. 01., h – 12:24 )

majd ha az számítástechnika is 6000 éves lesz, mint az építészet, vagy 2-300 éves lesz mint a gépipar, akkor lesznek olyan energia- anyagtakarékos struktúrák, mint azokban az iparágakban.

:Đ

Vannak már ilyenek bőven, nem ezzel van a baj.
Igény/pénz nincsen rá ugyanúgy ahogy építészeti és gépészeti csodákra sincs általában.
Az se kedvez a dolognak hogy az építészeti/gépészeti dolgok materiálisak (láthatóak és megmaradnak) az IT dolgok egyáltalán nem.
Az is tipikus IT-ban, hogy xy vezérnek a nagy projekt végén a szervertermet mutatják meg - mert az látványos és érthető - nem pedig a sokkal többe kerülő és szuperül összerakott bármit (ERP, workflow, whatever).

--
Gábriel Ákos

Plusz az építőiparban, gépészetben ami egyszerű, felesleges elemektől mentes az általában olcsó is, hiszen ahány példányt akarsz egy termékből, az annyiszor megy végig az előállítási folyamaton (itt segít, ha egyszerű) és annyiszor kell hozzá megfelelő mennyiségű és minőségű nyersanyagot biztosítani (itt segít, ha nincsenek benne felesleges elemek).
A szoftverfejlesztésben pont fordított a helyzet: minél univerzálisabbra, nagyobb tudásúra csinálsz meg egy modult, annál több helyen fogod tudni felhasználni (az újabb példány "ingyen" van), ezzel csökkentve az újabb termék előállításának költségét.

( Dolphy | 2018. 10. 03., sze – 22:12 )

Az utolsó mondatot kb teljesen feleslegessé tette a cikk elolvasását. :)

( NevemTeve | 2018. 10. 04., cs – 05:20 )

Mondjuk az köztudott, hogy a software célja és értelme a hardware erőforrások elpazarlása, ezt legjobban a híres Strupstrup-álinterjúból érthetjük meg. Vagy a leftpad esetből: tényleg külső komponens kell, hogy egy stringet elhelyezzünk egy mezőben?