A szoftveroptimalizációt hiányolja a százdolláros laptop atyja
← ElőzőOldal 2 / 2
Jelentkezz be a hozzászóláshoz.
Nem tudom, mit kell akkor ennyit senyvedni, ha nincs jó progi, Írjon ki a manus valami jó pályázatot,( a 100$l.top oprendszerére) és a készítõ(k) nevét megismeri így a világ.. akár még valami win-lin konkurrencia is lehetne belõle....
A bölcsek nem tudósok - a tudósok nem bölcsek Lao-Ce
#33
Persze, ezzel a magunkfajta bõven megelégszik. De a HC gamerek már 1-2 éve csak röhögnek az 1024x768-as felbontáson. És ahogy te is írtad, "ha jönnek a szörnyek...".
Nem tudom elfogadni, hogy az ember megvesz egy 400 ezres gépet amire 2 héten belül kiadnak egy olyan optimalizálatlan -bugos- progit, ami állóképeket képes produkálni esetenként.
Persze igazatok van... pénz, pénz, pénz... vegyé' új gépet, ha... vegyé' több ramot ha...
Olyan jól elvoltam a C64-el anno :-)
Nem tudom emlékeztek-e rá, de nézzetek meg egy demot/játékot a gép kiadását követõ 2. évben és nézzétek meg, hogy u.o. hardver mellett milyen döbbenetes munkák születtek.
Bár nem ide tartozik, de mégis idevág: optimalizáció magasfokon amit a PS2-es programerek is elkövetnek.
Eleinte is komoly megoldásokat lehetett látni a gépen, de 1-2 éve meg már az ember azt mondaná, hogy ez egy PC-s high-end gépen futó nextgen progi.
Kár, hogy csak a konzolokon van meg ez a sokat vitatott jó szokás :-(
Nem tudom elfogadni, hogy az ember megvesz egy 400 ezres gépet amire 2 héten belül kiadnak egy olyan optimalizálatlan -bugos- progit, ami állóképeket képes produkálni esetenként.
Persze igazatok van... pénz, pénz, pénz... vegyé' új gépet, ha... vegyé' több ramot ha...
Olyan jól elvoltam a C64-el anno :-)
Nem tudom emlékeztek-e rá, de nézzetek meg egy demot/játékot a gép kiadását követõ 2. évben és nézzétek meg, hogy u.o. hardver mellett milyen döbbenetes munkák születtek.
Bár nem ide tartozik, de mégis idevág: optimalizáció magasfokon amit a PS2-es programerek is elkövetnek.
Eleinte is komoly megoldásokat lehetett látni a gépen, de 1-2 éve meg már az ember azt mondaná, hogy ez egy PC-s high-end gépen futó nextgen progi.
Kár, hogy csak a konzolokon van meg ez a sokat vitatott jó szokás :-(
Ne keverd össze a személyiségemet a viselkedésemmel. A személyiségem én vagyok. A viselkedésem meg attól függ, hogy te ki vagy.
#32
Ez is egy kib****tt üzlet lett. Régen volt 4k demó meg 64k-ban játék. Ma a doom3 egy mentett állás 19Mb! Az optimalizálás nem üzlet. Ennyi.
#31
Elgondolkozhatnánk azért arról is, hogy nem-e véletlenül a gépünk nem olyan gyors, mint amilyennek hirdetik?
Példaképp a win98 ugyanolyan gyorsan bootol be egy 950-es gépen, mint a 3.0 gigahertzes gépemen.
A win2000 is hasonlóan viselkedik. Egy 350-es p2 gépen ugyanolyan gyors, mint egy 1.7GHz-esen...
Példaképp a win98 ugyanolyan gyorsan bootol be egy 950-es gépen, mint a 3.0 gigahertzes gépemen.
A win2000 is hasonlóan viselkedik. Egy 350-es p2 gépen ugyanolyan gyors, mint egy 1.7GHz-esen...
#30
macros:
azért lássuk be a Vista hw igénye egy vicc. Fõleg a linuxos XGL mellett aztán végképp. (az elfutkos korrektül egy 800 -as p3 -on, gef2 32 BM-al, es 256 memóriaval)
azért lássuk be a Vista hw igénye egy vicc. Fõleg a linuxos XGL mellett aztán végképp. (az elfutkos korrektül egy 800 -as p3 -on, gef2 32 BM-al, es 256 memóriaval)
#29
OFF: Oblivion 7800GT-n kifogástalanul megy 1024x768-ban 3.5-ös Athlon+2Gb. Az önárnyék, stb. be van kapcsolva +HDR, meg a grass distance csutkára fel van nyomvan: így tökéletesen játszható (kivéve az erdõ közepén, ha jönnek a szörnyek).
#28
Nem is rossz ötlet. A BeOS pl ilyen célorintált kis gépekre kiváló OS lenne. És azért egy P200-on 64 MB ramaml nálam már mûvelt csodákat. (6 mp3 egyszerre lejátszása akadás nélkül pl😊
A programozók is rosszabbul élnek mint 4 éve. 😛
A kemény munka a későbbiekben megtérül. A lustaság viszont azonnal.
Akármennyire is divat az MS-t fikázni meg lelamerezni, ennek ellenére tényleg csak a legjobb kóderek kerülhetnek be oda. Azt meg tudomásul kell venni hogy a programozó azt csinál amiért fizetik, ha szart kell, mert mondjuk Billy / Ballmer megaszonta, akkor azt. Nameg amikor jönnek hogy "legyen benne hát olyan kis izé bigyó ami pörög, forog", na azt kódold le optimálisan! 😄
// Oblit majd kipróbálom, 7900 gt-vel, 85.25 forcewarezzel talán jó lesz. 😊
// Oblit majd kipróbálom, 7900 gt-vel, 85.25 forcewarezzel talán jó lesz. 😊
A kemény munka a későbbiekben megtérül. A lustaság viszont azonnal.
#25
Ja, és mindenki menjen a faszba, aki assemblyben akar olyan alkalmazást írni, ami fut clusteren. De most komolyan. Mi ez itt? Óvoda?
Ha már kivan a faszod az idióta szignókkal csinálj te is egyet.
#24
MUHAHAHHAHAA EZ JUTOTT ESZEMBE:
Rosszabbak a programok, mint 4 éve :😊))))
Rosszabbak a programok, mint 4 éve :😊))))
Ha már kivan a faszod az idióta szignókkal csinálj te is egyet.
#23
Azert a MenuetOS-t nem kell tullihegni. Nagyon is kiforratlan, raadasul elinditottam a grafikus demo prg-t (valami forgo cucc volt) 2 peldanyban, es fele olyan lassan futott, mint 1. Na most hany eves is az a projekt?
Es nem egy emberes project, legfeljebb ugy, mint a SkyOS. Es csak hasonlitsd ossze a kettot...
Assembly jo dolog volt, ma is megvan meg a helye. Egy OS irasa nem ide tartozik.
Viszont az igaz, hogy manapsag tenyleg sok a bloat. Oke, unicode szoveg, divx, stb., de azt nem lehet tagadni, hogy igenis rengeteg felesleges hulyeseg terheli a mai rendszereket. Ez nem az OOP hibaja, hiszem az meg az a szint, ami szukseges, raadasul pl. a Java VM az minden kiadassal gyorsabb lesz. Hanem a felelotlen fejlesztes.
Valoban tessek megnezni a BeOS-t, lehet, hogy ma mar nem lenne eleg, de annak idejen siman lenyomta barmelyik masik OS-t teljes OOP mellett. Szerintem inkabb azt kene rakni ezekre a 100$-os gepekre, legalabb lokest adna a Haiku-nak is...
Es nem egy emberes project, legfeljebb ugy, mint a SkyOS. Es csak hasonlitsd ossze a kettot...
Assembly jo dolog volt, ma is megvan meg a helye. Egy OS irasa nem ide tartozik.
Viszont az igaz, hogy manapsag tenyleg sok a bloat. Oke, unicode szoveg, divx, stb., de azt nem lehet tagadni, hogy igenis rengeteg felesleges hulyeseg terheli a mai rendszereket. Ez nem az OOP hibaja, hiszem az meg az a szint, ami szukseges, raadasul pl. a Java VM az minden kiadassal gyorsabb lesz. Hanem a felelotlen fejlesztes.
Valoban tessek megnezni a BeOS-t, lehet, hogy ma mar nem lenne eleg, de annak idejen siman lenyomta barmelyik masik OS-t teljes OOP mellett. Szerintem inkabb azt kene rakni ezekre a 100$-os gepekre, legalabb lokest adna a Haiku-nak is...
#22
"Az MS-t kár volt belekeverned, ott épphogy a legjobb programozók dolgoznak."
A legjobbak... fõleg OOP-ben ;-)
Amúgy mondhatnám az összes többi progit is ami "népszerû"... 1-2 játéknál veszik csak a fáradtságot, hogy optimalizáljanak.
Meg sem engedném, hogy olyan waret dobjanak a piacra ami kolosszusként rátelepszik a vasra.
Far Cry-t pl. nagyon szépen optimalizálták... talán 40%-al jobban fut, mint 4 éve ugyanazon a konfigon... igen, megcsinálták!<#idiota>
De ellenpéldának jó az Oblivion ami ugye a mai PC-s gamer vágyálmából a feltelepítést követõen hamar rémálommá vált. (Ezen a konfigon /nem az enyém/ is képes 20 FPS-t produkálni: 3.4-es LGA775, 2 Giga Crosair 667, X1900XTX, sata).
Na ez tökéletes példája a nem optimalizált terméknek. Nem szép dolog ilyet piacra dobni <#ejnye1>
A legjobbak... fõleg OOP-ben ;-)
Amúgy mondhatnám az összes többi progit is ami "népszerû"... 1-2 játéknál veszik csak a fáradtságot, hogy optimalizáljanak.
Meg sem engedném, hogy olyan waret dobjanak a piacra ami kolosszusként rátelepszik a vasra.
Far Cry-t pl. nagyon szépen optimalizálták... talán 40%-al jobban fut, mint 4 éve ugyanazon a konfigon... igen, megcsinálták!<#idiota>
De ellenpéldának jó az Oblivion ami ugye a mai PC-s gamer vágyálmából a feltelepítést követõen hamar rémálommá vált. (Ezen a konfigon /nem az enyém/ is képes 20 FPS-t produkálni: 3.4-es LGA775, 2 Giga Crosair 667, X1900XTX, sata).
Na ez tökéletes példája a nem optimalizált terméknek. Nem szép dolog ilyet piacra dobni <#ejnye1>
Ne keverd össze a személyiségemet a viselkedésemmel. A személyiségem én vagyok. A viselkedésem meg attól függ, hogy te ki vagy.
#21
Ennyire azért nem rossz a helyzet.
1. Manapság annyi fejlesztõ van, hogy a cégek bõven tudnak válogatni. Egy felvételi beszélgetésbõl + hozott referenciákból kiderül hogy az illetõ hülye e. A hülyéket ma már nem veszik fel: max. más hülyéknek fejlesztenek weboldalakat Biszbasz Bt. néven.
2. Szerintem az optimalizáció nem a fejlesztõ dolga (hozzátéve azt is hogy a multam miatt én speciel imádom optimalizálni a kódjaimat: ha van rá idõm mindig elszórakozom vele), hanem a fordítóprogramé. Például a Javában alapvetõ hiba hogy ha a stringeket '+' jellen összeadjuk és nem egy tömbbe pakoljuk és aztán kiolvassuk a végén. Kérdem én ezt miért nem a fordító végzi önálóan? (tudtommal pl. a JBuilder ezt magától megteszi). Ez inkább a fordító fejlesztõinek lustasága, nem pedig a programozó hibája.
1. Manapság annyi fejlesztõ van, hogy a cégek bõven tudnak válogatni. Egy felvételi beszélgetésbõl + hozott referenciákból kiderül hogy az illetõ hülye e. A hülyéket ma már nem veszik fel: max. más hülyéknek fejlesztenek weboldalakat Biszbasz Bt. néven.
2. Szerintem az optimalizáció nem a fejlesztõ dolga (hozzátéve azt is hogy a multam miatt én speciel imádom optimalizálni a kódjaimat: ha van rá idõm mindig elszórakozom vele), hanem a fordítóprogramé. Például a Javában alapvetõ hiba hogy ha a stringeket '+' jellen összeadjuk és nem egy tömbbe pakoljuk és aztán kiolvassuk a végén. Kérdem én ezt miért nem a fordító végzi önálóan? (tudtommal pl. a JBuilder ezt magától megteszi). Ez inkább a fordító fejlesztõinek lustasága, nem pedig a programozó hibája.
#20
DSL = Danm small linux.
2. ne akarjál assemblyben oprendszert írni. Van olyan (Menuettos), de nincs értelme, mert nem portolható sehova, csak szórakozásból van.
2. ne akarjál assemblyben oprendszert írni. Van olyan (Menuettos), de nincs értelme, mert nem portolható sehova, csak szórakozásból van.
Ha már kivan a faszod az idióta szignókkal csinálj te is egyet.
Nem biztos, hogy önmagában csak az OOP hibás.
A legjobb példa rá az EPOC32 oprendszer, ami a Psion series 5-ben volt.
Vagy a BeOS.
Szóval lehet OOP-ban is kis erõforrásigényû hatékony kódot írni.
Csak ki kéne venni belõle a szemetet.
A legjobb példa rá az EPOC32 oprendszer, ami a Psion series 5-ben volt.
Vagy a BeOS.
Szóval lehet OOP-ban is kis erõforrásigényû hatékony kódot írni.
Csak ki kéne venni belõle a szemetet.
¤¤¤¤o¤o,¸¸o¤o,¸¸,o¤o°`°o¤o,¸¸,o¤o°`°o¤o,¸¸o¤o,¸¸,o¤o°`°o¤o,¸¸,o¤o°`°o¤o,¸¸o¤o,¸¸,o¤o°`°o¤o,¸¸,o¤o°`°o¤o,¸¸o¤o,¸¸,o¤o°`°o¤o,¸¸,o¤o°`°o¤O3>
Az MS-t kár volt belekeverned, ott épphogy a legjobb programozók dolgoznak. De sok a manager, a megmondóember. A linuxról meg számtalanszor bebizonyosodott hogy ugyanolyan erõforrásigényes, védtelen mint a win, csak azért nem hekkeli meg senki, mert senkit nem érdekel. Most jöhet a duma hogy de van 1 cd-s linux is, winbõl is van tinyxp, ezek minde lebutított verziók, pont annyival kisebbek mint amennyivel kevesebbet tudnak.
A kemény munka a későbbiekben megtérül. A lustaság viszont azonnal.
#17
Példának jó, de ha összehasonlítod az új xgl-es Linuxxal, vagy a Vistával, akkor láthatod hogy a bonyolultság összehasonlíthatatlanul más nagyságrend.
Hidd el, hogy egy videokártya drivert (ami csak egy ezreléke az oprendszernek) több tíz ember fejleszt több évig. És az csak egyetlen driver.
Hidd el, hogy egy videokártya drivert (ami csak egy ezreléke az oprendszernek) több tíz ember fejleszt több évig. És az csak egyetlen driver.
Azért egy win bonyolultságú oprendszert assemblyben megírni nem 5 perc. Mire elkészül, nem is gyártanak már olyan gépet amin futni tud. 😊
A kemény munka a későbbiekben megtérül. A lustaság viszont azonnal.
#15
Egy-két ember szerintem picit félreérti a cikket.
Itt senki nem arról beszélt, hogy gépikódban kellene közvetlenül a programokat megkreálni.
Itt arról van szó ami már tényleg baromi terhes mindenki számára... az optimalizáció hiánya!
Tényleg tarthatatlan az az állapot, hogy manapság -már bocsánat- de minden marhából lehet programozó, aki kiböffent magából egy HTML oldalt.
Ennek meg persze az a következménye, hogy a t. programozó urak csak a "bátyám szobatársának a barátnõjének az apjától hallottak a gépi kódról", beülnek a bõrfotelbe és egy egyszerû adatbáziskezelõt kihoznak 200 megából full OOP alapon... bezsebelik a nagy lét.. a kérdésre pedig, hogy miért ilyen cefet lassú azt a választ adják, hogy nem a progi lassú hanem a géped szar... vegyé' jobb procit, több ramot, gyorsabb vinyót stb.
De tudjátok mit legyen... engedjük az ilyeneket is kibontakozni, de a szörnyû az, hogy a nagy cégekhez bekerülve ezek az emberek a remek hozzáértésükkel tovább növelik a populáris programok bonyolultságát.
Ilyen 50 millió kódsorról regélnek Vista kapcsán... bah... röhejes.
Ha olyan szívvel, lélekkel meg olyan tudással rendelkezõ programerek ülnének "fontos székekben", mint akik 64k-ba képesek kisebb csodákat létrehozni, akkor nem tartanánk ott, hogy a 64 bites 3.2-es procim, 2 Giga ramom és SATA vinyóm mellett több, mint 1 percet várok mire ez a szemet bebootol.
Ja tudom, ébredjek fel... meg choose Linux (az is van, szalad is szépen :-)
Itt senki nem arról beszélt, hogy gépikódban kellene közvetlenül a programokat megkreálni.
Itt arról van szó ami már tényleg baromi terhes mindenki számára... az optimalizáció hiánya!
Tényleg tarthatatlan az az állapot, hogy manapság -már bocsánat- de minden marhából lehet programozó, aki kiböffent magából egy HTML oldalt.
Ennek meg persze az a következménye, hogy a t. programozó urak csak a "bátyám szobatársának a barátnõjének az apjától hallottak a gépi kódról", beülnek a bõrfotelbe és egy egyszerû adatbáziskezelõt kihoznak 200 megából full OOP alapon... bezsebelik a nagy lét.. a kérdésre pedig, hogy miért ilyen cefet lassú azt a választ adják, hogy nem a progi lassú hanem a géped szar... vegyé' jobb procit, több ramot, gyorsabb vinyót stb.
De tudjátok mit legyen... engedjük az ilyeneket is kibontakozni, de a szörnyû az, hogy a nagy cégekhez bekerülve ezek az emberek a remek hozzáértésükkel tovább növelik a populáris programok bonyolultságát.
Ilyen 50 millió kódsorról regélnek Vista kapcsán... bah... röhejes.
Ha olyan szívvel, lélekkel meg olyan tudással rendelkezõ programerek ülnének "fontos székekben", mint akik 64k-ba képesek kisebb csodákat létrehozni, akkor nem tartanánk ott, hogy a 64 bites 3.2-es procim, 2 Giga ramom és SATA vinyóm mellett több, mint 1 percet várok mire ez a szemet bebootol.
Ja tudom, ébredjek fel... meg choose Linux (az is van, szalad is szépen :-)
Ne keverd össze a személyiségemet a viselkedésemmel. A személyiségem én vagyok. A viselkedésem meg attól függ, hogy te ki vagy.
#14
Nem tudom, hogy van-e benne jogosultsági ellenörzés, vagy hogy akarnak-e beletenni, ha nincs. Na meg az is kérdés, hogy ha beletennék, akkor az mennyit lassítana a rendszeren, ha azt is jól optimalizált assembly kódban írnák meg.
Mindenesetre jelezetem, hogy én ezt csak példának hoztam fel az optimalizálásra és az assembly-ben való fejlesztésre, nem pedig etalonnak ami tökéletes és követendõ.
Mindenesetre jelezetem, hogy én ezt csak példának hoztam fel az optimalizálásra és az assembly-ben való fejlesztésre, nem pedig etalonnak ami tökéletes és követendõ.
<#eljen> Naigen, amikor megkapod a határidõt hogy x hét alatt legyen kész a progi, akkor kevésbé érdekel hogy optimális a kód vagy sem, te az elkészülésre kapod a fizetést. 😊
A kemény munka a későbbiekben megtérül. A lustaság viszont azonnal.
Lehet hogy kicsi, meg gyors, de ezért cserébe nyilván nem is végez olyan jogosultsági ellenõrzéseket, amik ma már fõleg hálózati munkáknál elképzelhetetlenek. Az ilyesmi viszi el a többi oprendszer idejének jó részét is, hiszen semmi nem fut csak úgy magától, 0 erõforrásigénnyel.
A kemény munka a későbbiekben megtérül. A lustaság viszont azonnal.
Az oop-re szükség van, egy nagy prodzsektet nem lehet papír-ceruzával, adhoc alapon kódolni, mert csak egy nagy bughalmaz lesz belõle. Fõleg ha valamit módosítani kell rajta, és millió helyen kéne változtatni.
A java, c# meg az oop-n kívül azért is jók, mert platformfüggetlenek, nem kell minden gépre külön a saját assemblyjében megírni, ugyanaz jó mindre, tehát többfelé fel lehet használni.
A java, c# meg az oop-n kívül azért is jók, mert platformfüggetlenek, nem kell minden gépre külön a saját assemblyjében megírni, ugyanaz jó mindre, tehát többfelé fel lehet használni.
A kemény munka a későbbiekben megtérül. A lustaság viszont azonnal.
#10
"Assemblyben nyilván lehetne tök optimális, gyors és kicsi oprendszert írni, csak mondjuk egymillió emberév munka lenne."
Ebben azért nincs igazad.
Ajánlom a következõ oldalt:
http://www.menuetos.net/
Ez egy 100 %-ban assemblyben írt oprendszer. Mostmár csak a 64bit-es verziója tölthetõ le, de van neki 32 bites is én is azt szoktam használni. Ahhoz még mellékelték a forráskódot is.
Egyetlen floppyra ráfér. Kezeli a hálót, van webszervere, full grafika minden nem kell shell-el pöcsölni. Még most is hihetetlenül szokatlan, hogy elindítva egy programot, abban a pillanatban elindul, nem kell a forgó homokórát bámulni, mint más rendszereknél.
Egyetlen programozó írta az egészet és két másik besegített a net és grafikai részbe és nem egymillió évig készült.
Nem feltétlenül azt akartam ezzel mondani, hogy ez a jövõ útja, csak éppen egy példa arra, hogyan lehet kicsi, villámgyors, ugyanakkor mégis komplex programot vagy rendszert írni, akár egyetlen programozónak is.
Ebben azért nincs igazad.
Ajánlom a következõ oldalt:
http://www.menuetos.net/
Ez egy 100 %-ban assemblyben írt oprendszer. Mostmár csak a 64bit-es verziója tölthetõ le, de van neki 32 bites is én is azt szoktam használni. Ahhoz még mellékelték a forráskódot is.
Egyetlen floppyra ráfér. Kezeli a hálót, van webszervere, full grafika minden nem kell shell-el pöcsölni. Még most is hihetetlenül szokatlan, hogy elindítva egy programot, abban a pillanatban elindul, nem kell a forgó homokórát bámulni, mint más rendszereknél.
Egyetlen programozó írta az egészet és két másik besegített a net és grafikai részbe és nem egymillió évig készült.
Nem feltétlenül azt akartam ezzel mondani, hogy ez a jövõ útja, csak éppen egy példa arra, hogyan lehet kicsi, villámgyors, ugyanakkor mégis komplex programot vagy rendszert írni, akár egyetlen programozónak is.
Ez igaz, de ha oop-ben programozunk, akkor lehetne alatta a hw is olyan ami natívan támogatja azt. Régebben akartak Java processzort csinálni, nagyon nem hallani már róla. Lehet hogy egy mûveletet lassabban hajt végre mint egy x86, de ott egy mûvelet igen sok x86 mûvelettel ér fel, összteljesítmény szempontjából mindenképp hatékonyabb lenne egy ilyen "célprocesszor". Igaz, ehhez az is kéne hogy megállapodjanak az assembly utódáról, mert az se lenne jó ha minden proci más nyelven mûködne, azzal ugyanott lennénk mint most.
A kemény munka a későbbiekben megtérül. A lustaság viszont azonnal.
#8
Ellenpelda: En Photoshopon is dolgozom evek ota, es minden egyes resz joval lasabb az elozonel. A csucs a mostani CS2, ami jocskan lomhabb a CS1-nel. Pedig nincsen benne tobb csilivili, egyszeruen optimalizalatlan, bugos is... A lenyeg hogy a programozoknak minel gyorsabban kell atalakitaniuk az egeszet, hogy ujnak tunjon.
#7
Egyetértek mindennel amit #4 írtál.
Egyébként a #2-re annyit reagálnék hogy igazából ma már nem számítanak ezek a dolgok az esetek 95%-ában.
Nagyon kevés sebesség kritikus dolgot kell manapság írni (algoritmusok fõleg), a futás nagy része így is a felhasználóra / hálózatra / adatbázisra való várakozásra megy el. Mondjuk én az utóbbi öt évben kizárólag web közeli fejlesztéseken dolgozom.
Persze ha kernelt írsz, az más tészta, viszont az már nem a .Net és a Java hatásköre.
Egyébként a #2-re annyit reagálnék hogy igazából ma már nem számítanak ezek a dolgok az esetek 95%-ában.
Nagyon kevés sebesség kritikus dolgot kell manapság írni (algoritmusok fõleg), a futás nagy része így is a felhasználóra / hálózatra / adatbázisra való várakozásra megy el. Mondjuk én az utóbbi öt évben kizárólag web közeli fejlesztéseken dolgozom.
Persze ha kernelt írsz, az más tészta, viszont az már nem a .Net és a Java hatásköre.
#6
Részben egyetértek az elõbb hozzászóló programozó úr véleményével.
-A linux kernel továbbra is sima c-ben készül. Hát esküdni nem mernék de szerintem nem sokat romlott sebességben az elõzõ szériákhoz képest.
Nyilván egy 64-bites utasításokat mindenféle piciX-es - satas, tûzvonalas, usbos kernel
NEM LEHET kissebb mint egy 1.0 széria.
- Nicholas Negroponte eltévesztette a konferenciát. Szerintem a kis buta windowst abból a Vistat rakta fel az uberszuper masinára....
Izé miért is vesz 100as úr halál drága notebookot?????? Miért nem a 100 dolcsis laptopot vett.
- Linuxon a 100as úr nyugodtan használjon XFCE-t, mc, vi. Ezek még az 5 évvel ezelötti note-okon is hasítanak.
A 7-8 éves gépemen remekül megy a Stable debiannal. Igaz a firefox 15sec alatt áll fel rajta, de internet elõtétnek használom, arra jó.
- Ha valakinek baja van a KDE,Gnome openoffice és társaival nyugodtan használjon mást.
-A linux kernel továbbra is sima c-ben készül. Hát esküdni nem mernék de szerintem nem sokat romlott sebességben az elõzõ szériákhoz képest.
Nyilván egy 64-bites utasításokat mindenféle piciX-es - satas, tûzvonalas, usbos kernel
NEM LEHET kissebb mint egy 1.0 széria.
- Nicholas Negroponte eltévesztette a konferenciát. Szerintem a kis buta windowst abból a Vistat rakta fel az uberszuper masinára....
Izé miért is vesz 100as úr halál drága notebookot?????? Miért nem a 100 dolcsis laptopot vett.
- Linuxon a 100as úr nyugodtan használjon XFCE-t, mc, vi. Ezek még az 5 évvel ezelötti note-okon is hasítanak.
A 7-8 éves gépemen remekül megy a Stable debiannal. Igaz a firefox 15sec alatt áll fel rajta, de internet elõtétnek használom, arra jó.
- Ha valakinek baja van a KDE,Gnome openoffice és társaival nyugodtan használjon mást.
#5
"Már akkor megkérdeztem, hogy mire is jó ez az OOP ha nagyobb kódot fordít, és lassabban is fut."
Én most nem vállalnám fel azt hogy ezt elmagyarázzam neked. Ha veszel / letöltessz egy OOP könyvet és megpróbálsz magadon erõszakot elkövetve megírni pár OOP programot (az OOP elveknek megfelelõen) akkor magadtól is rájössz, ha meg nem, akkor egyébként sincs segítség.
Én Z80-on kezdtem, 80286-on folytattam, 386-on írtam MMX alá grafikai rutionokat, aztán programoztam mindenben ami mozog, most mégis Javát, AJAX-ot és .Net-et használok. Hogy miért? Mert könnyebb újrahasznosítani a kódot, mert sok mindent megcsinál más - és én erõfeszítések nélkül átvehetem tõlük az eredményt, mert könnyû debugolni, mert a fejlesztõeszköz kinyalja a seggemet (VS 2005, Eclipse 3) és mert pár hét alatt kell komplex programokat letennem az asztalra.
Ha neked jó keseregni azon hogy már nem kõbaltával dolgozunk, csak tessék. Ifjú titánként még én is az Assembly programozásért tüntettem (akkor a C volt a puhapöcsûeknek való). Majd ha idõsebb leszel másként fogod látni.
Én most nem vállalnám fel azt hogy ezt elmagyarázzam neked. Ha veszel / letöltessz egy OOP könyvet és megpróbálsz magadon erõszakot elkövetve megírni pár OOP programot (az OOP elveknek megfelelõen) akkor magadtól is rájössz, ha meg nem, akkor egyébként sincs segítség.
Én Z80-on kezdtem, 80286-on folytattam, 386-on írtam MMX alá grafikai rutionokat, aztán programoztam mindenben ami mozog, most mégis Javát, AJAX-ot és .Net-et használok. Hogy miért? Mert könnyebb újrahasznosítani a kódot, mert sok mindent megcsinál más - és én erõfeszítések nélkül átvehetem tõlük az eredményt, mert könnyû debugolni, mert a fejlesztõeszköz kinyalja a seggemet (VS 2005, Eclipse 3) és mert pár hét alatt kell komplex programokat letennem az asztalra.
Ha neked jó keseregni azon hogy már nem kõbaltával dolgozunk, csak tessék. Ifjú titánként még én is az Assembly programozásért tüntettem (akkor a C volt a puhapöcsûeknek való). Majd ha idõsebb leszel másként fogod látni.
#4
Igazabol nem az OOP a hibas. Hanem az, aki nem tud OOP-ben programozni (es ebbol aztan tenyleg rengeteg van!!!). Mert a .NET baromi kenyelmes, konnyu megtanulni, minden hulye tud vele latvanyos (es lassu!) programot irni, de ha nem figyelsz oda, hogy pl egy sima string is egy object, akkor majd csodalkozni fogsz, hogy miert a GC viszi el a futasi idod 70%-at... 😊
Hogyha pontosan tudod h mit csinalsz (erted hogy milyen overhead-ek vannak oroklodesnel, mi mennyi memoriat fogyaszt, stb), nagyon gyors tud lenni. Ugyan igy assemblyben is lehet baromi lassu programot irni!!!!
Amugy pedig ott a Mono project. Az pont .NET linux ala! 😊
A java pedig azert lassu, mert nem Just-In-Time foritasra talaltak ki a kodjat, hanem ertelmezore...
Hogyha pontosan tudod h mit csinalsz (erted hogy milyen overhead-ek vannak oroklodesnel, mi mennyi memoriat fogyaszt, stb), nagyon gyors tud lenni. Ugyan igy assemblyben is lehet baromi lassu programot irni!!!!
Amugy pedig ott a Mono project. Az pont .NET linux ala! 😊
A java pedig azert lassu, mert nem Just-In-Time foritasra talaltak ki a kodjat, hanem ertelmezore...
#3
Az OOP a hibás az egészért.
A régi C az még türhetõ méretû és sebességû kódot gyártott.
10 éve voltam az elsõ C++ tanfolyamon, ahol még a borland C++-al fordítottunk progikat.
Már akkor megkérdeztem, hogy mire is jó ez az OOP ha nagyobb kódot fordít, és lassabban is fut.
Erre az volt a válasz, hogy sebaj jön a gyorsabb proci, meg a sok memória, és egyszerûbb áttekinthetõbb a kód.
Na errõl az áttekinthetõ kóddal már akkor sem értettem egyet, és mind a mai napig ez így maradt.
Ezek után mit csodálkoznak, hogy böszme nagy és lassú progik készültek.
Kárörvendve mondhatnám, hogy nesze nektek OOP, de sajnos nem tehetem, mert a világ nagy része még nem jött rá, hogy a java, meg a .net egy erõforrás zabáló szutyok. A .Net ráadásul nem kompatibilis a linuxokkal, és hát a java igazán látványos grafikai részei sem futnak minden oprendszeren, azt is úgy kell hegyezgetni, hogy mi fog futni ezen vagy azon a gépen.
Ez van, ezt nem most baszták el, hanem 10-15 éve kellett volna wc-be dugni a sok oop buzi fejét és ráhúzni párszor a tartályt!
A régi C az még türhetõ méretû és sebességû kódot gyártott.
10 éve voltam az elsõ C++ tanfolyamon, ahol még a borland C++-al fordítottunk progikat.
Már akkor megkérdeztem, hogy mire is jó ez az OOP ha nagyobb kódot fordít, és lassabban is fut.
Erre az volt a válasz, hogy sebaj jön a gyorsabb proci, meg a sok memória, és egyszerûbb áttekinthetõbb a kód.
Na errõl az áttekinthetõ kóddal már akkor sem értettem egyet, és mind a mai napig ez így maradt.
Ezek után mit csodálkoznak, hogy böszme nagy és lassú progik készültek.
Kárörvendve mondhatnám, hogy nesze nektek OOP, de sajnos nem tehetem, mert a világ nagy része még nem jött rá, hogy a java, meg a .net egy erõforrás zabáló szutyok. A .Net ráadásul nem kompatibilis a linuxokkal, és hát a java igazán látványos grafikai részei sem futnak minden oprendszeren, azt is úgy kell hegyezgetni, hogy mi fog futni ezen vagy azon a gépen.
Ez van, ezt nem most baszták el, hanem 10-15 éve kellett volna wc-be dugni a sok oop buzi fejét és ráhúzni párszor a tartályt!
#2
Nem tudok teljesen igazat adni neked.
A mostani processorok sokkal gyorsabbak, mint ahogy a memoriat elerik. A gyorsito tarjuk veges kapacitasu. Ugy tudod a programodat optimalizalni (meg .NET-ben is!!!! (En csinaltam... 😊)) hogy a proci cache-be minel tobb minden beleferjen egyszerre. Ha nem igy teszel, a sok memoriara varas elveszi az idod 90-95%-at.
Miutan a mostani orias programok eleve 50 megakat foglalnak a memoriabol, kizartnak tartom, hogy minden reszuk minden esetben full optimalisan futna.
Sokszor kisebb program = sokkal gyorsabb program.
A mostani processorok sokkal gyorsabbak, mint ahogy a memoriat elerik. A gyorsito tarjuk veges kapacitasu. Ugy tudod a programodat optimalizalni (meg .NET-ben is!!!! (En csinaltam... 😊)) hogy a proci cache-be minel tobb minden beleferjen egyszerre. Ha nem igy teszel, a sok memoriara varas elveszi az idod 90-95%-at.
Miutan a mostani orias programok eleve 50 megakat foglalnak a memoriabol, kizartnak tartom, hogy minden reszuk minden esetben full optimalisan futna.
Sokszor kisebb program = sokkal gyorsabb program.
#1
Ez azért így ebben a formában baromság.
Assemblyben nyilván lehetne tök optimális, gyors és kicsi oprendszert írni, csak mondjuk egymillió emberév munka lenne.
Ha gyorsítani szeretnénk a fejlesztést muszály szabványokat, modern nyelveket, OOP-t használni, debugolhatóra megírni mindent. Ezek mindegyike egyre lassítja a programot, egyre több hibalehetõséget csempész bele, viszont exponenciálisan csökkenti a fejlesztési idõt.
A Vista, a .Net 2.0 évekig készült/készül, de ha ezekre fejleszt az ember, hónapokat spórol meg.
Meg persze ott van hogy az emberek elvárásai a szoftverekkel szemben egyre nagyobbak. Ma már nem igazán a command prompton matat az átlag júzer, hanem animált felületeken nyomkod. Ennek nyilván többezerszeres a hardwareigénye.
Szóval a manusznak igaza van, egyre lassabbak a szoftverek, de hülyeség errõl panaszkodni.
Mellesleg õt se tartja vissza senki attól hogy a szuper laptopjára felrakjon egy shellt- és abban dolgozzon karakteres módban: az fix hogy eszement gyors lesz.
Assemblyben nyilván lehetne tök optimális, gyors és kicsi oprendszert írni, csak mondjuk egymillió emberév munka lenne.
Ha gyorsítani szeretnénk a fejlesztést muszály szabványokat, modern nyelveket, OOP-t használni, debugolhatóra megírni mindent. Ezek mindegyike egyre lassítja a programot, egyre több hibalehetõséget csempész bele, viszont exponenciálisan csökkenti a fejlesztési idõt.
A Vista, a .Net 2.0 évekig készült/készül, de ha ezekre fejleszt az ember, hónapokat spórol meg.
Meg persze ott van hogy az emberek elvárásai a szoftverekkel szemben egyre nagyobbak. Ma már nem igazán a command prompton matat az átlag júzer, hanem animált felületeken nyomkod. Ennek nyilván többezerszeres a hardwareigénye.
Szóval a manusznak igaza van, egyre lassabbak a szoftverek, de hülyeség errõl panaszkodni.
Mellesleg õt se tartja vissza senki attól hogy a szuper laptopjára felrakjon egy shellt- és abban dolgozzon karakteres módban: az fix hogy eszement gyors lesz.
← ElőzőOldal 2 / 2