• ú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í
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: tak si to překompuluj.

    REDGUY: toto je přesně už moc low-level, na mě :-) mě stačí, že s různými -O přepínači se to chová jinak. souhlasím s tím, že je to překvapivé chování. programovat v C už dávno nestačí, aby člověk chápal, "co se děje pod kapotou" (což opravdu víceméně stačilo ještě např. v éře 16bit CPU bez onchip cache...)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    REDGUY
    REDGUY --- ---
    XCHAOS: Ehm. Na "dodani assembleru" je vsechno co potrebujes volba -S .
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: ASM je na mě moc lowlevel, fakt sorry... někdo to třeba dodá a dostane od mě velký moderátorský palec nahoru.

    gcc(1): GNU project C/C++ compiler - Linux man page
    http://linux.die.net/man/1/gcc
    hledej
    "Options That Control Optimization"

    -O2 Optimize even more.

    zajímavé.. při optimalizaci na velikost výsledného kódu (tedy zablokování většiny těch inline-loop apod. optimalizací...) to dělá furt to samé:

    xchaos@tartarus:~$ gcc -Os test.c -otest
    xchaos@tartarus:~$ ./test WTF
    Sum: 403504454559365000
    Time: 0.471624
    xchaos@tartarus:~$ ./test
    Sum: 403504454559365000
    Time: 2.23573
    REDGUY
    REDGUY --- ---
    DAVIDOWITCH: Kdyz se podivas na ten stackoverflow, tak je tam super odpoved, kde ten clovek mj. pise ze Intel Compiler 11 dokaze dokonce prohodit ty dve smycky 8)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Muzes to nejak rozvest?
    Pripadne po mne hodit ASM vypisem, protoze si nemyslim ze by compiler mel bejt schopnej nahradit ten skok maskovanim, coz je asi jediny jak stahne ty 2 casy tak blizko k sobe (pokud si teda nezkousel tu moji modifikaci)
    XCHAOS
    XCHAOS --- ---
    REDGUY: jako ano, už jsem asi objevil, že jsem ve slepé uličce, s touto úvahou :-)

    myslel jsem, že třeba sečtení 33+33 by trvalo stejně jako sečtení 33+0 nebo 0+33. ale sečtení 8+8 by bylo rychlejší :-) (tedy někde by byl nějaký pomocný bitcounter, kolik z aktuálních bitů na sběrnici je "dirty" a musí se s nimi počítat v následující instrukci

    ale nemám to ničím podložené, tohle je na mě moc lowlevel :-) je to jen moje divoká spekulace "jak bych vymýšlel CPU"...
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: to už mi taky došlo


    DAVIDOWITCH: jiný -O switch compileru
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    REDGUY:
    http://en.wikipedia.org/wiki/Carry-lookahead_adder (je logN misto N)
    http://en.wikipedia.org/wiki/Carry_bypass_adder
    Carry-select adder - Wikipedia, the free encyclopedia
    http://en.wikipedia.org/wiki/Carry-select_adder

    Ale priznam, musel sem zkonzultovat spoluzaka, protoze uz to je 5 let co sem se to ucil, 4 roky od posledniho pouziti.
    REDGUY
    REDGUY --- ---
    DAVIDOWITCH: Neznam terminus technicus, ale takovou tu uplne obycejnou. I kdyz nepochybuju ze zaimavy budou i ty chytrejsi 8)
    Zkusim najit kde jsem o tom cetl...
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    REDGUY: Myslis Carry-lookahead, nebo nejakou z tech chytrejsich, nebo obecne proste tyhle bordely?
    REDGUY
    REDGUY --- ---
    REDGUY: A btw, navrh hw scitacek co pracujou v konstatnim case, aniz bys musel nejak postupne v nekolika krocich propagovat carry zleva doprava je docela zajimavej a elegantni. Doporucuju si o tom neco najit,
    REDGUY
    REDGUY --- ---
    XCHAOS: sčítání čísel obsahujíích různý počet nastavených bitů prostě trvá různě dlouho - ale kdeze. Delka scitani integeru je konstantni, na poslednich intelech trva tusim dokonce efektivne 0.5 taktu. Navic ty cisla co scitas jsou stejna, jen v jinem poradi. A konecne tuhle teorii lze snadno vyvratit tak, ze si to vyzkousis scitanim jinejch cisel.

    nebo trváte na compile-time optimalizacích - netrvame, protoze compile-time optimalizace s tim nemaji nic spolecneho (*) a nikdo tady nic takoveho nerikal. Naopak, tohle je nasledkem v podstate run-time optimalizace, ktera probiha primo v procesoru. Podrobne vysvetleni i s obrazkama: http://stackoverflow.com/questions/11227809/why-is-processing-a-sorted-array-faster-than-an-unsorted-array

    (*) tedy, c-t-o s tim maji spolecneho to, ze maji vliv na to jak vyrazny je ten efekt a pokud mas fakt hodne chytrej prekladac, dokazou ho eliminovat. Ale na ten rozdil v casech vliv nemaji.
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Cim se lisej tyhle dva behy?
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: scitani cisel obsahujicich ruzny pocet bitu trva uplne stejne, jeden takt.
    XCHAOS
    XCHAOS --- ---
    xchaos@tartarus:~$ ./test WTF
    Sum: 403504454559365000
    Time: 0.444335
    xchaos@tartarus:~$ ./test
    Sum: 403504454559365000
    Time: 2.32974

    ....a tohle je nejlepší:

    xchaos@tartarus:~$ ./test WTF
    Sum: 403504454559365000
    Time: 0.658788
    xchaos@tartarus:~$ ./test
    Sum: 403504454559365000
    Time: 0.687157

    ok, přiznávám se - dostali jste mě :-)

    (jen podotýkám, že můj mini-toolkit zahnrnuje i dávkový soubor "bake", který se má používat místo "make" a Makefile - a že budu používat při volání gcc ty optimalizace, který mě nejlíp dopadnou s mými typy zasmyčkování, která chystám... ale to je offtopic, tohle byl hezký vtípek, uznávám ...)
    XCHAOS
    XCHAOS --- ---
    xchaos@tartarus:~$ gcc -O1 test.c -otest
    xchaos@tartarus:~$ ./test WTF
    Sum: 403504454559365000
    Time: 0.43624
    xchaos@tartarus:~$ ./test
    Sum: 403504454559365000
    Time: 2.3264
    XCHAOS
    XCHAOS --- ---
    huh


    xchaos@tartarus:~$ gcc -O0 test.c -otest
    xchaos@tartarus:~$ ./test
    Sum: 403504454559365000
    Time: 3.60948
    xchaos@tartarus:~$ ./test
    Sum: 403504454559365000
    Time: 4.5604
    xchaos@tartarus:~$
    XCHAOS
    XCHAOS --- ---
    dobře... tohle už vypadá jako signál mimozemské civilizace "WTF" (zachycen po velkém úspěchu předchozího signálu "WOW")

    xchaos@tartarus:~$ ./test WTF
    Sum: 403504454559365000
    Time: 1.53202
    xchaos@tartarus:~$ ./test
    Sum: 403504454559365000
    Time: 3.59716

    můj návrh interpretace: sčítání čísel obsahujíích různý počet nastavených bitů prostě trvá různě dlouho - prostě CPU nějak ví, kolik je max. platných bitů v registru a pak i mikrokód sčítačící různý počet bitů trvá různě dlouho, to je celé.... prostě se mi to jeví, že asm instrukce ADD už není "atomická" (či jak to nazvat) - prostě už na soudobých architekturách netrvá vždy stejný počet taktů CPU (resp. možná trvá na úrovni jednoho vlákna, ale ten čas se může využívat např. pro NEVÍM způsobem NEVÍM JAK)

    je možné, že je to tímhle? (testováno zatím jen na 64bit platformě), nebo trváte na compile-time optimalizacích?
    XCHAOS
    XCHAOS --- ---
    REDGUY: ok :-)
    REDGUY
    REDGUY --- ---
    XCHAOS: Aaaaaaaaaaaargh. To proste neni mozny. Ty proste nejsi skutecnej. Ty jsi ve skutecnosti sdruzeni nekolika spickovejch komiku s extremne bizanim smyslem pro humor.

    Co jsem napsal v puvodni zprave?
    - "pokud mu na prikazove radce reknete "WTF"
    Co se pise v kodu?
    - "if (argc == 2 && !strcmp(argv[1], "WTF")) {"

    Co potom napsal xchaos?

    - "xchaos@tartarus:~$ ./test wtf"

    Najdi tri rozdily...

    Jak si z tebe potom nemam delat srandu?
    Kliknutím sem můžete změnit nastavení reklam