• ú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
    _BENNY
    _BENNY --- ---
    XCHAOS: funkcionalni jazyky zde nejsou OT?
    XCHAOS
    XCHAOS --- ---
    [ Programovani v C#, F# a dalsich jazycich pro .NET, Mono a ostatni CLI implementace ]
    ...zajímalo by mě, jestli to F# je spíš síťová verze Forthu, nebo Fortranu :-)
    VITEX
    VITEX --- ---
    XCHAOS: Ja jsem proti. Nedělej malýho. Céčko bude vždycky potřeba.
    XCHAOS
    XCHAOS --- ---
    Dobře, tak tenhle klub teda uzavřu, s tím, že se všichni naučíme programovat v Javascriptu... je někdo proti ? :-)
    XCHAOS
    XCHAOS --- ---
    Nedá mi to.. ale zase jeden javascriptový offtopic (snad mě omlouvá, že originál byl původně v Céčku :-)

    Doom Ported To the Web - Slashdot
    http://games.slashdot.org/story/11/05/31/1833239/Doom-Ported-To-the-Web
    https://developer.mozilla.org/en-US/demos/detail/doom-on-the-web/ Legendární hra #doom od #idsoftware portována do #javascript - u mě 20 FPS

    (trik je samozřejmě v tom, že VGA rozlišení bylo jen 0.064 Mpx :-) a dnešní PC jsou snad o několik řádů rychlejší, než 386ky v 90tých letech...)
    XCHAOS
    XCHAOS --- ---
    REDGUY: spíš je to duplicitní. už jsme si to tady vyjasnili...
    REDGUY
    REDGUY --- ---
    Mala douska k tomu ze "javascript na serveru neni". Dostanu ban za offtopic?
    JavaScript conquers the server | Application Development - InfoWorld
    http://www.infoworld.com/d/application-development/javascript-conquers-the-server-969
    XCHAOS
    XCHAOS --- ---
    já s tím realloc() plánuji cosi zcela pekelného... ale nejdřív musím pochopit, jak funguje ten fine-tuning u mallocu (viz man mallopt)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Pockej, jak se chova realloc dnes je uz nejakejch 20-30 let stejny. Zvetsi ten flak pameti a vrati pointer na zacatek zvetseneho flaku, nebo NULL pokud selhal.

    Pokud chces vedet vic, tak z definice chces vedet jak se to chova vevnitr. A to uz je implementation specific a glibc se ti bude na x86 chovat jinak nez na Sparcu a jinak nez na PICech a jinak nez na MicroBlazu a jinak nez na ARMu. (Ne nezbytne jinak, ale rozhodne ne spolehlive stejne).
    XCHAOS
    XCHAOS --- ---
    REDGUY: teď popravdě ani nechápu, jestli polemizuješ se mnou nebo s někým jiným. to není můj nápad, to s tím přehazováním pořadí stránek.

    v DOSu ani žádné dělení na userspace a kernel nebylo, a jak to bylo s možnostma řazení bloků paměti v reálném módu, to si fakt nejsem jistý a ani už dnes po tom nechci pátrat

    mě každopádně zajímá zjistit, jak se to přesně chová dnes (ani ne nutně, jak je to udělané vevnitř). a nějaké indicie mám viz [ XCHAOS @ ANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API ]
    REDGUY
    REDGUY --- ---
    ANT_39: No fakt. Sice to funguje az od dostatecny velikosti, ale je to tak. Jdu snist svuj kloboucke. (Chahahaha, zadnej nemam 8) )
    ANT_39
    ANT_39 --- ---
    Mno, to se da snadno overit, ze...
    $ cat realloc.c #include <stdlib.h> int main(int argc, char *argv[]) { void *x = malloc (10000000); malloc (10000000); x = realloc (x, 20000000); return 0; } $ make realloc cc realloc.c -o realloc $ ltrace -S ./realloc [...] __libc_start_main(0x400514, 1, 0x7fff34c36568, 0x400560, 0x4005f0 <unfinished ...> malloc(10000000 <unfinished ...> SYS_mmap(0, 0x98a000, 3, 34, 0xffffffff) = 0x7f18029f6000 <... malloc resumed> ) = 0x7f18029f6010 malloc(10000000 <unfinished ...> SYS_mmap(0, 0x98a000, 3, 34, 0xffffffff) = 0x7f180206c000 <... malloc resumed> ) = 0x7f180206c010 realloc(0x7f18029f6010, 20000000 <unfinished ...> SYS_mremap(0x7f18029f6000, 0x98a000, 0x1313000, 1, 0x1313000) = 0x7f1800d59000 <... realloc resumed> ) = 0x7f1800d59010 SYS_exit_group(0 <no return ...> +++ exited (status 0) +++

    IMHO by kernel mremap mohl tim premapovanim i resit... Pochopitelne porad plati, ze to musi byt velky blok alokovany pres mapovani.
    REDGUY
    REDGUY --- ---
    XCHAOS: No, presvedceny byt muzes. Ale pokud mi ukazes konkretni implementaci libc ktera realloc obecne implementuje pres nejake sachovani s mapovanim logickych adres na fyzicke a ne tak jak jsem rikal (mam shodou okolnosti misto za tim blokem? Pokud ano, zvetsim velikost bloku, pokud ne, malloc + memcpy), budu prevelice prekvapen. Uz proto, ze ?alloc zije v libc a libc zije v userspace, kterej o nejakem strankovani a fyzicky adresach nic netusi.
    XCHAOS
    XCHAOS --- ---
    REDGUY: no pravděpodobně jí měl jak říká [ DAVIDOWITCH @ ANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API ] - skrze kopírování paměti jinam. tedy alespoň v reálném módu. zase tý kopírovaný paměti nemohlo být ani tolik :-)

    jsem přesvědčený, že programy vyvíjené pro win32 nebo pro DOS extendér DOS4GW měly už v půlce 90tých let k dispozici v podstatě stejné možnosti, jako dnes. Ale Borland C byl nižší level. určitě to měli implementované divně.
    REDGUY
    REDGUY --- ---
    XCHAOS: Btw: Borland C libc v dřevních dobách DOSu jí podle mě neměla, a z toho vyplynula moje averze k polím a preference spojových seznamů Hmm. Dokumentace rika neco jineho: http://bitsavers.org/pdf/borland/Turbo_C_Reference_Guide_1987.pdf , strana 214 a 173 (cislovani pdfka, ne knihy). Mozna kdyby sis to poradne nastudoval uz tenkrat, usetril sis dvacet let zbytecne averze 8))
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Ne, nemuzes se spolehnout na to jak to bude implementovany na konkretni architekture. Jediny na co se muzes spolehnout je, ze to bude na venek delat co pisou ze to bude delat. A ze pokud nejakej kokot napsal dementni implementaci, tak mu nejspis nekdo urval hlavu a uz davno to prepsal efektivne. Ale realloc funguje i na procesorech co proste nemaj virtualni pamet, tam se tezko neco precisluje. (A taky ma potize na 32b OS, kdyz chces velky flaky pameti a mas moc fragmentovanou pamet, a tak vubec)
    XCHAOS
    XCHAOS --- ---
    ...These functions allow glibc-specific interaction with the dynamic memory allocation routines.

    malloc_stats()

    vida. myslím, že právě kvůli podobné sw-archeologii jsem tenhle klub zakládal.
    XCHAOS
    XCHAOS --- ---
    REDGUY:
    ANT_39: přesně pochopit, co malloc() - resp. jeho typické dnešní implementace pro typické dnešní architektury dělá - by mi určitě pomohlo "nejít proti srsti". že z větších bloků ukusuje "po částech", to jsem tušil... a právě proto bych předpokládal, že když udělám realloc() z 3prvkového pole třena na 300 000, tak dojde spíš k fyzickému kopírování ?

    Normally, malloc() allocates memory from the heap, and adjusts the size of the heap as required, using sbrk(2). When allocating blocks of memory larger than MMAP_THRESHOLD bytes, the glibc malloc() implementation allocates the memory as a private anonymous mapping using mmap(2). MMAP_THRESHOLD is 128 kB by default, but is adjustable using mallopt(3).

    vida vida... RTFM... konečně se někam posouváme :-)
    REDGUY
    REDGUY --- ---
    XCHAOS: LOL. No, vzhledem k tomu ze jsi nedokazal ze sebe vysypat aspon vzdalene pouzitelnou definici jak by to melo fungovat a k cemu presne by to bylo uzitecne, je to v podstate irelevantni 8)
    ANT_39
    ANT_39 --- ---
    XCHAOS: U malych pametovych bloku asi tezko, protoze ty se nemapuji separatne. man malloc o tom ma nejake relevantni povidani.
    Kliknutím sem můžete změnit nastavení reklam