• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
    • přihlásit
    registrace
    ztracené heslo?
    XCHAOSANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API
    /* Toto je klub především pro lidi, pro které je programování jednou z mnoha massive multiplayer online počítačových her, které lze hrát.
        V tomto klubu hrozí sémantická hereze a nezdravě vysoký obsah syntaktického cukru. Nevhodné pro algoritmické diabetiky.
        Od účastníků debaty se předpokládá automaticky přístup k instalovanému GNU C: sudo apt-get install build-essential
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    C (programovací jazyk)#C99 Heslo na české Wikipedii
    Jazyk C - Základy praktického programování V Praze 2oo7 pro SSPŠ Tomáš Harvie Mudruňka a kolektiv - jak si programování v C představuje většina lidí
    http://stevenkobes.com/ctest.html C Programming Puzzlers - nepouštějte se do flamewars v tomhle klubu, pokud neuhodnete aspoň polovinu správně!
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    http://en.wikipedia.org/wiki/C99 C99 is a modern dialect of the C programming language.
    http://cprogramminglanguage.net/ C programming language
    http://cprogramminglanguage.net/c-programming-language-tutorial.aspx C programming language - úvod
    http://en.wikipedia.org/wiki/Criticism_of_the_C_programming_language C makes it easy to shoot yourself in the foot. (ještě že ne do hlavy...)
    http://en.wikipedia.org/wiki/C_preprocessor
    http://gcc.gnu.org/onlinedocs/gcc/Variadic-Macros.html C99 makra s proměnným počtem argumentů - __VA_ARGS__
    http://gcc.gnu.org/onlinedocs/gcc/ GNU C Compiler
    http://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/Optimize-Options.html
    http://bellard.org/tcc/ Tiny C Compiler - prý C99 compliant (min. umí __VA_ARGS__) - vhodný pro skriptování v C - umí #!/usr/bin/tcc -run
    http://en.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest - pokud jste neviděli tohle, tak jste ještě neviděli opravdu nečitelný C zdroják
    http://bellard.org/otcc/ Obfuscated Tiny C Compiler - z tohohle vtípku vznikl Tiny C compiler
    http://en.wikipedia.org/wiki/ANSI_C Jak se střelit do nohy standardizovaným způsobem.
    http://eli-project.sourceforge.net/c_html/c.html ANSI C Specification
    http://www.lysator.liu.se/c/ Různý ANSI C bordel
    http://www.cs.rit.edu/~ats/books/ooc.pdf Object Oriented Programming with ANSI-C - a pak že to nejde
    http://en.wikipedia.org/wiki/Longjmp co jsou to setjmp()/longjmp() knihovní funkce (pro všechny, podle kterých to bez C++ try { } catch() ... nejde)
    http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/dcdc710c27f47c72 C neumí správně počítat (?)
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    http://www.fastcgi.com/ FastCGI is simple because it is actually CGI with only a few extensions.
    http://www.metalshell.com/source_code/18/Mysql_Select.html How to do a simple connection and select with mysql
    http://xmlsoft.org/ The XML C parser and toolkit of Gnome
    http://curl.haxx.se/libcurl/ libcurl - the multiprotocol file transfer library
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    https://dev.arachne.cz/svn/cll1h SVN/Trac jazyka C<<1 (user-friendly nadstavba nad ANSI C99 - ve stylu JQuery vs. JavaScript)
    Benchmark iterace a serializace stringů v různých jazycích vs. v C
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
        moderátor se velice zhruba řídí zvyklostmi moderace, která kdysi platila v řadě konferencí sítě FidoNet ... C != 0xdead */
    rozbalit záhlaví
    REDGUY
    REDGUY --- ---
    KOJA: Neni nejaka programovaci olympiada nebo tak neco, kde pravidelne vyhravaj lidi co pisou v OCamlu, Haskellu a podobne? Sakra, kde jsem to jenom cetl... i kdyz tam samozrejme otazka jestli vyhravaj proto, ze pisou v Haskellu nebo proto, ze jsou tak zatracene chytry, ze zvladnou psat v Haskellu 8)
    KOJA
    KOJA --- ---
    1 odpověď+1
    KILLUA: To v podstate navrhujes, to co popsal Fred Brooks v legendarni (ale bohuzel porad malo zname) knizce Mythical Man-Month. Mel jakousi analogii chirurgickeho tymu. Napr. zde: https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_surgical_team Zni to zajimave, zavery z realneho pouziti jsem necetl (nerikam, ze bych se po nich pidil). Knizku kazdopadne doporucuju, zajimave cteni a s vetsi casti relevantni i po tech letech.

    Ad ninjove, rockstar, superstar a jiny geniove - vyvoj software uz se nejakou chvili paralelizuje protoze vykon jednotlivce je v prumeru mezi generacemi spis nemenny, vzacne nadani je vzacne a nektere projekty jsou proste moc velke. Muj subjektivni dojem je, ze pokud je ninja asocial a neni schopny fungovat v tymu, tak jeho pouziti ma v souctu zaporny prinos. Na to aby se vyplatilo postavit tym okolo asocialniho genia ve zvlastnim rezimu je imho zase malo tech opravdu vyjimecnych. V postate musi genialita prevysovat deficit v soft-skills (fuj, pardon) tak moc aby se to vyplatilo. Odhaduju, ze to musi byt o dost. O tom, ze je komunikace pri tymovem vyvoji celkem dulezita by se dalo asi najit neco v Robert L. Glass - Facts and Fallacies of Software Engineering.

    A jak tu zaznely uvahy ohledne srovnani celkove efektivity programovacich jazyku, tak jedine co jsem kde cetl (tusi opet Brooks) je, ze lepe vychazeji jazyky s vyssi abstrakci, coz ale neni az takove prekvapeni.
    KILLUA
    KILLUA --- ---
    1 odpověď
    Takoví lidé by hlavně namísto samostatné, nebo kolektivní práce měli mít třeba 2-3 pomocníky, kterým by buď oni sami přidělili úkoly, případně nějakého koordinátora, který by řídil jak podobného "frajera" tak ty jeho pomocníky, pokud toho není on schopen.

    No ale tady teda už teoretizuju já :)
    ALMAD
    ALMAD --- ---
    +1
    KILLUA: https://en.wikipedia.org/wiki/Daniel_J._Bernstein

    Hlavně qmail, daemontools a djbdns.
    KILLUA
    KILLUA --- ---
    1 odpověď
    Djb neznám, ani G nenapoví, co/kdo to je?
    ALMAD
    ALMAD --- ---
    //OT

    KILLUA: Moje zkušenost je, že top programátoři Vránova typu programují výrazně rychleji...samostatně. Proto taky dost často mívají vlastní toolchain kterému rozumí odshora dolů. Dost je to vidět v Ruby/node.js komunitě, TJ byla typická ukázka, dělám teď na něčem s Remym a je to to samý.

    Blbý je, že pokud se ti nepodaří bejt taková superstar (jako třeba TJ) aby se ti okolo "tvýho toolchainu" udělala komunita, tak většínou zpomaluješ skupinovou práci, protože máš "nestandardní" toolchain proti komunitě.

    Noa...změř tohle.

    Dobře to taky IMHO bylo vidět na DJB, geniální softy, jednoduchý, nadčasový...ale každej z nich je rozhodně mimo mainstream, protože udržuj si to.
    KILLUA
    KILLUA --- ---
    1 odpověď
    Almad, díky za odkaz. btw jak tam s nadsázkou dodávaj, pokud sem to dobře pochopil, schopný programátor dovede rychleji a efektivněji napsat úlohu s čistým PHP než ostatní ve frameworcích.


    No se správnou metodikou, opensource kódem se při určitém počtu "pokusů" začne projevovat statistika, že průměrně se programuje o 20% rychleji v tomhle navzdory schopnostem jednotlivých programátorů + třeba poznatek, že určité % programátorů se průměru vymyká, takže se třeba vyplatí takovému špičkovému zaplatit 2x tolik a stejně se vyplatí víc.

    Prostě dala by se získat celá řada zajímavých informací.
    REDGUY
    REDGUY --- ---
    XCHAOS: ale cílem zjevně není změřit, jak rychle někdo implementuje samoúčelný nesmysl - coze? Vsechno co ten benchmark dela je ze meri, jak rychle bezi samoucelny nesmysl. Nebo ty si myslis, ze to ma jinej cil? Nejakej, kterej to uspesne dosahuje, navzdory vsem tem problemum, ktery jsem tady ukazal?

    Pokud nějaký jazyk má pomalou stringovou += konkatenaci, tak je přinejmenším dobré to vědět - na to nepotrebuju nablbej benchmark, na to staci se ten jazyk naucit.

    Nebo chces ted tvrdit, ze vedomym cilem toho benchmarku bylo ukazat, ze += v ruby je pomaly? 8)))

    Ačkoliv to nechceš uznat, tak já jsem rozhodně proti tomu za všech okolností cokoliv předčasně optimalizovat. - strawman, jako obvykle.


    samotné změření výkonnosti různých standardních nástrojů je prostě užitečné. - jojo. Akorat ze tenhle benchmark je v podstate nemeri. Protoze to, co se snazi merit, meri blbe a i kdyz tu blbost opravis, tak porad "meri" jen jeden, velmi mrnavkouckej fragmenticek celku.
    XCHAOS
    XCHAOS --- ---
    1 odpověď
    REDGUY: tak jasně... ale cílem zjevně není změřit, jak rychle někdo implementuje samoúčelný nesmysl (to je i omyl té implementace v Javě) - ale právě porovnat implementace stringových knihoven.

    Pokud nějaký jazyk má pomalou stringovou += konkatenaci, tak je přinejmenším dobré to vědět, aby když tápeš, proč je třeba něco pomalé (například poté, co se tabulky naplní daty, apod.), tak abys tušil, co řešit.

    Ačkoliv to nechceš uznat, tak já jsem rozhodně proti tomu za všech okolností cokoliv předčasně optimalizovat... ale samotné změření výkonnosti různých standardních nástrojů je prostě užitečné.
    REDGUY
    REDGUY --- ---
    KILLUA: Pokud víš o nějakém jiném způsobu jak otestovat reálnou produktivitu určitého jazyka vs jeho rychlost, náročnost na hw tak to sděl, světové korporace ti utrhnou ruce... - ted nejak nechapu co chces rict. Co ja rikam, ze takovej obecnej "test" je nerealizovatelnej. Ani ne tak kvuli komplexnosti nebo cene (coz by samozrejme problemy byly), ale proto ze proste kazdej ma jiny pozadavky.

    Ale jestli si myslis, ze to je tak snadny, bez, navrhni to StackOverflow. Jak rikas, urcite ti utrhaj ruce 8))
    ALMAD
    ALMAD --- ---
    ALMAD: Je to teda tady OT, ale http://www.knesl.com/webexpo-2012-souboj-frameworku kdyby se někdo chtěl podivat.
    ALMAD
    ALMAD --- ---
    1 odpověď
    KILLUA: Protože to je jenom flamewar spouštěč, IMHO je fakt těžký to udělat dobře.

    Ostatně viz Kneslův souboj frameworků bo jak se to menoval, kde se pokoušel o něco podobnýho na vyšší úrovni.
    REDGUY
    REDGUY --- ---
    1 odpověď
    XCHAOS: Ty proste nezvladnes uznat, ze celej ten "benchmark" je na nic a musis si najit aspon neco, vid? No ok, muzeme pokracovat:

    Pouzitim blbeho alogirtmu je blbe i to cecko, protoze je pitomost volat realloc pred kazdym prodlouzenim. Spravne je zvetsovat po vetsich kusech a realokovat jen obcas. Protoze i kdyz realloc mozna vetsinou nekopiruje, je pitomost na to spolehat.

    Blbe je i ruby, protoze appendovat retezec na konec jineho pomoci += je hloupost. Kdyz se to fixne, razem rychlost vyskoci o 20-30%.

    A to jen pri zbeznem pohledu.... takze jo, rekl bych, zes "neco prehledl" 8)))

    (opakovaná) práce se stringy je fakt důležitou součástí toho, co se už nějaký čas programuje. - ale jo, to urcite je. Ale hledani kratkeho substringu ve stovky kilobajtu az jednotky megabajtu dlouhem stringu, navic v kritickem inner loopu _fakt_ "dulezitou soucasti" programovani neni. Jestli chces testovat vykonost prace z retezcema, testuj ji nejak rozumne: treba nejakym templatovacim enginem, parserem textu, proste necim, co testuje vic casti systemu nez jen "jak dlouho trva volani strstr" (coz je v podstate jadro tohohle "benchmarku).

    ale pořád ta absence vyšších abstrakcí nutí programátora při sestavování algoritmu "prozradit svoje záměry" víc, než u hloupějších jazyků (a teď se zase budeme hádat, co tím myslím, ach jo...) - ano, zavoraka je spravne, protoze to pred zavorkou mi prijde jako dost blabol. Resp. pokud to nedejboze myslis tak, jak se obavam, tak to znamena, ze vubec nechapes co to je abstrakce a jaka je jeji hodnota pro programatora.
    XCHAOS
    XCHAOS --- ---
    KILLUA: jsem si to ještě prolistoval, a: However IMHO this somehow proves that Java is ineffective and overcomplicated because with all the expertise and effort required to optimise Java test case, Perl code modified to use moving window substitution completed the test in less than 2 seconds - somewhat 300+ times faster than Java.

    :-))
    KILLUA
    KILLUA --- ---
    3 odpovědi
    Redguj skutečně sem ti zavdal jenom zopakováním faktu o pomalosti určitého jazyka (naschvál sem ani nejmenoval) k tomu, aby si začal s osobními útoky typu "naivní"?

    Pokud víš o nějakém jiném způsobu jak otestovat reálnou produktivitu určitého jazyka vs jeho rychlost, náročnost na hw tak to sděl, světové korporace ti utrhnou ruce... .

    Na základě takového komplexního benchmarku se pak mohou konkrétní firmy rozhodovat, nyní se rozhodují na základě dohadů, dojmů... případně ty opravdu TOP korporace jak zmiňuje Almad si udělají nějaký interní neveřejný a maj data, ne dohady.

    Jen sem se podivil, že toto nedělají v nějaké větší míře stránky/média s milionovejma návštěvnostma.
    XCHAOS
    XCHAOS --- ---
    REDGUY: fakticky "špatně" (použití vysloveně nevhodné třídy pro stringy) je tam jen ta Java (nebo jsem něco přehlédl?)

    a na tom, že na tom nezáleží, se jako na jediném neshodneme. třeba programátorům počítačových her to tak asi nepřijde, ale (opakovaná) práce se stringy je fakt důležitou součástí toho, co se už nějaký čas programuje. C je možná dnes zastaralé v tom smyslu, že se už nepřiblížíš skutečné instrukční sadě dnešních CPU a nemáš ani ponětí o jejich optimalizacích (jak si mě sám přesvědčil) - ale pořád ta absence vyšších abstrakcí nutí programátora při sestavování algoritmu "prozradit svoje záměry" víc, než u hloupějších jazyků (a teď se zase budeme hádat, co tím myslím, ach jo...)
    REDGUY
    REDGUY --- ---
    1 odpověď
    XCHAOS: každopádně ten benchmark je hlavně neaktuální. Aha. Takze to, ze je starej, je u tebe vetsi problem, nez ze je spatne? Nebno ze meri veci, na kterejch zas tak nezalezi? Ok, beru 8)))
    XCHAOS
    XCHAOS --- ---
    1 odpověď
    REDGUY: no, přečetl jsem si komentáře pod benchmarkem a opravuji to na "Java je složité monstrum" :-)

    každopádně ten benchmark je hlavně neaktuální. dal jsem si práci spustit asi 4 z původních testů (v té C verzi jsem jen opravil buffer overrun) a bez jakýchkoliv speciálních optimalizačních flagů nebo změn je u mě v roce 2016 C++ přeci jen rychlejší, než Perl:

    xchaos@hyperion:~$ ./pokus++
    exec.tm.sec str.length
    2sec 256kb
    11sec 512kb
    ^C
    xchaos@hyperion:~$ ./pokus.pl
    exec.tm.sec str.length
    4sec 256kb
    17sec 512kb
    ^C

    Takže je to akutální téma a zřejmě se někdo chytil za nos a něco ve std String zoptimalizoval, za poslední 3 roky. nicméně v C pořád:

    xchaos@hyperion:~$ ./pokus
    exec.tm.sec str.length
    0sec 256kb
    3sec 512kb
    ^C
    REDGUY
    REDGUY --- ---
    1 odpověď
    XCHAOS: o sorry, ale napsat, že benchmark může mít "zápornou hodnotu" - ale vzdyt jsi to sam nazorne demonstroval: "benchmark" byl blbne napsanej, takze vysledek byl nesmyslnej, takze XChaos vykrikoval, ze "Java je pomale monstrum" a ze "je to v ni udelane spatne". _PITOMOST_, zejmena s ohledem na to, ze kdyz se to to napise spravne, tak to najednou bezi jedenactkrat rychlejc... jo, tak tomu proste rikam "zaporna hodnota blbe udelanyho benchmarku" - jeden trouba napise spatnej benchmark a jinej trouba z toho vyvodi spatny zavery.

    týká se řetězení a modifikace stringů, takže ty tvrdíš, že v dobře napsaném kódu se to nebude vyskytovat - jezis, to je zase strawman. To co "testuje" ten benchmark je neco podstatne jineho nez obecne retezeni a modifikace stringu.

    autor benchmarku mj. pěkně ukázal na rozdíly ve spotřebě paměti. - jenomze ten jeho Java benchmark, protoze byl blbe napsanej, tak i tenhle rozdil "ukazoval" _BLBE_. Pokud _BLBEJ_ vysledek vydavas za "pekne ukazani"...no, fail, fail 8)) A pokud se ten test napise spravne, tak nejakou spotrebu pameti v C vs. v Jave fakt nejak zasadne netestuje. Cili zase fail 8))
    XCHAOS
    XCHAOS --- ---
    1 odpověď
    REDGUY: jako sorry, ale napsat, že benchmark může mít "zápornou hodnotu"... týká se řetězení a modifikace stringů, takže ty tvrdíš, že v dobře napsaném kódu se to nebude vyskytovat? já naopak už delší dobu tvrdím, že v dnešní době webových aplikací je práce se stringy nejčastější neoptimalizovaný kus kódu, který se vyskytuje mezi (optimalizovaným) browserem a (optimalizovnaou) databází. rozuměj: je to nejčastější aplikace, kterou bude psát nějaký bastlíř, který moc neví, co dělá (protože fragmenty kódu, které fakt něco dělají, jsou větišnou hotové v knihovnách a psali je lidi, co vědí, co dělají).

    rychlost není jediný parametr - autor benchmarku mj. pěkně ukázal na rozdíly ve spotřebě paměti. na webserverech se samozřejmě spouští spousta procesů, pro každý vyřizovaný dotaz... a i když server nevytuhne, tak vyprázdnění diskové cache ho zpomalí.

    ...ale jinak souhlasím, že v benchmarkovaném kódu by neměli být zjevné chyby a měl by je navíc psát někdo, kdo daný jazyk ovládá do hloubky, ale ne povrchně.
    ALMAD
    ALMAD --- ---
    ALMAD: (abych upřesnil, "masovější adaptace Golangu v Googlu". Zdroj už jsem zapomněl)
    Kliknutím sem můžete změnit nastavení reklam