BGAFC Vendégkönyv

Σ: 1 post

saxus (statz)

#9, Agyfasz (419)

4964 | #1bd9 | ^ | Idézet | Mon, 16 Apr 2012 22:10:05 +02

84.3.*.*

*.catv.pool.telekom.hu

kemi írta/wrote:
de az valószínűleg azért van, mert fos a GCC winfoson.

Nem csak ott ;) Nem véletlen, hogy komoly pénzeket tolnak egyes cégek az LLVM+Clang páros fejlesztésébe. Ugyan átlagosan még jó 10%-al lassabb a GCC-nél a generált kód, csak épp kevésbé bloated, sokkal modernebb, modulárisabb arch (egy optimalizer, amögött archonként konkrét fordító + optimalizáló, a fordító előtt meg nyelvenként frontend, amely a fordító köztes nyelvére fordít. Így egy új nyelv támogatásakor csak a nyelv->köztes kód fordítót kell megírni, nem kell mindenhol optimalizálót, stb. Nem tudom, ismerős-e valakinek a JVM/CLI koncepciója itt ;) Ja meg jóval értelmesebb hibaüzenetek. Szóval itt is az van, hogy az esetek nagy részében nem éri meg az a plusz 10% (na meg figyelembe véve, hogy néhány éve sehol nem volt a projekt, egyáltalán nem biztos, hogy nem fogja csúnyán lehagyni idővel a GCC-t).

kemi írta/wrote:
A Java viszont megint nyert, tehát kijelenthetjük, hogy a .NET még a Javánál is fosadékabb.

Az ilyen szintetikus tesztek így önmagukban semmit nem mondanak. Másrészt a Java meg a .NET nem matekolásban lassabb, mint a C, hanem pl. a dinamikus dolgok használata miatt. Pl. reflection.

TCH írta/wrote:
hogy a szoftverek egyre lassabbak és nagyobbak lesznek, de ez nem fog a végtelenségig tartani.

Öregem, a helyzet az, hogy a CPU-k magjainak száma másfél évente megduplázódik. Ezzel együtt kb. a teljesítményük is. Ehhez képest disk, a hálózat vagy úgy bármiféle IO sebességének fejlődése kb. a vánszorgó csiga tempója. Az a helyzet, hogy ha _alkalmazást_ akarok fejleszteni, ahol a cél egy konkrét (nem informatikai) probléma megoldása, akkor kb. totálisan telibe fogom szarni, hogy egy gomb eseménykezelője most 0.1 vagy 0.2 microsecig futott. User nem vesz észre belőle semmit és egyébként is, a CPU idő 99,99%-a kihasználatlan.

TCH írta/wrote:
Dehogynem. Szükségszerűen az adatok kezelésének felesleges kerülői miatt.

Látszik, hogy nem olvastad el a linkelt cikkeket. Másrészt, hibakezelést nem lehet elsunnyogni. Az a helyzet, hogy a legtöbb fagyás és sechole még mindig az ilyenekből adódik.

TCH írta/wrote:
Ez a két "indok" gyakorlatilag az a két kifogás

Vedd még hozzá a csapatban való fejlesztést és a kódok továbbadását. Pont most anyázok amiatt, hogy az a kedves kolléga, aki 4 hónap után dobbantott és egy önfejű makacs fasz volt szakmai téren nekiállt "leszarom, ez így fos, nem érdekel, gány fúj, nem vagyok hajlandó így kódolni" hozzáállással telibetúrni a rendszert és a meglévő rendszerkomponensek helyett egyedi módon megoldani a feladatot. Hozománya? A fejlesztést segítő toolok 100%-a nem működik együtt a cuccaival, AJAX réteg megkerülve, +1 template rendszer. "Mert gyorsabb így." Kurvára kibaszottul leszarom, főleg, hogy dobbantott. Most ez azzal járt, hogy tarthatok karban kettő dolgot és akinek be kell tanulnia a rendszerbe, és egy ilyen az keményen megnöveli a betanulást és az időt, amely alatt egy hibát javítani lehet. Na ez az idő egy ember esetén átlagosan egy fél szerver ára.

Ha alkalmazást fejlesztesz, ott kell optimalizálni, ahol gázos a teljesítmény, egyébként minden esetben kizárólag az számít, hogy könnyen áttekinthető és rugalmas

TCH írta/wrote:
Akkor lenne ugyanolyan lassú, ha C-ben a C#-el vagy Java-val megegyező adatszerkezeteket és eljárásokat használnál.

legyen a kód.

Hagyjuk már, C-ben önmagában lófasz nincs. Azt különben is rendszerprogramozásra találták ki, nem alkalmazásfejlesztésre. Másrészt, amint összefutsz C-ben ilyen - manapság elég általános - feladatokkal, mint memoriakezelés (.NET pl. képes arra, hogy áthelyezzen memóriában részeket, hogy ne legyen annyira fragmentált, így gyorsabban lehet foglalni vs. malloc(), ami szanaszét tudja töredezni a ramot) vagy esetkeg [unicode/utf8/ansi] stringkezelés, neadjisten XML feldolgozás, mindjárt ott tartunk, hogy hoppá.

Aztán ha meg eljutunk ilyen apróságokig, amire nemigazán illik a "non blocked" jelző, mint disk vagy hálózati művelet, máris gyakorlatilag elenyésző a különbség. Hisz egy IO művelet esetén a kód 99%-a úgy is az OS kódja lesz vagy valószínűbb, hogy vársz a hardverre.

TCH írta/wrote:
A holdra egy C64 kaliberű géppel feljutottak és ma ennek a teljesítménynek a többszázezerszeresére van szükség, hogy a windózpécé életre keljen. No fuckin comment.

Remek, a 60-70-es évek informatikájával szemben meg nem változott semmi, ugye? Tegyük már hozzá, hogy ahhoz a teljesítményhez kellett 3 szobányi szekrény, ma meg körberöhögi a mobilom és akkor még grafikont is rajzol az adatokból valós időben meg még kielemzi és nem két év alatt van meg hozzá a szoftver, hanem 3 hónap alatt.