Výkonný počítač na programování.

29.9.2011 23:33 | Přečteno: 4407× | poslední úprava: 30.9.2011 00:05

Upgradoval jsem domácí počítač a přikoupil jsem k tomu i další obrazovky. Teď mám Core i7 2600K @ 5GHz, 16 GB RAM a čtyři obrazovky. Kupodivu celá tahle opičárna vyšla docela levně.

Můj starý procák (Phenom 2 Quad 3 GHz) už nestačil s výkonem, takže jsem se rozhodl upgradovat. Podle uniklých prezentací výkon Buldozeru za moc nestojí a Core i7-3820 nepůjde taktovat, takže volba padla na 2600K. Docela jsem uvažoval i o 2500K, který nemá hyperthreding a je o třetinu levnější.

Vedle procáku jsem potřeboval podvozek. Intelácké desky jsou si v podstatě podobné jako vejce vejci, takže jsem vzal nejlevnější splňující moje požadavky: Asus MB P8P67. Dražší desky v podstatě nabízejí pouze extra sloty pro grafárny, což nepotřebuju.

Sandy Bridge jdou dobře taktovat, a zvýšená voltáž nezvyšuje spotřebu v idle. Takže procák měl běžet přetaktovaný 24/7. K tomu jsem potřeboval dobré chlazení. Nakonec jsem sáhl po Antec Kuhler H2O 920. Je to hybridní vodník v podstatě nejlepší chlazení co jde ještě namontovat do skříně a nevyžaduje externí tepelný výmněník.

Větrník v tomhle provedení by byl obrovský a zabral jeden nebo dva sloty pro RAM. Na CPU sedí jen malá pumpa a okolo je spousta místa. Přetaktovaný CPU občas může běžet na plný výkon 24/7 takže na chlazení záleží. Sandy Bridge jde dobře taktovat, ale člověk si nemůže být jistý jestli se procák nepřehřívá a nevkladá IDLE instrukce (nebo se nepodtaktuje)

Hry už mě nebaví, takže jsem vyhodil starou,výkonnou a hodně nenažranou grafárnu. Nová by měla mít hodně výstupů a rozumnou spotřebu. Sapphire 6770 Flex podporuje 4 monitory takže volba byla jednoduchá.

Ramky jsem koupil nejlevnější na 4x4 GB @ 1600MHz. Za X let plánuju upgrade na 4x8 @ GB 2200 MHz. Kromě toho mám SSD disk a pár dalších HDD, s CD jsem se neobtěžoval. Celé to napájí 500W OCZ zdroj (postačující). Na bednu si moc nepotrpím, nacpal jsem to do staré minitower bedny a nechal otevřené pod stolem. Výmněník od CPU se do bedny celý nevejde, takže jsem vyřízl otvor a nechal to přečuhovat.

Tímto se dostáváme ke taktování. Procák běžel na zakladní vcore až do 4400 Mhz. Dostal jsem se někam k 5200 MHz s vcore 1.55V, šlo by to ještě dál ale nebyl důvod. Nakonec jsem zakotvil na 4944 MHz, vcore 1.46 V. Po 24 hodinách na CPUBurn je pořád stabilní na teplotě 68 stupnů C. V idle je teplota procesoru okolo 58 stupnu.

Výkon jsem moc netestoval, takže sem nepošlu žádná čísla. Jen jsem si napsal primitivní test abych zkontroloval zda s přetaktováním roste výkon. To se nedělo, bylo potřeba zakázát v biosu speedstep aby se procák dostal do TurboBoost . Teprve potom výkon vzrostl zhruba o 30% oproti základní frekvenci. Nechal jsem běžet CPUBurn 24 hodin, výkon zůstal stabilní, takže procák se nepřehřívá a TurbuBoost skutečně funguje stabilně.

Kromě toho mám tři 22" monitory. Širokoúhlé nudloidní displaye jsou bohužel dnes jediná volba, je to asi celosvětová konspirace proti programátorům. Naštěstí je to tu workaround, některé displaye lze otočit vertikálně do pivot mode. Z dřívějška jsem měl dva Dell Ultrasharp 2209WA 1650x1050 22", nejsou špatné ale jsou lepší. Chtěl jsem větší rozlišení ve stejné velikosti. Jediný současný monitor který to splňuje je Eizo SX2262W, ten je ale na mě trochu drahý. Naštěstí se dříve vyráběl Lenovo ThinkVision L220X, který má stejné parametry a pořád lze sehnat použitý nebo dokonce nový. Postupně asi nahradím oba starší monitory tímhle Lenovem.

U tří monitorů je třeba si hlídat jas monitorů. Většina PVA/IPS panelů neumožňuje snížit jas na rozumnou úrověň. Existuje ale jednoduchý trik: lze snížít jas jednotlivých RGB složek ze 100% na 20%, potom je jas rozumný a pořád jde regulovat v hlavním menu.

Provozovat tři monitory v linuxu jde dobře. Opensource ovladače jsem nezkoušel, s closedsource radeon ovladači z Ubuntu si Gnome napamatovalo rozlišení. Po stáhnutí nejnovejších ovladačů přímo od AMD vše funguje dobře.

Tahle konfigurace vytváří virtuální display o rozlišení 3302x1920 (část plochy je uříznutá). Čistá úhlopříčka obrazu je zhruba 40". Určitě by se dal sehnat single display s podobnými parametry, ale cena a přenosnost by byla někde naprosto jinde.

Grafika Sapphire 6770 Flex má celkem 4 výstupy: Single DVI, Dual DVI, HDMI a DisplayLink. Na DisplayLink jsem za 30 euro koupil aktivní adaptér na Single DVI. Kromě tří displayů je připojená ještě televize v obýváku přes 10 metrový HDMI kabel. Počítač zárověň slouží jako multimediální přehrávač.

Spotreba: V idle (nevytížený počítač bez monitorů) je to 110 W. Pod zátěží to jde obvykle k 180 W, nejvíc jsem naměřil 280W při CPUburn v 8 vláknech a se zatíženou grafickou kartou. Tři monitory k tomu přidají dalších 150 Wattů. Docela mě překvapilo Lenovo, udávaná spotřeba je 90 Wattů, ale já naměřil jen 50 W (asi nižší jas).

Možná se ptáte kolik to celé stojí, pořizoval jsem to postupně takže nemám přesný rozpočet, ale odhadoval bych asi 1100 euro. Základní deska, zdroj, grafika a bedna nejsou nic extra. Displaye jsou z druhé ruky . Další 100Euro by šlo ušetřit koupením 2500K procesoru, který je v podstatě stejný.

Oproti mému starému Phenomu 2 at 3 GHz to je subjektivně 2.5x rychlejší. Kompilace se zrychlila ze 2minut na 40 sekund. Astronomické výpočty nejsou o moc rychlejší (závisí na HDD), ale počítač je o dost interaktivnější pokud počítá. Oproti Phenomu také o dost klesla spotřeba v klidu (ale to bude asi starou grafárnou, která žrala i trávu u silnice).

A na závěr pár obrázků:

       

Komentáře

[Zdeněk Burda]

O kolik je větší tvá produktivita na takovémto počítači s 3 monitory proti např. výkonově poloviční sestavě s jedním monitorem? Nemyslím to nějak špatně, jen mě to prostě zajímá - zastávám názor, že od určitého výkonu je počítač pro práci dostatečný (pokud nestříháš video nebo neprovozuješ obrovské virtualizované prostředí - ale to bych pak zvážil použití serveru a lehkého desktopu jako klienta.

[Vskutečnosti Saýc]

Jo. A taky bych dneska uvazoval radsi o phenomu a SSD nez o i7 a HDD.

[Trained.Monkey]

Z phenomu 2 jsem odesel a SSD uz mam. i7 ma mensi spotrebu a vetsi vykon.

[JS]

Vic monitoru je dobra vec, ale vykonny pocitac bych vyvojarum zakazal ze zakona. Alespon by se naucili poradne programovat..

[a]

+1 na vykonnych pocitacoch vznikal aj .NET framework, JAVA či Mono a vysledné programy tak aj vyzeraju - pomale a trhane na beznych desktopoch...

[expert]

Pokud navrhnu algoritmus se slozitosti polynomialni, tak bude pomalejsi nez s logaritmickou a nezalezi na vykonu meho PC. Dopln si tyto znalosti...

[Sten]

Pokud nějaký algoritmus poběží sekundu místo deseti milisekund a sežere GiB RAM místo 10 MiB, tak se to na tom výkonnějším počítači dá snést, vaše reakce stejně nejsou tak rychlé, aby v tom byl výrazný rozdíl. Pokud ale na méně výkonném ten optimalizovaný algoritmus poběží sekundu, zkuste si spočítat, jak dlouho poběží ten neoptimalizovaný, když ještě přidáte usilovné swapování

[JS]

Zaprve to neni pravda a za druhe, pokud na vykonu nezalezi, muzete klidne pouzit i slabsi PC.

[pc2005]

Když budou nuceni používat pomalej hw, tak se budou víc snažit hledat ty rychlejší algoritmy.

[xkucf03]

Možná tak když budeš psát ve vimu a tvůj program se nebude muset kompilovat. Pak budeš narážet na limity HW skutečně při běhu programu a může tě to teoreticky motivovat k nějaké úspornosti. Jenže když budeš používat trochu vyspělejší nástroje pro vývoj, nějaké IDE, analyzátory kódu, budeš pouštět automatické testy, budeš kompilovat… tak na ty limity HW narazíš při vývoji (což bude snižovat tvoji produktivitu), nikoli při spouštění programu (na to bude HW stále dost rychlý, předimenzovaný).

[pc2005]

Souhlas testy programů by chtělo mít hotový rychle. Na druhou stranu, metoda dostatečného hardwaru na testy (a předimenzovaného na spuštění) vede k neustálému zvyšování nároků programu na hw. Je to takový bludný kruh asi jako státní dluh.

[Heron]

Proč? Naopak si myslím, že právě dostatečné testování a i profilování vede k lepšímu SW, protože se všechny problémy zachytí hned v počátku.

Navíc on ten HW není až tak brutální, jak si někdo možná myslí, rozhodně to není desetikánosek nejakého lowend, spíše dvojnásobek. A na dostatečně velkých testovacích datech se problém projeví tak jako tak, to obvykle nelze pomocí HW dohnat.

[JS]

Navíc on ten HW není až tak brutální, jak si někdo možná myslí, rozhodně to není desetikánosek nejakého lowend, spíše dvojnásobek. A na dostatečně velkých testovacích datech se problém projeví tak jako tak, to obvykle nelze pomocí HW dohnat.

Ale u desktopovych aplikaci, o kterych je tu rec, muze byt problem sehnat vetsi testovaci data. Ja treba si nemyslim, ze jsou vsechna ta IDE napsana zrovna efektivne, protoze vidim, jak rychle se to vyviji. Uz to samo o sobe je problem. Navic co jsou dobra "testovaci data" pro odezvu IDE?

O tom to prave je. Je jednodussi vzit opravdu velky program a v IDE ho otevrit, vyzkouset zda se to da pouzit, a napsat, ze to proste chce ty a ty HW pozadavky. Co na tom, ze efektivita se nekde ztratila.

[pc2005]

Co na tom, ze efektivita se nekde ztratila.

Jj teďka programuju PICy. Nejvíc mě fascinujou ty super nadupaný programátory, zvláště když já mám zastrkaný drátky do LPT portu .

[luta]

pokud je to jen konicek. Proc ne. Pokud te to ma zivit, jsou dratky s lpt spatny vtip

[pc2005]

Tím jsem narážel na to jak jsou adaptéry přes usb nadupaný funkcema i když stačí LPT a převodník úrovní. V průmyslovém nasazení by to asi nějakou krabičku chtělo - to jistě .

[Josef Kufner]

Ono asi trošku narazíš, až budeš chtít ty dráty do LPT připojit k notebooku. Situace s IDE je velmi podobná – ta molochovitost je cena za univerzálnost. Že už je to trošku extrémní, s tím souhlasím.

[pc2005]

Ono asi trošku narazíš, až budeš chtít ty dráty do LPT připojit k notebooku.

No problemo. Většina notebooků má GPIO, stačí vyvíst. Pokud bych fakt chtěl vyvíjet na notebooku PICy, tak bych stejně asi potřeboval tyhle starý porty. Minimálně bez sériáku bych se neobešel, a přes něj to jde taky.

[Mrkva]

Tam už musíš mít zenerky! :)

[pc2005]

Jinak i u LPT musím mít podpůrný součástky. Ten PIC co programuju má IO 3.3V. I když by zvládl asi i 5V, on ten LPT je dost měkkej (RS232 taky).

[Josef Kufner]

A není jednodušší připojit jednoho brouka do USB než hledat GPIO uvnitř notebooku (a přijít o záruku)? A když už máme toho brouka v USB, proč mu neudělat trošku chytřejší firmware? Ach... ty vlastně nechceš použitelný nástroj... tak to jo.

[pc2005]

A není jednodušší připojit jednoho brouka do USB než hledat GPIO uvnitř notebooku (a přijít o záruku)?

No jenže usb převodníky (třeba LPT) je dost drahá sranda. Najít GPIO není zas takovej problém. BTW to mě připomíná, že jsem chtěl přenášet data po zvukovce...

A když už máme toho brouka v USB, proč mu neudělat trošku chytřejší firmware?

Tohle bych nepsal někomu, kdo se už měsíc snaží napsat vlastní USB stack a je z toho mírně agresivní .

Ach... ty vlastně nechceš použitelný nástroj... tak to jo.

No já nevím, školní usb programátor pro FPGA desku (obsahuje asi nějakej FTDI nebo uC) se zablokuje pokud se nevhodně pustí programování a neodblokuje se ani po rebootu. Musí nastat unplug. Takže třeba práce přes vzdálenou plochu je taková ruská ruleta.

[Grunt]

BTW to mě připomíná, že jsem chtěl přenášet data po zvukovce...

Jak to chceš modulovat?

[pc2005]

Je fakt, že u přenosu dat do PICu by to už byl dost netriviální problém (proto radši LPT, navíc mám motherboard s hafo GPIO). Chtel jsem tím demonstrovat hlavně to, že data jsou přenášet i přes IO u kterých to hnedka člověka nenapadne (hmm má grafika na VGA výstupu kondík? imho ne ).

Jinak pro obecné data jsem chtěl kdysi vylepšit linmodem, ale pak mě vyhořela (dvakrát ) zvukovka a nebylo na čem si s tím hrát. Osobně bych zkusil asi QAM, to je docela jednoduchý a relativně účinný.

[Grunt]

Chtel jsem tím demonstrovat

No to nemusíš. To už jsem zkoušel. Jen je problém že neodhadneš hlasitost a že většina převodníků je δ-σ, takže potřebuješ dobrou modulaci (i kvůli šumu co se přidává po drátě). Jinak hudba jde prát i do LPT (resistor-ladder…základ všech moderních DAC) – to už jsem zkoušel taky.

[Grunt]

Teda digitálně to jde taky. To už jsem též zkoušel. Na portu sériovém. Akorát jsem z toho nedostal víc než 64kb/s (11520n8), takže dobré tak max. pro 8kHz 8-bit nebo něco psychoakustického. …čistě pro zajímavost samozřejmě.

[pc2005]

Hehe jakýpak máš čipset, že dává jen 115200?

[Josef Kufner]

LPT převodník do USB je na nic, protože u něj nelze ovládat jednotlivé piny.

Jednočip schopný komunikovat po USB stojí kolem 60Kč. Např. ATMega8 a podobné.

[pc2005]

Jo jenže nejdřív ho musíš naprogramovat, hotový kit bude stát víc a navíc na USB už musíš mít hotovej stack.

BTW to je jedno, můj programátor nevyžaduje ovládat jednotlivé piny (to LPT snad neumí normálně ne? změna se provádí maskováním).

[luta]

ta sw implementace USB do atmegy je kdo ví jaká..někdy to jde, někdy ne.. lepší je hodit tam rovnou ft232r a mít po problémech..

[pc2005]

Takže vlastně používat UART .

[luta]

tak tak člověk si ušetří občas dost problémů jak s hw tak sw na PC navíc ft232r může být i opticky oddělen.. vím že třeba usbasp programátor chodí dobře, ale sw usb bootloader v atmega128 mi nechodil téměř vůbec takže než se pak trápit, tak tam nacpu ftčko a je to

[Grunt]

To jo…a nebo se to také dá brát jako klíčová konkurenční výhoda, která může stát až vedení, pokud nebude muset platit za nezbytné nářadí za které ostatní budou muset platit desetitisíce a ještě bude schopen si ho přizpůsobit dle požadavků (za to se myslím chtějí další desetitisíce). Tolik k tvému širokému rozhledu.

[luta]

mě MCU programování prozatím i jako studenta živí, takže myslím, že mám rozhled docela dobrý. Je pravda, že bych ho neměl, kdybych to do teď dělal jako koníček na drátkách z lpt

[Grunt]

Aha. No tak to zas z druhé strany. Ale určitě se shodneme na tom, že drátky z LPT jsou prostě základ, přes který si musí projít ať chce nebo ne.

[luta]

to souhlasím :) někde tu lpt potvoru taky ještě mám

[pc2005]

Pokud budeš testovat a provozovat aplikaci na kompu, kde test nebude omezen výkonem hw, tak aplikace už nebude tuplem omezena. To ale znamená, že se většina programátorů nebude patlat s vymýšlením efektivnějších algoritmů, ale dá tam první, co je napadne. Jejich komp to zvládne. To ale bude znamenat, že si budou muset uživatelé koupit výkonější stroj. Programátor si řekne, že když už maj výkonější stroj, tak tam přidáme další funkce. Čímž se náročnost časem zvýší tak, že si bude muset koupit rychlejší stroj. Tím se kruh uzavírá a dochází k zacyklení a neustálému navyšování.

Samozřejmě tu budou vyjímky, ale co jsem se koukal, tak většina preferuje Javu přes čistým céčkem.

[Heron]

Tak ještě jednou a konkrétně

Jestliže mám vzorek dat o 10^9 prvcích, tak při použití blbého algoritmu to testování neprojde, zatímco při použití dobrého ano. Je to jasné? Na dostatečně velkém vzorku testovacích dat nic jak exponenciálné, ani polynomiální složitost neprojde. Naopak konstatní a logaritmické projdou velice rychle a tam rozdíl i kdyby dvojnásobku výkonu testovacího HW nehraje žádnou roli.

Je to jasné?

Teď jsem narazil na další app, kterou evidentně nikdo netestoval. Picasa má vážný problém s výkonem jakmile velikost DB překročí velikost IO cache (cca 6GB pro můj případ) a musí se pracovat s diskem. Toto je další příklad, jak by se mělo testovat. Velikost DB o několika terabytech (proč ne?) se do RAM zcela jistě nevleze. Limit na rychlost jednoho dotazu potom může být 200ms. Algoritmy na to jsou.

Zkrátka testovat by se mělo na mnohonásobně větším vzorku dat.

[JS]

Je zbytecne to sem psat, protoze PC2005 evidentne rozumi tomu, co rikas. Ale pointa je jinde - z empirie vyplyva (a ty to potvrzujes), ze aplikace na vetsim vzorku dat nikdo netestuje. Jedna z moznosti (a jde o nadsazku), jak dosahnout toho, aby si toho tedy vsimli, je dat jim slabsi pocitac.

[Heron]

A já bez nadsázky můžu oponovat tím, že pokud to nikdo netestuje, tak si toho nikdo nevšimne ani na pomalém stroji

[pc2005]

Slabší počítač se zahltí stejnými daty, které na rychlým počítači projdou normálně. Na 486 a 3.11 jsem dokázal OS zahltit i obyčejným psaním na klávesnici a/nebo rychlou práci s myší.

[JS]

Evidentne. Proto take slo o nadsazku.

[xkucf03]

A moje pointa je v tom, že můžeš dřív narazit na limity při vývoji (což ti bude překážet v práci), zatímco pro zkušební pouštění toho softwaru ten HW bude stále dost výkonný – viz #109. Nejvíc to bude vidět na vývoji pro jednočipy nebo třeba mobily – na pomalém PC ti bude IDE sotva chodit a při každé kompilaci si můžeš zajít na kafe, ale když si ten program pustíš, stále poběží na mnohem výkonnějším železe, než je jeho cílová platforma. A podobné to bude i u běžných desktopových nebo serverových aplikací – vývoj prostě může vyžadovat (a často vyžaduje) víc hardwarových prostředků než samotný běh výsledného programu.

Něco jiného jsou pak zátěžové nebo výkonnostní testy, kdy se program nechá zpracovat velké množství dat – pak je samozřejmě běh programu náročnější než jeho vývoj, ale takové testy se už obvykle nedělají na počítače vývojáře a taky se nepouštějí tak často (kdežto to zkušební spouštění programu za účelem ověření funkcionality dělá programátor často a obvykle na svém stroji).

Omezovat vývojářům rychlost jejich počítačů je podle mého nesmysl a nic dobrého to nepřinese. Naopak testeři by měli mít HW stejně rychlý (pomalý) jako skuteční uživatelé – a součástí testů bude i kontrola doby odezvy programu a jeho „svižnosti“ a když nebude vyhovovat, je to legitimní důvod, aby testeři vrátili programátorům software k přepracování.

[Ondrej 'SanTiago' Zajicek]

Nejvíc to bude vidět na vývoji pro jednočipy nebo třeba mobily – na pomalém PC ti bude IDE sotva chodit

Coz ale je v podstate jen dusledek toho, ze vyvojare toho IDE nikdo nenutil pouzivat to IDE na pomalem PC ;–) .

[xkucf03]

Na druhou stranu: kdyby je někdo nutil, tak by tu třeba takové IDE vůbec nebylo, resp. nemělo by takové funkce, jaké má teď. A já si tedy radši koupím* lepší počítač, než abych se vzdal těch funkcí.

*) nový počítač jsem si koupil naposledy před třemi lety, takže to nebude tak hrozné…

[JS]

To je otazka. Existuje dost lidi, casto velmi chytrych, kteri zastavaji nazor, ze Vim/Emacs davaji podobnou produktivitu jako IDE se zlomkem HW pozadavku (ostatne proc to tak muze byt uz jsem popsal jinde).

Jake konkretni funkce IDE podle tebe ostatne vyzaduji tak brutalni vykon?

[Grunt]

A nebo by ty funkce byly mnohem propracovanější, logičtější a celkově křupavější, protože by vývojáři museli pálit mozkový čas při návrhu takového IDE místo času procesorového (jeden důkaz za všechny: GNU). Tohle jako hádat se co by bylo kdyby ryby nebyly (což je na úrovni slepice a vejce).

[Michal Kubeček]

museli pálit mozkový čas při návrhu takového IDE místo času procesorového (jeden důkaz za všechny: GNU)

Můžete mi osvěžit paměť? Jaké IDE vyprodukoval GNU projekt? (preventivně: případnou odpověď "Emacs" beru jen jako hloupý vtip).

[Grunt]

No a jsme u toho: Jeden moloch s jedním názvem? Žádný. Provázané malé programy? No skoro mě to nutí říct, že IDE s názvem GNU. Emacs není IDE, ale OS.

[Michal Kubeček]

Jeden moloch s jedním názvem? Žádný. Provázané malé programy? No skoro mě to nutí říct, že IDE s názvem GNU.

Asi bude nejprve potřeba vyjasnit si pojmy. Takže co podle vás znamená to "I" ve zkratce IDE?

Emacs není IDE, ale OS.

Hm, takže Emacs řeší správu paměti? Správu procesů? Filesystémy? Síťovou komunikaci? Drivery pro hardware? Ono občas nezaškodí se trochu zamyslet, než člověk zopakuje nějaký hloupý vtip, a rozmyslet si, jestli je na něm aspoň něco málo pravdy…

[Grunt]

Asi bude nejprve potřeba vyjasnit si pojmy. Takže co podle vás znamená to "I" ve zkratce IDE?

Jedno okno nebo good for noobs? To asi těžko.

Hm, takže Emacs řeší správu paměti? Správu procesů? Filesystémy? Síťovou komunikaci? Drivery pro hardware? Ono občas nezaškodí se trochu zamyslet, než člověk zopakuje nějaký hloupý vtip, a rozmyslet si, jestli je na něm aspoň něco málo pravdy…

insmod lepsi_nalada.ko && insmod trocha_smyslu_pro_humor.ko. Jestli dneska při vstávání někoho něco kouslo do nohy nebo do řiti, tak je mi to sice líto, ale vinen tomu kupodivu nejsem.

[Michal Kubeček]

Jedno okno nebo "good for noobs"? To asi těžko.

Pokud jsem něco zásadního nepřehlédl, jediná zmínka o IDE v tom odstavci má u sebe poznáku "who?" s odkazem na "avoid weasel words". Což je přesně podstata mé námitky: vývojové prostředí - beze všeho. Ale integrované?

Aby bylo jasno: netvrdím, že je IDE nutností nebo správnou volbou, a sám už pár let žádné nepoužívám. Ale považuji za nesmysl vydávat za IDE něco, co je de facto jeho pravým opakem. IDE vznikla právě proto, aby zastřešila do jednoho rozhraní sadu různýc nástrojů (editor, překladače, linker, debugger, profiler, …). Jestli je to lepší nebo horší, to je složitá otázka; ale rozhodně je to něco jiného.

Jestli dneska při vstávání někoho něco kouslo do nohy nebo do řiti, tak je mi to sice líto, ale vinen tomu kupodivu nejsem.

Což ovšem nic nemění na to, že prohlášení Emacsu za operační systém v sobě nemá ani tu špetku pravdy, která je pro dobrý vtip potřeba. To už má Emacs blíž k tomu IDE…

[Grunt]

Pokud jsem něco zásadního nepřehlédl, jediná zmínka o IDE v tom odstavci má u sebe poznáku "who?" s odkazem na "avoid weasel words".

Spíš my šlo ukázat o to, že je tu i jiný názor (jehož zastáncem já jsem) i když ještě asi uplně ne s ostrými hranami.

Ale integrované?

Definuj! Co je přesně ta integrace? GUI? Pro ty co mají klávesnici před monitorem jen z důvodu zpětné kompatibility určitě. Že všechno vypadá jako že to patří do jednoho balíku? Když si Microsoft, tak určitě. Co potom Dev-C++ (co si odmyslíme ten one-hand udělátor)? A co když integrovanost spočívá v tom, že všechny programy se ovládají jediným myšlenkovým principem (stejné zkratky, příkazy, filozofie, usw.) a dají se mezi sebou propojovat (jakože Qemu je schopné nabídnout port na attachnutní GDB (ale jako i třeba terminálu – to všechno patří do té filosofie), které zase dovede použít Emacs pro mixování kódu a assembleru, které využívá objdump pro disassemble…) To není integrovanost? IMHO víc než u některých IDE. Zvláště když se stačí naučit princip u jednoho z nich a vše ostatní už jde tak nějak samo od ruky. Jaký je reálný rozdíl v programu, nástrojích a modulech pokud nepočítám písmenka?To IMHO také byly cíle GNU projektu před tím než vůbec nějaké GNU existovalo. Holt to zatím trošku drhne, ale co v reálném světě binární je, že?

aby zastřešila do jednoho rozhraní sadu různýc nástrojů (editor, překladače, linker, debugger, profiler, …).

Všechno to myslím začalo jako GNU Compiler Collection (což je víc nástrojů, ne jeden), pak se začali přidávat i jiné nástroje, pak nástroje, které výslovně nepatřili do GNU,… No tak holt ne Enviroment, ale Collection. Jaký je rozdíl?

Což ovšem nic nemění na to, že prohlášení Emacsu za operační systém v sobě nemá ani tu špetku pravdy, která je pro dobrý vtip potřeba. To už má Emacs blíž k tomu IDE…

Ew, bite me!

[Michal Kubeček]

Vypadá to, jako byste zcela přehlédl druhý odstavec mého příspěvku. Takže ještě jednou: jsem dalek toho, abych vás přesvědčoval, že IDE je nutnost nebo jediná správná cesta. Jak už jsem napsal, sám také už pár let žádné IDE nepoužívám. Jen jsem prostě proti tomu, abyste ve svém svatém boji vydával za IDE něco, co jím ani zdaleka není. Prostě napište, že IDE nechcete a že pro vás nemá význam, na tom přece není nic špatného, abyste se za to musel stydět a vymýšlet absurdní konstrukce, podle kterých vlastně jakési "IDE" používáte.

[Grunt]

Ach jo. Kubečka dneska očividně něco žere.

jako byste

Jo, jo. Bysme (bychom ať se vyhnu ještě nějakému nacistovi) toho přehlédli. Kdybychom jen mohli. Ale no ták.

[phr]

Byste je kupodivu správně. Bysme ne.

Například tady

[Grunt]

Nacisti už dorazili! Všichni do bunkrů! Zachraň se kdo můžeš!

[xkucf03]

I když se omezíme na ten editor, což je jen část IDE, očekávám od toho napovídání*, proklikávání se ke zdrojákům volaného kódu, kontextové zobrazování dokumentace k metodám/třídám/proměnným, neustálou kompilaci a kontrolu chyb… a tyhle funkce mi zatím žádný jiný program než IDE typu Netbeans/Eclipse nenabídl – pokud ano a navíc bude vyžadovat méně paměti a méně žrát CPU, budu jedině rád.

Podle některých tady jsou ti programátoři líní/neschopní a jejich programy jsou pak hardwarově náročné – jenže zatím se prostě nenašel nikdo tak schopný a pracovitý, aby vytvořil program se stejnou funkcionalitou a menšími hardwarovými nároky. Tak co mám dělat jako uživatel toho programu? Nepoužívat „nenažraná“ IDE, vzdát se těch funkcí a používat programy, které spotřebovávají minimum zdrojů? Nebo raději používat to „neefektivně“ napsané IDE, které i přes to funguje na mém několik let starém počítači dobře, svižně (je to použitelné a ještě tu je celkem velká rezerva)?

*) které vychází z toho, že editor „chápe“ třídy a metody – ne že jen hloupě napovídá slova, která se vyskytují v souboru/projektu.

[Grunt]

očekávám od toho napovídání*

které vychází z toho, že editor „chápe“ třídy a metody – ne že jen hloupě napovídá slova, která se vyskytují v souboru/projektu.

Jo, jo. Pamatuju ještě takový malí editor VRML z dávných dob. Ten ten kód též důmyslně chápal a dovedl perfektně napovídat. No nakecal toho fakt tuny. Se docela divím, že takový modul za ta léta do Emacsu/Vimu/čehokoliv ještě nikdo nenapsal.

proklikávání se ke zdrojákům volaného kódu

Co to? Shell ti nestačí?

kontextové zobrazování dokumentace k metodám/třídám/proměnným

Já si vystačím s man a info. Asi budu divný.

neustálou kompilaci

Si nacpi GCC do cronu, když ti to něčemu pomůže.

Podle některých tady jsou ti programátoři líní/neschopní a jejich programy jsou pak hardwarově náročné – jenže zatím se prostě nenašel nikdo tak schopný a pracovitý, aby vytvořil program se stejnou funkcionalitou a menšími hardwarovými nároky. Tak co mám dělat jako uživatel toho programu? Nepoužívat „nenažraná“ IDE, vzdát se těch funkcí a používat programy, které spotřebovávají minimum zdrojů? Nebo raději používat to „neefektivně“ napsané IDE, které i přes to funguje na mém několik let starém počítači dobře, svižně (je to použitelné a ještě tu je celkem velká rezerva)?

Omyl. To je už několik let staletí trvající boj mezi dvěma skupinami. Myslíš, že to je jen v oblasti programování? Pche. V strojírenském oboru je to ještě horší. Tvůrci (povětšinou jednotlivci) malých, ale důmyslných a promyšlených zařízení co si vystačí s tužkou, papírem, pravítkem a strojírenskými tabulkami vs tvůrci obřích komerčních mrch, které se dělají na Pro/E, Catích či jiném softwaru za statisíce, ne-li milióny (, které sami stojí statisíce, ne-li miliony) co se najednou nedají vyrenderovat ani na nejnovějších grafikách a co mají jednou rukou věčně podepřenou hlavu a druhou klikají nějaké předdefinované šroubky (teda aspoň z pohledu první skupiny) na tom obřím bastlu. Bastl je samozřejmě drahý, nákladný, těžký, funkčnost všelijaká, ale většinou ne moc svižná (kdo najde podobnost s Firefoxem, ten má dva bludišťáky ode mně).

[Grunt]

Čistě pro zajímavost: Absolutní state-of-art (kdo zná GeForce řadu Quadro?) při nástupu do takové firmy dostáváš automaticky i když jdeš spojovat jen dva jäckly. To není žádná položka.

[Grunt]

To není žádná položka.

Teda ta mašina, ten jäckl většinou jo.

[podlesh]

Jo, jako bych se vrátil v čase, to byly flame Ale tohle je opravdu slabota.

První dva body se dají kombinací ctags+vim zařídit, bod 4 jsem řešil indenzivním používáním indent (ten najde syntaktické chyby typu nezavřená závorka) a méně intenzivním používáním make (tam se pak najde ostatní). Bod 3 je v pohodě dokud používám GNU knihovny (tam stačí man a info), u "3rd party" už to bývá horší a neustálé přepínání do browseru není to pravé...

[Grunt]

bod 4 jsem řešil indenzivním používáním indent (ten najde syntaktické chyby typu nezavřená závorka)

Neexistoval on kdysi v dávných dobách na to jakýsi udělátor co se snažil vehementně vynutit z gcc nějaký objektový kód (line samozřejmě označil) a nedal pokoj dokud ho nedostal? Osobně to dělám také tak. Chyba v programu je jen do té doby než z toho GCC vykouše nějaký kód.

Bod 3 je v pohodě dokud používám GNU knihovny (tam stačí man a info), u "3rd party" už to bývá horší a neustálé přepínání do browseru není to pravé...

Na to snad i existuje nějaká iniciativa, ne? Doxygen myslím? Ale jinak propojovači trubek z jedné strany na druhou (trubka nebo API knihovny/frameworku, jaký je rozdíl?) jsou odsouzeni k dlouhé a bolestivé záhubě, takže proč se jimi zabývat?

[pc2005]

Neexistoval on kdysi v dávných dobách na to jakýsi udělátor co se snažil vehementně vynutit z gcc nějaký objektový kód (line samozřejmě označil) a nedal pokoj dokud ho nedostal? Osobně to dělám také tak. Chyba v programu je jen do té doby než z toho GCC vykouše nějaký kód.

Jako, že by to upravilo překlep:

xval=1;
yval=2;
write(xyval+3.14);

na

write(xval+3.14);

nebo

write(yval+3.14);

Brrrr.

Ale jinak propojovači trubek z jedné strany na druhou (trubka nebo API knihovny/frameworku, jaký je rozdíl?) jsou odsouzeni k dlouhé a bolestivé záhubě, takže proč se jimi zabývat?

To myslíš jak?

[Grunt]

Jako, že by to upravilo překlep

To je chyba logická, ne syntaktická. Od toho mám zase GDB, protože jsem líný přímo něco psát do kódu a znova ho kompilovat.

To myslíš jak?

No to radši ani nechtěj vědět.

[pc2005]

Pokud to dokáže rozpoznat, tak OK. Ale i u syntaktickejch se dá poměrně jednoduše najít chyba, která po opravě vede k chybnému programu. Například chybějící "}" a za kterým příkazem má být.

Povídej přeháněj.

[Grunt]

Počkat, ale logické chyby nerozeznává GDB, ale já (jen jeho pomocí). To už i na ně udělali nějaké udělátko? Samozřejmě naprosto nejlepší varianta je logické chyby nepsat.

[pc2005]

Tak pokud to bereš jako céčko, tak není definovaná žádná, včetně té funkce . Navíc jsem myslel z nějakého neznámého důvodu, že chceš aby to ten program snažil opravit :-/. Jestli jen detekci, tak to není problém.

[Grunt]

Navíc jsem myslel z nějakého neznámého důvodu, že chceš aby to ten program snažil opravi

Proč bych to proboha dělal?

[pc2005]

Njn, ale tohle:

jakýsi udělátor co se snažil vehementně vynutit z gcc nějaký objektový kód (line samozřejmě označil) a nedal pokoj dokud ho nedostal?

Tomu moc nepomohlo .

[Grunt]

Jinak jsem si toho nevšiml, ale to nevypadá jako přeložitelný kód. GCC by hučelo, že konstanta xyval na řádku XY není definovaná, jestli mi ještě oči dobře slouží.

[xkucf03]

Co to? Shell ti nestačí?

Nestačí. V mém editoru (IDE) najedu kurzorem např. na volání metodu a jedním kliknutím nebo klávesovou zkratkou přeskočím na její zdrojový kód.

Já si vystačím s man a info. Asi budu divný.

Totéž – nemusím se přepínat jinam a tam vyhledávat např. název metody (který si musím buď zapamatovat a ručně zadat nebo zkopírovat přes schránku). Stačí někam najet myší/kurzorem na místo, kde se metoda volá, stisknout klávesu a v plovoucím okně vidím dokumentaci k metodě, její parametry atd.

Si nacpi GCC do cronu, když ti to něčemu pomůže.

Jednak je to dost těžkopádné řešení a jednak by bylo potřeba ještě nějak dostat informaci o chybách do editoru – aby se podtrhly chyby. A ve výsledku pak bude to volání kompilátoru (samostatní proces) a předávání výsledku (případných chyb) do editoru (jiný proces) hardwarově více náročné, než když IDE volá kompilátor interně pomocí jeho API.

Neříkám, že se bez těchto „vymožeností“ nedá programovat, ale řekl bych, že je to o úroveň pohodlnější a příjemnější práce a umožňuje to člověku se víc soustředit na vlastní programování než na obsluhu nástrojů.

[Grunt]

Nestačí. V mém editoru (IDE) najedu kurzorem např. na volání metodu a jedním kliknutím nebo klávesovou zkratkou přeskočím na její zdrojový kód.

GDB ti zobrazí u metody název modulu (cestu) a číslo řádku (většinou už stačí napsat jen příkaz line a sprostě to okopírovat když ti funguje gpm). Věřím, že kdyby GDB umělo klikat, tak to bude dělat právě tak. Ostatní programy/moduly/nástroje to mají většinou obdobně.

Totéž – nemusím se přepínat jinam a tam vyhledávat např. název metody (který si musím buď zapamatovat a ručně zadat nebo zkopírovat přes schránku). Stačí někam najet myší/kurzorem na místo, kde se metoda volá, stisknout klávesu a v plovoucím okně vidím dokumentaci k metodě, její parametry atd.

Znovu: Nevím co Emacs, ale vim jednoznačně klikat neumí. Proto má příkaz man jen tři písmenka (a dá se volat přímo z emacsu jestli si to ještě dobře pamatuju).

A ve výsledku pak bude to volání kompilátoru (samostatní proces) a předávání výsledku (případných chyb) do editoru (jiný proces) hardwarově více náročné, než když IDE volá kompilátor interně pomocí jeho API.

No nevím v čem si zvyklí ty, ale Dev-C++ to dělá tak, že si zavolá GCC a snaží se v jeho výstupu najít řádek, který obsahuje string line. Ten následně označí. Celá záhada.

[AHAHA]

Pár dalších věcí (konkrétně Eclipse a Java):

- vedle metody okamžitě vidíš, jestli metoda překrývá metodu z předka

- CTRL-T na metodě ti ukáže v hierarchii tříd, kde je daná metoda překrytá

- po uložení souboru ti správně doplní importy tříd, doplní chybějící @Override a final, kde je to vhodné

- CTRL-SHIT-G ti ukáže všechny použití dané třídy, metody (na to grep použít nejde)

- vizualizace spousty věcí, např. WSDL

- okamžitá kontrola na chyby pro spoustu věcí (třeba XML podle DTD)

- kontextová nápověda, např. v XML ti nabídně jen tagy z DTD. Viděl jsem, jak IntelliJ Idea dokáže dvoukrokové napovídání, tzn. ti ze znalosti "Integer i = " dokáže napovědět i "Integer i = obj.getCount()". Jak přesně to funguje ale nevím.

- pokročilá analýza kódu (FindBugs)

- integrace VCS - je velmi příjemné, když ti editor ukáže, který kód ještě není commitnutý (tohle žel bohu umí Eclipse jen na úrovni souborů, NetBeans i v rámci souboru).

- a skoro bych zapomněl na refactoring - introduce variable, introduce method, constant, přesun tříd mezi packagema s upravenými referencemi atd. atd.

[Grunt]

Ok, tak Javu nevím. V době vzniku GNU snad ani žádná neexistovala. Na to už snad asi opravdu bude lepší použít to Eclipse.

[xkucf03]

Viděl jsem, jak IntelliJ Idea dokáže dvoukrokové napovídání, tzn. ti ze znalosti "Integer i = " dokáže napovědět i "Integer i = obj.getCount()". Jak přesně to funguje ale nevím.

To dělají Netbeans běžně – např. napíšeš:

long x = System.

a radí ti to v první řadě:

currentTimeMillis();
identityHashCode(provider);
nanoTime();

pak je čára a pod ní nápověda všech dalších členů ze System (které už nedávají valný smysl, když se snažíš hodnotu dosadit do long proměnné). Nevidím v tom až takovou magii, ale je to velmi užitečné a člověk se nemusí rozptylovat s tím, co v daném kontextu nelze použít. A když nejde o obecný typ (jako ten long), ale o nějakou konkrétnější třídu, tak je často jen jedna možnost a stačí odentrovat to, co ti IDE napovídá jako první možnost – tím se docela šetří klávesnice

[AHAHA]

Ale tohle je jednokrokova napoveda. Jde o to, ze ta IDEA ti dokaze napovedet i objekt na kterem je metoda spustena. Je to popsane tu:

www.jetbrains.com/idea/features/code_assistance.html

Je fakt, ze uzitecne je to jen nekdy ...

[JS]

Prijde mi, ze napriklad prave to automaticke doplnovani override a final jsou veci, kde IDE jen zalepuje nedokonalost jazyka. Pokud to IDE muze doplnit automaticky, proc to v tom jazyce vubec je? To same plati pro refaktoring - kolikrat mi prijde, ze refaktoring resi problemy, ktere by s jinym systemem trid (napr. generickymi funkcemi s ad hoc polymorfismem, coz je v soucasnosti asi muj nejvetsi favorit) neexistovaly.

No a co se tyce te analyzy. To se jiste hodi. Ale nevim, proc bych potreboval zrovna nejakou super-aktualni verzi - vetsinou staci analyza, toho, na cem jsem zacal delat, to co jsem udelal pred 10 minutami uz si pamatuji. Pozadavek mit "analyzu kodu v realnem case" mi prijde trochu jako audiofilie - zni to sexy ale realny dopad na produktivitu to nema zadny.

[JS]

Ostatne, kdyz uz jsme u te analyzy - daleko vice bych uvital nejakou analyzu toho, jak se program chova za behu, spis nez aby me to kazdych par vterin informovalo o tom, ze jsem jeste nedopsal nejakou funkci. Na to by se meli autori IDE/kompilatoru zamerit spis.

[AHAHA]

Ad override - tady docela souhlasim, anotace je zbytecna a jeji popisna funkce by se mela nechat spis na IDE.

Ad final - tady nesouhlasim - podle final properties se da na prvni pohled urcit immutable tridy, coz je casto velmi dulezite. Je pravda, ze toto by taky mohlo staticky analyzovat IDE a zobrazovat, zatim to ale zadne nedela.

Jinak ale souhlasim s tim, ze IDE jsou tu castecne i proto na zalepovani nedokonalosti. S tim se ale musime smirit, spousta jazyku je "here to stay".

Ad generickymi funkcemi s ad hoc polymorfismem, ale predpokladam, ze treba refactoring "prejmenovani metody" je dobre pouzitelny i tam.

Ad analyza: mel jsem na mysli hlavne odhalovani chyb, ktere se zrejme hodi co nejrychleji po jejich vzniku.

[Grunt]

A jinak ještě, a teď fakt jen čistě pro zajímavost, i nějaký ten udělátor pro porozumění kódu se v rámci GNU projektu v FSF pokoušeli. Kdo ví o co se pokoušeli ještě. Když už nic, tak alespoň snaha o integraci se zapřít rozhodně nedá.

[JS]

Vsechno co rikas, vyjma te permanentni kompilace, lze udelat s velmi nizkymi HW naroky (a treba Emacs ve spolupraci s ctags a dalsimi utilitami to dovede take).

Ta permanentni kompilace, ta mi ovsem tedy jasna neni (konecne, striktne vzato to neni featura, ale implementacni zalezitost). Jak zlepsuje produktivitu to, ze se kompiluje porad, misto aby se kompilovalo dejme tomu kdyz clovek dopise funkci a rekne, ze to je hotove? Dela mi to VS, nevim jak to vypnout, a rad bych (jediny uzitecny moment ktery to dava je, ze nemusim znat syntaxi VB, staci proste chvili zkouset, ale to spis vypovida o tom, ze jsem lama).

Prijde mi to dost rusive. Asi jako kdybych psal nejakou praci, a nekdo nade mnou stal a kecal mi do toho. Ja vim sakra, ze funkce nic nevraci, jeste to nemam spocitane! Nemam automatickou kontrolu/doplnovani rad (uz se mi ve VS stalo, ze mi spatne neco automaticky doplnilo, ja si toho nevsiml a slo o chybu - zachycovala se nespravna vyjimka).

Co se tyce toho napovidani - ja si myslim, ze pokud uz programujete, mel byste vedet, co chcete kam napsat, a tak vas fakt, ze neco je v napovede, co tam byt nema, nemusi vubec trapit (alespon me to problem nedela). Nicmene, i to lze slusne resit pres ctags nebo prediktivni napovedu.

[pc2005]

Picasa má vážný problém s výkonem jakmile velikost DB překročí velikost IO cache (cca 6GB pro můj případ) a musí se pracovat s diskem.

Jenže kdyby měl vývojář stroj s 256MB RAM, tak by na ten limit přišel poměrně rychle . A kdyby to optimalizoval, aby to při 256MB jelo uspokojivě, tak by to jelo rychle i na rychlejších strojích.

Pokud testuješ na vzorku dat o velikosti n na počítači o výkonu v, tak neotestuješ n+1 dat, kde pak může být nějakej kritickej zlom a neotestuješ ani výkon v-1, protože bys musel počítač schválně zpomalit (ono asi část zpomalí IDE, ale pokud je komp fakt nabušenej, tak rozdíl může být důležitý). Pokud začneš testovat n+1, tak neotestuješ n+2 a pokud půjdeš víc dál, tak budeš potřebovat rychlejší hw, tedy v+1. Což tě opět vzdálí od obyč kompu.

[xkucf03]

Jenže kdyby měl vývojář stroj s 256MB RAM, tak by na ten limit přišel poměrně rychle

Programátor není tester. A pokud musí zastávat obě tyto role jeden člověk, ať si na testovaní sedne k pomalejšímu stroji (nebo to pustí v pomalejším virtuálu), resp. stejně pomalému, jako budou mít uživatelé. Nevidím ale důvod, proč mu ztěžovat pracovní podmínky v době, kdy je v roli programátora a vyvíjí software.

[pc2005]

IMHO Programátor by měl být i tester. Ta komunikace mezi dvěma osobami dost zdržuje a je ztrátová. Když programátor naprogramuje něco, co testerovi nepojede, tak bude muset začít po oznámení testera na tý části začít znova (pokud se vůbec domluví).

S poslední větou souhlasím, viz. #144. Ovšem přinutit testera na pomalej počítač je podle mě prakticky nereálné.

[Ondrej 'SanTiago' Zajicek]

Rekl bych, ze to ani neni tak o algoritmech s lepsi asymptotickou slozitosti, jako spis o onech multiplikativnich konstantach. Asymtoticka slozitost je jednoducha - uz z navrhu algoritmu a kodu je casto jasne, jaka bude. Oproti tomu u tech multiplikativnich konstant (zda jsou dostatecne male na to aby to pri beznem pouzivani bylo dostatecne svizne) je to spis vec citu a testovani.

Pokud vyvojari (a testeri) budou aplikaci vyvijet (a testovat) na hi-end strojich a uzivatele to pak poustet na nekolikrat pomalejsich low-end strojich, tak se to pak tam bude pri beznem pouzivani plouzit. Takze uzivatele bud mohou upgradovat hw nebo vymenit sw. Pokud zvoli prvni volbu, tak to v konecnem dusledku vede na to, ze uzivatele pravidelne upgraduji svuj hw jenom proto, aby udrzovali krok s vyvojari, a potrebuji stale vykonejsi hw na delani te same prace (Wirthuv zakon: Software is getting slower more rapidly than hardware becomes faster).

[Michal Kubeček]

Teoreticky máte pravdu, ale v praxi - zejména u větších firem - jsou často priority trochu jiné. Z hlediska nákladů pak je často menší problém jednorázově koupit "větší kladivo" než průběžně řešit problémy, protože perfektně optimalizovaný kód je komplikovanější a náchylnější k chybám. Z pohledu programátora hračičky to vypadá smutně, ale tak to prostě nezřídka je.

[JS]

Otazka je, zda se to skutecne az tak vylucuje, tyhle 2 veci. Ja snim o tom, ze kompilator bude za programatora vybirat datove struktury (a tedy castecne i algoritmy) na zaklade experimentalni analyzy o behu programu. To je jedna z veci, ktera by IMHO pomohla.

[JS]

Jeste bych rad poznamenal, ze vsechny ty analyzatory jsou diminishing returns. Napriklad ve VS si muzu nechat najit reference na promennou nebo funkci - ale to funguje jen tehdy, pokud zrovna neni zakomentovana nebo v komentari, nehlede na to, ze to najde jenom funkci/promennou, ne obecny retezec. To je priklad situace, kdy jednoduche reseni (grep) je ucinnejsi nez sofistikovany vynalez (syntakticky analyzator kodu).

Jiny podobny priklad je doplnovani. Kdyz vybiram veci k doplneni, je mi celkem jedno, ze seznam veci, co mohu doplnit je 100% korektni (resp. nevadi, pokud je tam neco navic). Prediktivni doplnovani (treba i na zaklade zdrojoveho textu) je snadna a ucinna metoda, ktera nevyzaduje znalost semantiky zdrojoveho kodu.

A tak bychom mohli pokracovat. Nejsem proti pokroku, ale mam dost duvodu si myslet, ze nejde vzdycky tim spravnym smerem.

[AHAHA]

ad 1) ale vzdyt to je prave to, co chci. Ja chci reference na kod, ktery neco dela, ne kod, ktery uz roky vyhniva v nejakem zakomentovanem kodu. Krom toho, IDE maji samozrejme taky grepove vyhledavani, ale je navic pekne integrovane.

ad 2) no mne zalezi na tom, jestli je to korektni napoveda nebo ne. Pokud neni a ja ji vyberu, je to chyba, kterou se doufejme brzy dovim. V IDE se vam toto nestane. Krom toho, pokud napr. chce naseptat metodu jineho objektu, tak vam to nebude fungovat (v pripade, ze je naseptavani pouze v ramci souboru) nebo bude naseptavani vicemene nepouzitelne (naseptavani v ramci projektu).

[podlesh]

ad 1) ale vzdyt to je prave to, co chci. Ja chci reference na kod, ktery neco dela, ne kod, ktery uz roky vyhniva v nejakem zakomentovanem kodu. Krom toho, IDE maji samozrejme taky grepove vyhledavani, ale je navic pekne integrovane.

Případně hledání referencí provede zároveň i ten grep a najde je i v komentáři (pokud to nevypnu, samozřejmě). Výsledky pak mám pohromadě a můžu si je seskupit/odfiltrovat podle typu. Jinými slovy: autoři nektěrých IDE takovéto požadavky slyšeli a vyslyšeli.

To samozřejmě nic nemění na tom, že grep je velmi užitečný nástroj který neustále používám (a sed, awk, cut, wc, atd atd).

[JS]

Ad 1) Problem je, ze staticka analyza nikdy nebude dokonala, a pokud ano, omezi moznosti jazyka. IDE sice mozna pak zvysi produktivitu, ale v jazyce, ktery ji predtim uz umele omezil. Napriklad reflexe nikdy nebude 100% rozlustitelna statickou analyzou, a proto je lepsi na statickou analyzu pri cteni nespolehat (a ono uz jen i ty komentare, ktere obcas obsahuji jmena funkci a trid, jsou problem); je to dobre pro kontrolu, ale to je cele (a i tam rekl bych je typova inference produktivnejsi).

Ale chapu, ze se na to, jako zastance metaprogramovani, divam trochu jinak. Podle me metaprogramovani je produktivita, a je to typ produktivity nekompatibilni s tim, co za produktivitu pry prinasi IDE.

Ad 2) Nevim, jak bych mohl vybrat nekorektni napovedu. Pro dany objekt se vzdycky ujistim, co prislusna metoda dela - jinak bych asi neodvedl dobrou praci.

[AHAHA]

Ad 1) Na tohle mam opacny nazor - uprednostnuji statickou analyzu i na ukor omezeni jazyka. Reflexe je dobry priklad a vec, ktere se vyhybam az neni k zbyti. Jeji pouziti uznavam pouze ve specifickych prikladech - napr. frameworcich, urcitych knihovnach apod. Reflexe (a dalsi staticky neanalyzovatelne techniky) totiz vytvari urcitou magii, ktera je pro nove prichoziho tezce rozlustitelna.

Ad 2) Pokud je napoveda/doplnovani nekontextova, pak velmi snadno. Samozrejme pokud na overeni spravnosti metody pouzijete nejaky jiny zdroj, tak neni problem, pak tam ale moc nedava smysl pouziti te napovedy/doplnovani.

[Sten]

Výkonný počítač je důležitý pro kompilace (takové optimalizované C++ se díky šablonám může na slabších strojích kompilovat i několik dní), ale přikázal bych jim používat na debugging virtuální mašinu se schválně omezenými zdroji

[xkucf03]

Výkonný počítač je potřeba např. na spouštění testů – když to totiž bude trvat dlouho, vývojáři nebudou (tak často) pouštět testy, což může zhoršit jejich produktivitu nebo kvalitu práce.

P.S. jinak ale chápu jak to myslíš. Zajímavé např. je, jak některé předělávky starých her v HTML5 dokáží pořádně vytížit dnešní několika GHz procesor, zatímco před dvaceti lety ta hra fungovala na třiosmšestce s 20 MHz

[Michal Fecko]

P.S. jinak ale chápu jak to myslíš. Zajímavé např. je, jak některé předělávky starých her v HTML5 dokáží pořádně vytížit dnešní několika GHz procesor, zatímco před dvaceti lety ta hra fungovala na třiosmšestce s 20 MHz

presne +1

[JS]

Nejak mi k tomu chybi ten dukaz, ze se skutecne pise kvalitnejsi software..

[Já]

Kde by se taky vzal, když tu jsou tmáři, co považují za efektivní metodu provádění výkonových optimalizací použití „pomalého“ počítače pro vývoj. A někdo je dokonce poslouchá.

[Trained.Monkey]

+1

[poky74]

Já bych to tak zle neviděl, sám používám jistou obdobu.

Na vývojový server, na kterém píšu jednu aplikaci který je hodně citlivá na paměť jsem dal 1GB ram, což mě prostě nutí psát algoritmy a datový struktury tak optimalizovaný jak jen to je možný, protože tu paměť prostě nemám, mít tam 16GB jako na ostrým serveru, tak mi je jedno že támhle je proměnná která se už nepoužije, táhmle to by šlo udělat malinko lépe...

Snažím se k tomu přistupovat jako programátoři tak před 15 lety, každej bajtík se hodí. Používání frameworků je něco nemyslitelného, mám svůj, umí jen to co potřebuju a využíívám a je mnohem rychlejší a lehčí než cokoli jiného co poskytuje stejné funkce. Vývoj je sice o něco pomalejší, ale ve výsledku se mi to vyplatí (čímz neříkám že je to pravidlo, spíš to bude naopak, ale zrova u  tohohle projektu se to hodí).

Předpokládat že když někdo dělá něco jinak než já nebo jinak než je zvykem není moudré.

[Trained.Monkey]

A ted si predstav ze potrebuju otestovat jak se aplikace bude chovat s nekolika uzivately (sty/tisicy/apod). Moje workstation ale stezi utahne aplikaci + IDE, takze se na nejake narocne simulace samozrejme vykaslu. Na vykonne masine ale muzu nahodit 50 virtualnich OS, propojit je do site a simulovat v prakticky realnych podminkach.

Proste blablabla, jsem super a delam v assembleru, tyhle kecy uz jsem slysel. Mozna to ma smysl u vyvojare ovladacu a embedded systemu, ale u webovych stranek je to overkill.

[poky74]

Nechápu, proč na mě útočíš. Píšu to na čtyřjádru s 16GB paměti, testy při vývoji probíhají ve virtuálu s jedním jádrem a GB paměti, ten mezičlánek je tam právě kvůli co největší optimalizaci, pro testy při větších změnách se pro jistotu používá jiný virtuál s 8 jádry a 8GB paměti, ještě se nestalo že by testování na tom ukázalo nějakou chybu, leak, zacyklení etc... To prostě proto že ten kód znám velice dobře a dávám si na tom záležet.

Proste blablabla, jsem super a delam v assembleru, tyhle kecy uz jsem slysel.

Osobně se mi tedy více zamlouvá vývojář co si dá záležet, nedělá prasárny, neleakuje mu to, necyklí se to, vývojář který zná dobře svůj kód a ví přesně co od něj může čekat v krizových situacích, než patlal, co nasadí nějaký nechutný cms, kvůli několika fcím naloaduje 10MB frameworků a je mu to jedno, protože já přece spousty paměti a spoustu jader.. "Ten server to přece nějak zvládne", tyhle kecy už jsem taky slyšel, po měsíci od spuštění aplikace mu to každej den v půl 5 začne swapovat a po pár minutách je server mrtvej. Co udělal? Do cronu hodil scripty který když zjistěj že dochází paměť tak restartují daemony a tak to "vyřeší".

Tenhle přístup je mezi nynějšími "takyvývojáři" stále častější a já se toho odmítám účastnit.

Myslím že pro většinu případů je nejideálnější nějaká střední cesta, nic se nemá přehánět.

[Trained.Monkey]

To mi trochu ujelo, sorry.

[Heron]

Snažím se k tomu přistupovat jako programátoři tak před 15 lety, každej bajtík se hodí.

Tohle lze pochopit několika způsoby. Nevím, který myslíš ty, ale ve mě to evokuje například že rok se ukládá na dvě platná místa (19XY) a že se používaly jednotlivé bity aktuálního slova jako flagy pro nějaký stavový automat. Tak takhle snad ne, to byl tragický omyl. A nedivil bych se, kdyby právě z tohoto důvodu někomu ujely v diskusi nervy.

Nebo také tím, že se používají obecné algoritmy a datové struktury, které za daného použití mají nejmenší spotřebu paměti (s tím, že ale nijak uměle neomezují rozsah). Tak takhle ano.

[JS]

Tragicky omyl? Vazne?

S tim neomezenim rozsahu - no, nevim. Napr. by se dalo tvrdit, ze 32-bitove systemy omezuji rozsah oproti 64-bitovym. Presto se v nekterych pripadech zjistuje (napr. JVM), ze 64-bitu neni uplne to ono. Ono kdyz mate 3 nulove bajty na kazdy pointer, tak to zacne byt sakra zajimava uspora.

[Michal Kubeček]

Ovšem za jakou cenu…

[JS]

Je to kompromis. Nemyslim, ze otazka 32 vs. 64 bitu ma uspokojive reseni (a stejne tak si nemyslim, ze pred 30-40 lety mela uspokojive reseni podobna otazka, totiz rok ve 2 nebo 4 cifrach).

[Michal Kubeček]

Řekl bych, že dnes už má - nepočítám-li různá embedded zařízení - zcela uspokojivé řešení.

[JS]

Neverim, ze je ta zalezitost u konce. JVM se ten problem snazi resit pres kompresovane pointery, a moje predpoved je, ze nas pro tohle ceka HW podpora, v urcite podobe.

Ostatne, myslim si ze HW architektury jeste nerekly posledni slovo, co se tyce pointeru. Z hlediska procesoru by mohlo byt uzitecne vedet, co v pameti je (nejspis) pointer. Mohl by provadet automatickou dekompresi nebo dokonce prefetch jeste ve chvili, nez se skutecne ta adresa pouzije (podobne jako provadi predikci skoku).

[Michal Kubeček]

To, že se to někdo snaží řešit, ještě automaticky neznamená, že je to problém, který řešení vyžaduje. Vezmu-li v úvahu, že 2x4GB kit stojí dnes kolem 1000 Kč bez DPH, což je cena, za kterou bych před pár lety pořídil čtvrtinu, odmítám na normálním PC (jak už jsem řekl, něco jiného jsou třeba embedded systémy) řešit fiktivní "problém dvojnásobně dlouhých pointerů". Zvlášť poté, co vím, jaké šílené a zbytečné komplikace 32-bitová architektura v memory managementu přináší.

Ten "problém" je úplně stejně fiktivní jako "problém" čtyřnásobně dlouhých adres a větší paměťové náročnosti IPv6. Za dobu, co o tomto "problému" slýchám, vzrostly velikosti používané pamětí tolikrát, že se v tom jednorázové "krát čtyři" hravě ztratí. Ale ani tam to někomu nebrání pořád strašit větší spotřebou paměti - jen u IPv6 aspoň vím proč.

[pc2005]

Zvlášť poté, co vím, jaké šílené a zbytečné komplikace 32-bitová architektura v memory managementu přináší.

To ale není vina bitů, ale Intelu.

[Vskutečnosti Saýc]

A vzrostla tak i velikost cache u procesoru?

[Michal Kubeček]

Ano.

[Vskutečnosti Saýc]

Skoro to tak nevypada, Pentium 2 melo 512 KB L2 cache, zatimco Sandy Bridge Core procesory maji 256 KB na jadro. To mi nepripada jako tak velke zvyseni.

(Dobre, pridali L3, ale ta je sdilena celym procesorem, takze si nemyslim ze je to totez)

[Michal Kubeček]

Totéž… U toho Pentia II nemělo smysl rozlišovat, jestli je cache per-core nebo pro celý procesor, když bylo jádro jen jedno. Co je podstatné, je rychlost přístupu k ní. Čísla po ruce nemám, ale docela by mne překvapilo, kdyby dnešní Sandy Bridge četl z L3 cache pomaleji než tehdejší Pentium II z L2 cache.

[Grunt]

a že se používaly jednotlivé bity aktuálního slova jako flagy pro nějaký stavový automat. Tak takhle snad ne, to byl tragický omyl. A nedivil bych se, kdyby právě z tohoto důvodu někomu ujely v diskusi nervy.

Tak to se snad používá i dnes, ne? Ani ne tak proto kolik to žere (ono nejmenší adresovatelná jednotka má stejně 32-bitů (na 32-bitovém systému), takže když použiješ dva bity, zbytek je výplň o 30-bitech, takže si s tím stejně moc nepomůžeš a tak se to pokud vím nikdy ani nepoužívalo), ale protože se s tím pohodlně pracuje (vymaskování bitů, posuny, usw.). Ono např. i v kodecích kde se řeže na různé bitové délky jedním bitem počínaje je to všechno uloženo třeba ve 32-bitech a více a řeže se to na jednotlivé bitové délky až když to vylézá do souboru (třeba dokonce i až u Huffmana).

[pc2005]

Ani ne tak proto kolik to žere (ono nejmenší adresovatelná jednotka má stejně 32-bitů (na 32-bitovém systému),

To je relativní . Sběrnice do RAM už dlouho nemá 32 bitů. Spousta procesorů i když má registry 32bitový, tak může přistupovat ke kratším délkám. Například x86 (i když tam si nejsem jistý, jak se to po těch 64 drátech přenáší). Nebo třeba TMS34010, kterej adresuje po bitech .

[Grunt]

Spousta procesorů i když má registry 32bitový, tak může přistupovat ke kratším délkám.

Jo to je jasný, ale překladač to stejně zarovná na těch 32-bitů, ne?

[pc2005]

U TMS to právě není pravda. Andrew Morton kvůli tomu musel patchovat GCC.

U x86 nevím, tam to má asi jednodušší. Nicméně mě to nedalo a zkompiloval jsem si krátkej program s bitovejma posunama. A tam se pracuje i s 8 bitovými částmi registrů. Ale myslím, že x86 má nějaký omezení na systémový operace (musí být zarovnané na počet bitů aktuálního módu +-). S obyč daty by ale měla schopna pracovat libovolně.

[Ondrej 'SanTiago' Zajicek]

Na x86 (a asi i na mnoha dalsich) se bezne pouziva prirozeny alignment, tedy ze primitivni typy jsou zarovnane na nasobky sve velikosti. Pokud mas ve strukture 8* uint8_t, tak zabere 8 B, ne 32 B (jak by ty bylo kdyby kazdy uint8_t byl alignovan na 32bit). Nejmensi adresovatelna jednotka je tedy byte.

[Grunt]

Též fakt. Ale bacha, že nominální velikost = počet alokovaných bitů platí jen u pole (na různých architekturách je to různě). Dál pokud se probublává interními mechanismy alokace se to může kvůli rychlosti porůznu zarovnávat a nakonec jeden int může být výhodnější než se snažit cpát do jednotlivých bitů. Jak už jsem řekl, to je IMHO vhodné jen kvůli ulehčení si práce. Jinak i většina kodeků (a věřím že se to bude týkat i ostatních programů, které nějak pracují s bity) i když může použít i jeden bit všechno cpe do uint16_t (týká se zvuku, je dost možné, že u obrazu nebo u nějakých komplikovanějších mrch to bude ještě víc) a nikdo se nepatle s alokací pro přesně daný počet bitů (většinou je to tak že se alokuje pole o maximální myslitelné velikosti + něco navíc a nad ním se pak pracuje). A jinak že nekecám úplné blbosti: Tak se to netýká paměti ale registrů procesoru (viz MOVZBL):

5	  uint8_t a = 3;
=> 0x0804839a <main+6>:	 c6 45 ff 03	movb   $0x3,-0x1(%ebp)
(gdb) step
6	  int b = 4;
=> 0x0804839e <main+10>:	 c7 45 f8 04 00 00 00	movl   $0x4,-0x8(%ebp)
(gdb) 
7	  int c = 5;
=> 0x080483a5 <main+17>:	 c7 45 f4 05 00 00 00	movl   $0x5,-0xc(%ebp)
(gdb) 
8	  uint8_t d = 6;
=> 0x080483ac <main+24>:	 c6 45 f3 06	movb   $0x6,-0xd(%ebp)
(gdb) 
10	  a = d << 2;
=> 0x080483b0 <main+28>:	 0f b6 45 f3	movzbl -0xd(%ebp),%eax
   0x080483b4 <main+32>:	 c1 e0 02	shl    $0x2,%eax
   0x080483b7 <main+35>:	 88 45 ff	mov    %al,-0x1(%ebp)

Asi to bude mít co dělat s rychlostí (mám 32-bitový procesor, no schválně by mě zajímalo co by to dělalo na 64-bitovém). Nižší módy už neběží nativně, ale spíš se asi povětšinou budou něco jako emulovat. Důvod existence: Zpětná kompatibilita. Tož tak.

[Já]

Tohle jsem si myslel taky, než jsem viděl, jak se dokáže ten hodící se bajtík promítnout do brutální exploze nákladů na další údržbu aplikace. Stejně tak nevěřím v lehčí a rychlejší vlastní se „stejnou funkcí“. Většinou to stejnou funkci nemá. A většinou to není správně. Občas samozřejmě ano, ale pokud se to uvádí jako obecné pravidlo, mávejte červeným praporkem.

A ano, dost věřím tomu, že celá tahle idea se slabším počítačem spíše než že by přišpěla k lepšímu návrhu aplikace, vede k pochybnému handlu korektnosti a udržovatelnosti za drobné výkonové optimalizace. Což považuju za hloupé.

[JS]

Ne, to neni metoda jak je provadet, to je metoda jak si vsimnout, ze jsou potreba.

[Já]

I to je špatně. Rychlejším počítačem se umlátí nezřídka jenom krajně nezajímavá třída výkonostních problémů a chybně omezené škálovatelnosti.

[JS]

Pokud vite, jak vas algoritmus skaluje (popr. skaluje jinak nez linearne), nepatrite do kategorie, ktera by si zaslouzila pomalejsi pocitac.

Problem dnesni doby je spoustu malych veci, ktere se nascitaji dohromady. Vy ani nevite, ze prochazite ten kratky seznam 50x, protoze jich v aplikaci mate desitky. Proste my nevime, co bychom meli optimalizovat, a je nam to jedno, protoze rychly pocitac to nejak upocita. Na pomalem pocitaci bychom si museli vsimat vseho a tim bychom to psali efektivneji.

[Já]

Jenže ten pomalejší počítač je často pomalejší úplně jiným způsobem. Pokud aplikace reálně poběží na šestnácti xeonech a pár desítkách GB paměti, může dávat smysl ji optimalizovat úplně jinak než aby běžela dobře na mém dvoujádrovém laptopu a 4G paměti. Ten ostatně ani nemá šanci při reálných datech a objemu provozu jakkoliv přežít.

Občas může být výhodnější projít krátký (co je krátký?) seznam padesátkrát, než s ním dělat něco jiného, protože optimalizace, co by se příznivě projevila na pomalejším počítači by se naopak mohla nepříznivě projevit na rychlejším, protože to upočítá, ale už třeba neprotáhne přes síť nebo z disku, nebo cokoliv, neboť není rovnoměrně rychlejší, ale jenom nějak rychlejší, někdy i třeba pomalejší, v něčem.

Nebo příklad z opačné strany zase, mám výkonově optimalizovat Androidí aplikace na emulátor, který je suverénně nejpomalejší androidá „zařízení“ vůbec? Nonsens, přeci.

[JS]

To je jiste zajimavy argument, ale trochu miji pointu, ktera je, ze my nevime, co mame optimalizovat. Ani nevime, ze je to vlastne spatne - kdybychom neznali historii, mohli bychom si myslet, ze to proste lepe udelat nejde. A to je podle meho nazoru ten mylny pohled, ktery nam davaji rychle pocitace.

Je to asi jako s nerostnym bohatstvim. Dokud ho mate hodne, muzete plytvat, i kdyz fakticky mate technologii na to setrit. Logicky je to absurdni, ale empirie takove chovani lidi potvrzuje.

[Já]

To nevíme, protože není vůbec snadné to zjistit. A použití staršího nebo pomalejšího počítače není ten kouzelný trik, který nám to řekne. Spíš šidítko a sebeklam.

[JS]

Pouziti pomaleho pocitace nas nuti to zjistit. Ale jasne, pokud to nekdo nechce vedet, pak nebude pouzivat pomaly pocitac. Proto bylo od zacatku zrejme, ze jde z moji strany o nadsazku. Ovsem ten problem je realny.

[Já]

Já si skoro nemyslím, že bych potkal aplikaci, kde by použití pomalejšího počítače něco získalo. Pořád se bavíme moc abstraktně.

[JS]

Ja jich potkal hodne, staci se podivat do historie.

[Heron]

ze my nevime, co mame optimalizovat

Od toho jsou profilery a debugery, ne?

[JS]

Nerikam ze ne, ale to funguje jen do jiste miry. I pro pouziti profileru musite vedet, co ta aplikace ma vlastne spravne delat (myslim uvnitr). A to u slozitych aplikaci byva dost problem vedet.

[xkucf03]

A s čím nesouhlasíš?

• na rychlejším počítači bude vývojář častěji pouštět testy (resp. na pomalém ho to bude otravovat a bude to dělat jen ve chvílích, kdy musí – např. před commitem)
• spouštění automatických testů není na škodu, naopak může odhalit chybu dřív, než si jí všimne člověk
• ve výsledku to zlepší kvalitu softwaru nebo efektivitu práce

Tedy ne že bych byl až takový magor do testování, od toho jsou jiní, ale tohle můžu potvrdit z vlastní praxe – když testy poběží několik minut, tak se na to vykašlu (většinou), ale když to bude pár vteřin, tak je klidně budu pouštět každou chvíli – a díky tomu můžu dřív přijít na to, že jsem např. něco rozbil a je potřeba ten kód zase dát pryč nebo přepsat – čím dřív na to přijdu, tím líp.

[Heron]

+1

[JS]

Nesouhlasim s tim, ze to zlepsuje kvalitu software (a tedy, pokud zahrnujeme pod efektivitu prace fakt, ze se vyrobi neco kvalitne, nezvysuje to ani efektivitu prace). To bych chtel empiricky dolozit. Zatim mi pripada, ze empirie je presne opacna - vykonne pocitace zpusobi nabubrelejsi software.

Jinak proti automatickym testum nic (moc) nemam (krome toho, ze si myslim, ze existuji ucinnejsi metody na prevenci/odhalovani chyb).

[xkucf03]

vykonne pocitace zpusobi nabubrelejsi software

Celé je to myšleno za předpokladu: „za jinak stejných okolností“ – tzn. že např. posadíš stejného programátora před výkonnější stroj a on bude pracovat stejně, jen ty testy nebo kompilace bude moci pouštět častěji – tudíž když napíše kód, který neprojde testy nebo nejde zkompilovat (každý dělá chyby), tak na to přijde dřív a vyplýtvá méně času – než když bude celé dopoledne něco smolit, kompilace/testy pustí až přes oběd a po návratu z oběda zjistí, že to má blbě a jde to předělávat.

Samozřejmě si můžeš myslet, že javisti jsou čuňata a píší nenažraný kód – budiž, o tom se teď nechci hádat – ale představ si, že posadíš svého „ideálního programátora“ nebo sebe před HW, který ho nebude brzdit – pak si myslím, že ty výsledky budou lepší.

Jestli si chce někdo zkoušet, jak běží jeho program na slabém HW, ať si udělá virtuální stroj s odpovídajícími parametry a na něm to spouští – ale spouštět je něco jiného než vyvíjet, kompilovat atd.

[JS]

Ty ses tomu problemu vyhnul, ze sis tam dosadil idealniho programatora, ktery dela jen to spravne a tak mu to jen pomuze. Ja se ale ptam, jaky maji vykonnejsi pocitace pro vyvojare dopad v realnem svete, na realne vyvojare (kteri nejsou tak uvedomeli, aby to pousteli na pomalem stroji). A tam tvrdim, ze to pozitivum (v prumeru) prokazane neni.

[Heron]

Já si nemyslím, že by byl problém ve výkonu programátorova HW. Problémem jsou spíše testovací data. Velmi často se testuje na malém vzorku dat a tam to běží rychle na kterémkoliv HW. Mělo by se testovat na vzorku dat daleko větším, než při reálném nasazení. HW (lowend), který je o polovinu pomalejší než highend nemusí odhalit rozdíl mezi O(log n) a O(n^2) na malém vzorku dat. Podle mého názoru to tedy o výkonu HW moc není a vývojáři by měli mít HW takový, aby se jim dobře programovalo a nebrzdilo je to.

[JS]

Empiricky vzato, jelikoz software je nenazranejsi, tak nejspis vykon HW problem je. Tim nerikam, ze znam reseni.

[rastos]

vykonny pocitac bych vyvojarum zakazal ze zakona. Alespon by se naucili poradne programovat..

Predstav si, že vyvíjaš klient-sever aplikáciu v jave. (Zasahuješ do kódu aj servera aj klienta a tie by nemali byť na jednom stroji.) Na jednom stroji sa hodí mať pustený eclipse, browser s dokumentáciou, dva VM pričom jeden z nich beží Oracle SQL. Aký HW by si dal takému programátorovi?

[JS]

Asi nejaky na kterem nepobezi Java?

Vazne, slo o nadsazku. Vite co to je? Ale opravdu, nevidim zadne velke doklady o tom, ze se pres veskery "technologicky pokrok" v IDE a podobne pise kvalitnejsi software. Myslim, ze je to diskutabilni.

[rastos]

nevidim zadne velke doklady o tom, ze se pres veskery "technologicky pokrok" v IDE a podobne pise kvalitnejsi software.

Ide o to, čo znamená "kvalitnejší". Ak to znamená "kompaktnejší" tak je pravda, že sa teraz píše kód menej kompaktný, ako kedysi (so slzou oku spomínam čo dokázal F29-Retaliator v púhom pol megabajtovom .exe). Na druhej strane ak kvalitnejší znamená "ľahšie portovateľný" alebo "modulárnejší" alebo "znova použiteľný", alebo "robustnejší" ... tak sme na tom teraz asi, lepšie než kedysi.

[JS]

Nemam ten pocit. Robustnejsi kod? Kde jsou casy CICSu, o kterem se matematicky dokazalo, ze je spolehlivy? Lepe portovatelny? Mluvite o Jave, ktera je mene portovatelna nez C? Nebo nez Common Lisp?

Modularni a znovupouzitelny. Asi mluvite o OOP. Zatim jsem nevidel, ze by nekdo vzal tridy z jednoho projektu, kde se s tim dopredu nepocitalo (tj. nevytvorili neco jako knihovni abstrakci) a pouzil je v jinem. Naopak jsem videl Unixovy shell a Forth - to jsou podle meho vrcholy modularity.

Jediny pokrok, ktery nastal, je, ze mame lepsi knihovny (z toho mozna take plyne to zdani portovatelnosti). Tedy mame nejaky software uz napsany. To ovsem nic nerika o tom, ze piseme lepsi software dnes.

Ano, jsem trochu dabluv advokat.

[xkucf03]

Zatim jsem nevidel, ze by nekdo vzal tridy z jednoho projektu, kde se s tim dopredu nepocitalo (tj. nevytvorili neco jako knihovni abstrakci) a pouzil je v jinem.

A kde je ta hranice mezi (dobře navrženou) interní třídou nějakého programu a „knihovní abstrakcí“?

[JS]

Rozdil bych rekl je v tom, ze nemusis stavet dalsi abstrakci na druhe strane. Napriklad kazda aplikace ma typicky vlastni system treba logovani a spravy chyb, nebo zamykani. Stejne tak, knihovny maji take kazda vlastni system, jak tyto veci resit. Nekde v aplikaci se to musi propojit. Pokud pouzivas cizi knihovnu, typicky musis napsat nejaky dalsi spojovaci kod, ktery tohle obstara. To same musis udelat, pokud z nejakych trid chces mit takovou znovupouzitelnou knihovnu.

Asi je to fundamentalni problem, a je otazka, zda ma vubec nejake rozumne reseni. OOP k jeho reseni prispiva, ale v relativne omezene mire (konkretne tim jednim smerem, ze umoznuje v nekterych pripadech navrhnout snaze pouzitelne knihovny).

[xkucf03]

so slzou oku spomínam čo dokázal F29-Retaliator v púhom pol megabajtovom .exe

A co teprve takový VLAK – 12 kB.

Ten odkaz jsi sem neměl dávat, teď si kvůli tobě budu celý víkend hrát DOSové hry

[David Ježek]

jó vlak, ten jsem hrál někdy před 17 lety (a dohrál ). příjemná vzpomínka

[podlesh]

Vazne, slo o nadsazku. Vite co to je? Ale opravdu, nevidim zadne velke doklady o tom, ze se pres veskery "technologicky pokrok" v IDE a podobne pise kvalitnejsi software. Myslim, ze je to diskutabilni.

A já jsem ještě neviděl doklad o tom, že Alexandr Makedonský není hrdina!! Asi půjdu rozbít židli...

Ale opravdu, software se asi nepíše kvalitnější, ale rozhodně se ho píše více.

[Trained.Monkey]

Nedavno jsem byl tri tydny na notebooku (Core2Duo, 2GHz, 4GB RAM, SSD). Oproti tomu jsem asi trikrat rychlejsi na sve soucasne sestave. Delam ve Scale na velkem projektu, takze vykonny procak vyuziju.

Tohle mam na svuj hobby projekt, v praci mame vse virtualizovane, tam mam Core 2 Quad 6600. A pokud si praci vezmu domu tak je rozdil hodne poznat.

[alblaho]

Waw. Scala. Nechceš někdy napsat své zkušenosti?

Jazyk je to mocný, ale nejsem si jistý, jestli to není spíš na závadu. Trochu se bojím, že je to akademická splácanina. Kolik z těch fíčur opravdu používáte? Které jsou nejužitečnější a které máte interně zakázané?

[xkucf03]

Trochu se bojím, že je to akademická splácanina.

Náhodou… už jsem ji viděl několikrát použitou v ostré praxi Ale chce to prostě v týmu mít nějakého nadšence, který to trochu popostrčí a ostatním pomůže – učit se nový jazyk úplně na zelené louce se v rámci běžného projektu moc nedá.

[alblaho]

Vím, že se to v praxi používá, je v tom tuším Twitter....

Jde mi spíš o to, jestli ta obrovská bohatost jazyka (imho mnohem větší než C++, tam jsou "jen" šablony a vícenásobná dědičnost) nepřináší spíš komplikace.

Dovedu si představit, že si ve Scale budu něco hackovat sám pro sebe. Ale nedovedu si až tak dobře představit, že budu dělat v týmu různě dobrých lidí s různými preferencemi na složitém projektu. Vlastně mi Scala mírně připomíná Perl.

Zkrátka jsem přistoupil na onu primitivnost Javy, diskutujeme o designu řešení, ale jazykové prostředky řešit nemusíme.

[xkucf03]

jo, souhlas, tohle se mi na Javě taky líbí

[Trained.Monkey]

Se Scalou moc spokojeny nejsem, brzo se budu presouvat na Kotlin.

[Vskutečnosti Saýc]

Proc ne?

[xxx]

WTF? To clovek potrebuje Core i7 na to aby mel na jednom monitoru vim na druhym Chrome s Gmailem a uprostred nejake IDE?

[xxx]

Teda abyste to nepochopil nejak zle, tak bych mel otazku. Proc?

[Bluebear]

Řekl bych, že znám odpověď, i když je spíše emocionální (možná spíš hormonální).

pokud jsi viděl film Armageddon (tuším?) s Bruce Willisem, kde jeden psychicky labilní člen posádky (ne, že by ostatní byli nějak zvlášť stabilní) občas zajde na palubu, kde jsou skladovány jaderné nálože pro rozdrcení meteoru, a sedne si na jednu z hlavic. Na otázku, proč to dělá, odpovídá "chtěl jsem cítit tu sílu mezi nohama"

A samozřejmě, pokud kompiluješ obrovské balíky (třeba si to dovedu představit u vývojáře OfficeLibre a podobných monster), tak tam se hodí každá špetka výkonu.

[JS]

A samozřejmě, pokud kompiluješ obrovské balíky (třeba si to dovedu představit u vývojáře OfficeLibre a podobných monster), tak tam se hodí každá špetka výkonu.

Mozna by pomohl takovy vynalez.. make? (Vazne, vim ze to znas, ale nedalo mi to.. Jak mohli ti nasi predci vubec pracovat?)

[Michal Vyskočil]

Občas je holt nutné použít takový rpmbuild a přeložit LibreOffice sakumprásk. A tam se výkon skutečně šikne.

[CEST]

No, obavam se, ze kompilace muze byt u programatora ta nejjednodussi cinnost (rozumnej pro CPU a RAM). U nas chtel jedes vyvojar lepsi CPU, 8GB RAM a SATA III radic a disky kvuli IDEA IDE. To je proste moloch, kterej sam potrebuje serverovy parametry, aby se v tom dalo delat. Vyslednej program pak muze byt treba jen "Hallo World" a pobezi na 386, ale IDEA potrebuje hodne.

Zlatej vim/gvim

[podlesh]

To je pěkná hovadina - zrovna Idea v pohodě běží na 3GB RAM, dokonce i méně - často se mi stává že po upgrade chvíli v pohodě používám defaultní limit (asi půl giga) než otevřu velký (stovky GB zdrojáků) projekt. To sice pořád funguje ale už to při hledání přemýšlí. Takže je čas zvýšit na Xmx1212.

Co se týče disku, tak standardní notebookový (5400 otáček) dostačuje (pokud tam nemá Windows + corporate antivir, to zabije cokoliv). Samozřejmě jen do té doby než člověk ochutná SSD, ale to není nic specifického pro Ideu a dokonce ani pro programování (kolega začal požadovat SSD poté co viděl že mi OpenOffice nastartují za necelou sekundu).

Celkově bych z toho požadavku usuzoval, že onen vývojář chtěl ve skutečnosti lepší "status" (asi jako se v jiných oborech hraje o velikost kanceláře či výkon služebního auta).

[xkucf03]

stovky GB zdrojáků

To asi nebudou jen zdrojáky, ne?

[podlesh]

Chzbička se vloudila, samozřejmě to jsou stovky MB A i tak je pravda, že podstatnou část zabírají různá data (ať již konfigurace, HTML kód nebo data pro testy).

[Trained.Monkey]

Zajimave, ja tuhle masinu poridil prave kvuli Ideii Momentalne mam Xmx7000. Nejvetsi projekt na kterem obcas delam ma zhruba 260MB zdrojaku (pouze *.java soubory). A Scala plugin nebo profiler dokaze take sezrat hodne pameti.

Fakt nechapu proc se nejak umele omezovat, v nakladech je hardware zanedbatelna polozka.

[podlesh]

Pravda, pokud nepočítám data tak je to jen 40MB na java soubory a zhruba stejné množství jsp a xslt. Takže projekt s 260MB zdrojáky je výrazně větší. A Scala plugin žere opravdu hodně... (jak by se dalo koneckonců očekávat).

Každopádně pointa je v tom, že samotná Idea není žádný moloch který se na čtyřgigovém stroji nerozjede. S tím že na hardware by se šetřit nemělo souhlasím, ale trochu bych pozměnil priority - na prvním místě SSD disk, pak možná paměť pokud potřebuji mít aplikace spuštěné paralelně (zvlášť věci jako virtuální stroj nebo Lotus Notes). Pak teprve procesor, a to opravdu jen při intenzivním používání jazyků s pomalým kompilátorem (jako je scala, nekdy i C++).

[Trained.Monkey]

> Každopádně pointa je v tom, že samotná Idea není žádný moloch který se na čtyřgigovém stroji nerozjede.

S tim se da souhlasit.

[Trained.Monkey]

Ne. Cele tohle jsem poridil abych mohl hrat Pacman pres try obrazovky ve velkem rozlyseni.

[PeDRo]

Nekdo se asi pta proc a nac... ja delam v c# a to nic moc projekt, ale zvoleny hw a treba i 3 monitory uplne chapu! At si rika kdo chce, co chce... Mezi nami vcelari, tedy spis vcelickami, kdyz 1/3 casu cekam az se zkompiluje, rozbehne a kdyz to hodi chybu tak cekam nez se IDE s debuggerem probere... a to treba nemluvim o tom, ze k tomu co delam, jeste testuju ve dvou VM s xp, jedno standard, druhy se zvysenym DPI. Libustka, na C2D s 4G ram! opravdu! Kdo nezkusil, nezazil - nepochopi.

[JS]

Jo, ja bohuzel taky.. IDE s OCD, ktere ma potrebu mi sdelit, ze jsem nedopsal vetu, jeste nez jsem ji dopsal, to je opravdu uzitecne vyuziti vseho toho vykonu.

[CEST]

A nebylo by treba lepsi misto navysovani vykonu zkusit nejaky chytrejsi IDE? Treba takovy, ktery konce vet bude poznavat podle nejakyho specifickyho ukonceni a teprve pak bude necim otavovat. A tudiz kontrola takovyho specifickyho ukonceni bude urcite jednodussi a rychlejsi, nez po napsani kazdyho znaku zacit kontrolovat a vyhazovat chybu.

[xkucf03]

Asi to máš rozbité Já mám oproti počítači popisovanému v zápisku směšné kuličkové počítadlo, ale IDE mi funguje dobře – napovídá všechno, co potřebuji, kontroluje syntaxi, podtrhává chyby… ale až když přestanu psát a rychlé je to dost (nezdržuje, nezasekává se).

[mirec]

+10, ja mám tiež prdítko 1GHz CPU, 1GB RAM, ale je to pasívne chladené, 1 5:4 monitor, no radosť s tým pracovať.

[miho]

Uvazoval jsem o tomto usporadani monitoru. Nakonec jsem ale zvolil dvojici 30" 2560x1600 S-IPS a 24" 1920x1200 TN otocene klasicky. Hlavne kvuli ergonomii (horni hrana monitoru nema byt nad urovni oci jinak se to vymsti na krcni pateri; to se s monitorem v portrait modu dela tezko). A take abych nemusel tocit monitorem kdyz se chci podivat na film. Uz je prilis pozde na to, abych to pocital, ale myslim, ze i celkova plocha je vetsi.

[Trained.Monkey]

Na vasi kombinaci mi vadi ze je to moc roztahane do sirky a nevejde se tam moc textu. S pateri kupodivu problem nemam. Pravidlo o hornim okraji obrazovky ve vysce oci snad vymysleli vyrobci notebooku .

[pako]

já tuhle konfiguraci (monitor na výšku) používám při programování a nestěžuju si, ovšem je fakt že dlouhodobé čumění na vrchní nebo spodní roh obrazovky moc příjemné (fakt je že na ten portrait monitor čučím ze vzdálenosti zhruba odpovídající jeho úhlopříčce)

[pako]

edit

moc příjemné není

[Bluebear]

Tedy, a to jsem si myslel, že šílenec pro silné stroje jsem tu já

Jen otázka: u vodního chlazení na tom možná tolik nezáleží, ale to šasi mi připadá hodně malé (miditower?) - nežhaví se ti tam příliš ty součástky, které nejsou vodou chlazené? Já mám bednu o něco větší, procesor nepřetaktovaný a topí to jak vulkán

[Trained.Monkey]

Je to minitower. Tohle chlazeni fouka vsechno teplo od procaku okamzite ven z bedny. Chipset je stabilne na 40 stupnich. A nechavam case porad otevrene.

[Sten]

Chce to vodou chladit i chipset, disky a zdroj, pak to můžete narvat i do menší krabice

[Semo]

A vedla pristavit vacsi radiator na tu vodu.

[Kvakor]

N8hodou, takový topeňový radiátor (a dělají se i měděné) by dokázal uchladit i opravdu výkonný stroj, navíc bez toho, že by ho bylo nutné ofukovat. Jen ty hadice by trochu vadily.

[Semo]

Nijak nespochybnujem tepelny vykon radiatora. Len som narazal, ze to, ze vdaka vodnikom sa da nastrkat vsetko do miniaturnej krabice este neznamena, ze teplo zmizlo. Iba si majitel musi pristavit tepelny vymenik mimo krabice.

[Trained.Monkey]

Zkousel jsem krabici od bot, ale papir je horlavy

Anyway, na 'tuzing' v podobe blikajich diod a pruhlednych skrini si moc nepotrpim. Do ty bedny se to bez vetsich problemu vejde a vetsi prikoupim, az bude potreba pridat dalsi disky.

[kouzer]

Zajímavé. Moje potřeby po "výkoném pc" se zastavili před víc jak 5ti lety a to mám C2D 1,6GHz, 2GB ram a integrovanou intel grafiku.

A to mi na tom běží Oracle  Express (10.2?), NetBeans (programování v Javě), VirtualBox a Firefox.

A stejně se ten stroj většinu času fláká...

[Michal Fecko]

a ja že skutočný programátor si postačí s vim, make a 1,6ghz atomom

[Sten]

Skutečný programátor si postačí s vim, make a AVR

[Jakub Lucký]

Skutečný programátor píše vim myapp.tar.bz2 :-P

[xkucf03]

Ještě jsi zapomněl, že pracuje na dálku přes ssh spojení, ale používá k tomu telnet klienta

[prqek]

Telnet? Netcat...

[skywaker]

skutocny programator si postaci s FASM

[K42]

Opravdový programátor nepotřebuje ke své práci všechny tyto abstraktní pojmy, je úplně šťastný, má-li děrovač štítků, kompilátor FORTRAN 4 a pivo.

Zdroj: Opravdoví programátoři nepoužívají Pascal, Ed Post, © 1983

[Heron]

Pěkné. Také jsem měl více monitorů (tedy, jen dva 24 + 21), a musel jsem to dát pryč. Zvyknul jsem si na to strašně rychle (doslova během pár minut), efektivita byla úžasná, ale... Nebyl jsem potom schopný pracovat nikde jinde, příchod na single monitor (nedej bože na notebook) byl utrpení. Tak jsem to musel dát pryč.

Zajímal by mě názor ostatních s více monitory.

[ludvik]

V podstatě máš pravdu. Mám to stejné. Ale rozhodl jsem se ignorovat "to jinde" a pokud možno tam nesedat. Mimochodem kdybys ty monitory měl stejné, tak to není za pár minut, ale během první minuty

Děsím se doby, kdy mé krásné 20" 4:3 HP odejdou do nebe. Obrovský širokoúhlý monitor není řešením - sice budu mít víc bodů vertikálně, ale horizontálně si pohorším. Kromě toho ke krajům pak člověk kouká pod úhlem (tedy je to dál) a není to ono. A stavět ty širokoúhly na výšku, z toho mám dost divnej pocit.

[Trained.Monkey]

Mrkni na Lenovo L220X, 1920x1600 ve 22"

[ludvik]

škoda, že už se nedělá

[Grunt]

Já měl dva CRT monitory a kvůli žravosti údajně vyměněno za jeden LCD. No zvyká se na to fakt dobře. I když se na tom jednom monitoru většinou nic důležitého neděje, člověk aspoň může v klidu na jednom číst Ábíčko a na druhém něco dělat aniž by se musel zatěžovat šíleným ALT+Tabováním (když se to zrovna hýbe, přeletí jen očima, nemusí se hledat kde skončil posledně a nemusí furt kontrolovat stav okna pod ním a navíc když se zastaví (třeba kompilace), tak je to hned v periferním vidění vidět). IMHO dva a více monitory opravdu zvyšují produktivitu. Člověk ušetří toho neskutečného ALT+Tabování mezi pornem (či ekvivalentem) a prací. Já bych jako efektivní pracovní prostředí viděl minimálně tři monitory. Jeden jako pracovní plocha, jeden na korespondenci, dokumentaci, firemní diskutování a tak a jeden na porno (či ekvivalent v podobě Ábíčka nebo soukromé korespondence ). Jen mě ještě štve, že se na jeden monitor nedá nacpat konzole a na druhé Xka v jednom sezení.

[Grunt]

Jen mě ještě štve, že se na jeden monitor nedá nacpat konzole a na druhé Xka v jednom sezení.

Což by se zase dalo vyřešit samostatným počítačem. Ok, oprava: Jako minimum pro efektivní pracovní prostředí bych viděl čtyři obrazovky a dva počítače nebo tři obrazovky, jeden počítač a jeden hodně dobrý terminál.

[loki]

Ja mam na toto dva stroje. Jedno notebook na web + im a na zbytek velky stroj s velkym monitorem. :)

[Josef Kufner]

A co s tím vyvádíš, že 3GHz nestačily?

[Trained.Monkey]

Tohle je muj domaci pocitac. Po nocich delam astronomickou aplikaci v Jave. Krome toho obcas nejake vypocty.

[TM]

Proboha, k čemu je dobrý pro jednoho uživatele takto výkonný počítač? To děláte nějaké simulace nebo výpočty anebo to je jen ona typicky uměle vytvořená potřeba, jak je dnes běžné? Pochopím pokud je to zvyšování výkonu a kapacity hobby...
U nás má průměrný vývojář běžné 2 jádrové PC s 2 GB RAM a naprosto to stačí. Přitom není výjímkou rebuild projektu i několikrát denně...

[User682]

zdravim,

muzete nastinit, co vyvijite a v cem vyvijite ? Tak nejak nedovedu pochopit k cemu je potreba takovy vykon. Osobne jsem kupoval vykonnejsi masinu a castecne v tom take hralo roli to, ze "jsem ji musel mit".

Osobne mam Phenom x6 a 16GB RAM a vcelku se to dost flaka. Jak u Javy, tak obcas C/C++ . Od 2 monitoru jsem se pred tydnem vratil k jednomu. Ale toto dovedu pochopit, ze to dost/vetsine lidem pomuze. C/C++ veci se hodne urychlily pouzitim ccache.

gf

[Trained.Monkey]

Delam ve Scale, kompiler je hodne pomaly a inkrementalni kompilace nefunguje spolehlive. Krome toho to obcas neco pocita. Delam v Intellij Idea. Na trech monitorech konecne muzu zaroven videt applikaci, profiler a IDE dohromady.

[User682]

Tak to chapu. Na aplikace, co neumi pracovat ve vice vlaknech narazim dost casto.

gf

[Vskutečnosti Saýc]

IDEA ma profiler? Kde?

[Trained.Monkey]

Nee, mam JProfiler coz je externi aplikace s pluginem. Dal pak funguje dobre VisualVM ktera je zadarmo

[loki]

Slusny stroj, takoveto pocitace schvaluji. Nechapu lidi, kteri kvuli par wattum radeji trpi u nevykoneho atom-based desktopu.

[luta]

takovou masinu bych si nechal taky libit. Ikdyz momentalne mi staci ta i5

[Luděk]

Zdravím, jakou tam máte prosím distribuci. Mám dá se říct srovnatelnou sestavu, ale hlavní použití je na simulace. Prozatím to běží na Win, ale rád bych kvůli kompatibilitě ruzných nástojů přešel na Linux a nevím jaká distribuce by byla vhodná...

[:::]

co provadis za simulace? dela se tam treba nejaky nasobeni velkych matic?

Uz delsi dobu premyslim, ze si postavim stroj na simulace, a docela by me zajimalo jestli je realny vyuzit 4 a vic jader, nebo tam bude uzkym mistem pristup do pameti...

[Luděk]

Simulace lineární, nelineární statika a dynamika, takže implicit a explicit solver, žádné CFD. U implicitu limitující velikost paměti u inverze matice, není žádný problém zaplnit 16 GB. U explicitu je pro mě rozhodující počet jader a výpočetní výkon, na pamět méně náročné.

[Vskutečnosti Saýc]

Tak to premyslej na GPGPU.

[Luděk]

Toto řešení teď úplně nesleduji, nicméně grafiky už mají double-precision jednotky nebo jde o emuluci z sigle-precision? Rozhodně by to bylo výkonově zajímavé, ale je třeba nejdříve na to mít napsané aplikace, aby uměli využívat GPU.

[David Ježek]

Vyčkej pár týdnů/měsíců na odhalení nextgen architektur amd/nv, teď nemá smysl nad tím ani hypoteticky přemýšlet...

[Vskutečnosti Saýc]

Nektere grafiky double-precision umi, ale jsou to ty workstation class grafiky, co uz stoji vic penez. MATLAB by to treba mel umet vyuzit, taky existuji c++ knihovny pokud delas vlastni software.

[David Ježek]

většina grafik DP umí, namátkou z posledních HD 5800/6900 od AMD nebo vyšší Ferminy od Nv. není třeba sahat po workstation kartách, byť je pravdou, že třeba u nvidie dávají quadra/tesly v dp polovinu výkonu sp, zatímco geforce dávají jen 1/8 - uměle zaříznuto. něco podobného mylsím platí pro radeony vs firegl, ale je to myslím 1/2 vs 1/4 nebo tak nějak.

[Grunt]

Docela drsná výmluva když zrovna k programování většinou stačí ekvivalent psacího stroje (mechanický s příkonem 0.0W).

[w4rr10r]

Tak. Co by na to řekl pan Knuth?

[Grunt]

To je mi stejně jedno. Lamy neposlouchám.

[xkucf03]

???

[Grunt]

No já jsem především nepochopil otázku. Co by měl Knuth říkat? Neprogramoval on nejčastěji na trošku lepším psacím stroji?

[Semo]

A navyse: hoci je professor of computer science, tak je znamejsi prave ako vylepsitel toho pisacieho stroja.

[loki]

To jako ze D. E. Knuth je lama? Cetl jste nekde the art of computer programming?

[xkucf03]

Možná myslel láma

[pc2005]

V případě Knutha by to musel být minimálně Dalajláma.

[Josef Kufner]

The art of computer programming je učebnice matematiky, nikoliv programování, ač to s ním velmi těsně souvisí.

[Trained.Monkey]

Ja pouzivam obycejne Ubuntu. Jadro je na vsech distribucich v podstate stejne, neni to jako na windows ze clovek potrebuje specialni edice.

[Michal Kubeček]

Docela by mne zajímalo, kolik z těch mudrců, kteří mají jasno, jak by vývojáři měli mít nevýkonné počítače, se v praxi skutečně zabývá vývojem a laděním a kolik z nich jen mlátí prázdnou slámu, protože nevědí, o čem mluví.

[David Ježek]

hello world v turbo pascalu je snad taky svého druhu vývoj .

[TM]

Ale jo, připojil jsem se nedávno se změnou zaměstnavatele, ale je to denní chleba. Průměrná sestava viz. to co píši výše. Výsledný produkt (velký projekt běžící od 90. let) běží dnes na 32 bitových mikrokontrolérech, ale na PC se ještě před sestavením pro cílovou platformu kompletní projekt testuje přeložený pro x86 pod simulátorem (teprve pak probíhají reálné testy). Práce pro několik překladačů, řadu scriptů v Perlu, píše se v Eclipse (C++, C, Assembler, pomocné věci Perl). Není důvod vyhazovat peníze za nějaká monstra a ukájet se nad jejich kapacitou.
Když čtu moudra o tom, jak se na PC, ve kterém není narváno to nejvýkonnější co je na trhu, nedá pracovat, přestávám chápat, jak vlastně všechen ten software kolem nás vznikl

[Michal Kubeček]

Z té diskuse mám neodbytný pocit, že nemalá část diskutujících si představuje, že práce vývojáře sestává výhradně z psaní v editoru a zkoušení aplikace stejným způsobem, jako to pak bude dělat uživatel. Jenže takhle to není ani u desktopových aplikací a u serverových nebo systémových už to tak nevypadá ani zdaleka.

Navíc nejde jen o vyvíjení a testování nového kódu, ale taky o hledání a opravování chyb. Vezmu-li v úvahu, že takové hledání regrese v jádře běžně znamená 6-8 buildů příslušných balíčků a že jeden build mi na 4x2.4GHz Phenomu trvá 35 minut, pak je představa, že by mi měl stačit jednojádrový procesor na 1 GHz poněkud mimo realitu (je ale jasné, že ve firmě bude praktičtější mít pro podobné účely jeden opravdu výkonný stroj, který budou využívat všichni, než aby měl každý svůj trochu výkonný). Nemluvě o tom, že určité chyby je extrémně obtížné zreplikovat na jednoprocesorovém systému a u některých je to dokonce principiálně vyloučené.

[JS]

Neni ale Linux ponekud specialni pripad? Co do mnozstvi zmen v case je to dost mozna nejvetsi software na svete.

[pc2005]

Souhlas. Na druhou stranu, opravování chyb na pomalým stroji by působilo proti psaní těch chyb. Nejmíň chyb udělali ti, co pracovali v době děrných štítků . To pak si každej rozmyslel dělat chyby. Simulaci pak provádí nejvykonější lehce dostupný hw a to mozek.

Pokud se něco opravuje stylem pokus omyl, tak nutně dochází k blobovatění daného softwaru.

Osobně bych byl asi pro kompromis. Rychlej hw, na bisekci a překlady a zpracování velkých dat. A pak hodně pomalej na otestování datových hrdel. Koneckonců je to přesně metoda návrhu, co používám na PIC. Jenže na to se většina moderních programátorů vykašle, když má k dispozici výkonný stroj.

[AHAHA]

Nejmíň chyb udělali ti, co pracovali v době děrných štítků .

Slozitost programu je dnes ale trochu jinde.

[Grunt]

No…to záleží na tom jestli chceš flame nebo ne.

[pc2005]

To jistě, ale neznamená to, že musí programátor tu složitost tvořit. Většina programátorů dneska taky nedokáže navrhnout vlastní procesor, na kterým by ta jejich aplikace fungovala.

[podlesh]

Docela by mne zajímalo, kolik z těch mudrců, kteří mají jasno, jak by vývojáři měli mít nevýkonné počítače, se v praxi skutečně zabývá vývojem a laděním a kolik z nich jen mlátí prázdnou slámu, protože nevědí, o čem mluví.

Většina zůčastněných se nečím takovým skutečně zabývá a na základě toho mají skálopevné přesvědčení, že ví o čem mluví. No a z toho samozřejmě (logicky) plyne názor, že ti ostatní neví o čem mluví, jsou blbí, líní nebo se zabývají hovadinami - podle nátury.

Podobnost s jinými oblastmi probíranými na abclinuxu není náhodná - je to prostě politika, i když taková spíš k smíchu. Jo a pozor, platí to pro obě strany (jak ukazuje tento dotaz).

PS: Diskusí o IDE jsem se zůčastnil na obou stranách, takže mohu porovnávat. Diskuse o výkonu stroje pro programátora je něco celkem nového (pamatuji časy kdy i překlad obyčejného C nebyl až zas tak zanedbatelný), ale nakonec se to stejně stočilo na IDE.

[JS]

No a z toho samozřejmě (logicky) plyne názor, že ti ostatní neví o čem mluví, jsou blbí, líní nebo se zabývají hovadinami - podle nátury.

Takova vec z toho logicky neplyne a takovy nazor nemam.

(Nicmene mam nazor na vase komentare, a ten je, ze mi pripadaji dost negativisticke, vuci lidem.)