Vlákno názorů k článku Techniky zvýšení výpočetního výkonu mikroprocesorů od Clock - Neexistuji nejake? Zvetseni poctu neuronu a zmenseni tloustky...
-
BLEK. (neregistrovaný)No, Clock zrovna jak kůň v ASM/C dře a vydělává o dost víc než .NET, JAVA, PHP kodér (sám jsi tvrdil, že kodér je u vás ve firmě až na posledním místě).
Od určitého počtu prodaných zařízení se vyplatí najmout si drahé ASM programátory a díky nim to zařízení udělat o pár euro levnější. -
A co je na tom divneho? Bud chci vyvijet rychle za cenu pomalejsiho programu (tzn. volim managed jazyky) a nebo optimalizuji , vyvoj je 10x drazsi, ale program rychlejsi:) Vzdycky to zalezi pouze na tom, co chci delat a co se mi vyplati. A vzhledem k tomu, ze je vypocetni vykon pomerne dost levna zalezitost, tak jazyky ala Java ci C# pochopitelne slavi uspech :)
Nicmene zpraseny program neni ani tak otazka jazyka, jako programatora, udelat nepouzitelne pomaly program se da v jakemkoliv jazyce... -
anonymnía co treba jazyky jako lisp ? to, cim se dneska vytahuje java a c# mely uz davno predtim nez tyhle dva paskvily vznikly (od koho to javisti asi opsali ? ;-)), a slusne implementace se co se vykonu tyce na urovni ccka.
implementace regularnich vyrazu v common lispu (CLPPCRE) je dokonce rychlejsi nez PCRE, coz ma byt nejrychlejsi implementace regularnich vyrazu vubec - tipnul bych si ze to ma co do cineni s tim, ze nepouzivaji retezce znaku pro zadani kriterii, s listy se da pracovat rychleji ;-), ale zdrojaky jsem nezkoumal...
a navic maji vlastnosti o kterych se vetsine jazyku ani nezdalo. -
vzyt je uplne jedno, v cem je program napsany. dnesni hw je tak levny, ze je uplne jedno, jestli se programuje v asm nebo c#.
ale asi spis mas na mysli rozdily ve volbe algoritmu. malo kvalitni programator zprodukuje zpraseny a pomaly kod klidne i v tom asm. pricemz typickym prikladem je velka cas oss, na kterem se tenhle typ lidi uci programovat. :-(( -
atarist (neregistrovaný)No ne vzdy je HW tak levny, ze nezalezi na optimalizacich, dokonce ve vetsine pripadu je tomu prave naopak. Nekdy ani nejde tak o cenovou laci jako o to, ze proste silne procesory jsou velke a strasne zerou (=vyzaruji teplo, ktere je nutne nekam odvest), to se pro mnoho zarizeni zrovna moc nehodi.
S druhym odstavcem souhlas. -
JS (neregistrovaný)Souhlas. Ono pomalost software je mnohem vice dana dobou jeho vzniku nez tim, jestli je opensource nebo ne.
Navic, podle me, jestli jste dobry nebo spatny programator vam v tomto smeru dnes pomuze jen malo. Vetsina software se pise rychle za pomoci knihoven a frameworku, ktere jsou velice obecne (a pro dany problem zbytecne) a jejich chovani malokdy muzete odhadnout, dokud tu celou aplikaci neslozite. Driv se kazdy program psal od piky, a programator si to tedy mohl sam zoptimalizovat.
Chci tim rict, pomalost dnesnich aplikaci neni trivialni problem, a je dany tim, ze pozadujeme stale slozitejsi aplikace a knihovny, a nechceme pokazde znova vsechno stavet. Take k tomu prispiva fakt, ze u slozite aplikace si nemuzete udelat teoretickou analyzu, jak co dlouho bude trvat. Takze to proste vyzkousite a pokud to na vasem pocitaci rozumne chodi, je to v pohode. Ale pokud je to funkce v nejake knihovne, ktera je volana z jine knihovny, muze se vam bez problemu stat, ze se ta funkce vola 100x vic nez by mela, a pak uz to samozrejme poznat bude.
Zkratka - dnesni aplikace jsou slozite, tedy mate na vyber - bud to napsat odspodu optimalne (coz chce hlavne cas, dobre SW inzenyry a davku odvahy resit uz davno vyresene problemy), a nebo pouzit knihovny, cimz se zbavite porozumeni toho, jak vase aplikace vlastne funguje, a pak velice snadno dojdete do neoptimalniho stavu. Inteligence lidi je omezena a ani ti nejlepsi nejsou schopni se s timto problemem vyporadat. -
Pavel TišnovskýZlatý podporovatelNaprosta pravda, optimalizovat bez profileru v mnoha pripadech nevede k cili. Mnohdy se az clovek divi, protoze ceka, ze tady a tady se program bude sekat (vnorene smycky atd.) a az profiler odhali, ze ve skutecnosti je to uplne nekde jinde. A kvuli pravidlu 90/10 (90% casu se stravi v 10% kodu) je opravdu lepsi se zamerit na problemova mista, nez ztracet cas optimalizaci neceho dalsiho. Druh -
JS (neregistrovaný)To neni treti pristup, mame na mysli ruzne urovne. Ja mluvim spis o navrhu, o uroven vys. To mate napriklad moznost pouzit obecne databaze nad SQL nebo si napsat vlastni. Pokud si napisete vlastni, mozna usetrite, protoze muzete jeji datove struktury a algoritmy prizpusobit na miru vasemu problemu. Obecna databaze je radove mene prace, ale o rad pomalejsi. V obou pripadech muzete samozrejme profilovat a optimalizovat, ale radovy rozdil vam uz zustane, protoze vychazi z toho rozhodnuti.
Druha vec je, ze i s profilerem je malokdy citelne, co vlastne zpusobuje tu pomalost. Muze se vam snadno stat, ze nejsou zadna zjevne pomala mista, jenom ohromna hromada mist, ktera jsou trosku pomala (coz tezko poznate, jak moc ktere je, kdyz nemate srovnani), a tato hromada se vam nascita do jednoho velkeho bloatu. Tento typ pomalosti mi prijde nejbeznejsi v modernich aplikacich, a je velice tezke oznacit konkretni algoritmus jako vinika (protoze obvykle jsou v opravdu kritickych mistech pouzity rozumne algoritmy). -
Tomas Z. (neregistrovaný)Ja myslim, ze to jde i na tehle urovni. Pokud nejprve pouziju databazi a zjistim, ze jsem pomaly, tak minimalne uz vim, jakou funkcionalitu tohoto typu potrebuji a bude se mi lepe psat nahrada (to ze to budu vedet na zacatku podle designu je skoro vzdy iluze). Podobne u knihoven - pokud je prilis obecne napsana, muzu funkcnost prepsat potom, kdyz uz vim ze to je problem. Nebo se muze ukazat jako lepsi pouzit cachovani/memoizaci, nebo partial evaluation techniky (vcetne treba predkompilace, to jde i u te DB).
S tim druhym bodem v zasade i souhlasim, zvlaste kdyz do hry vstoupi vypadky z kesi nebo dokonce swapovani. I kdyz si myslim, ze vetsinou je to "jen" otazka zkusenosti a dostatecneho usili.
ČLÁNKY DO MAILU