" Fortran a Python a také v jazyce Perl"Tohle mě pořád poměrně překvapuje. Fortranu rozumím (byl na takové výpočty přímo navržený) ale ten Python a Perl? U algoritmu, který má být echt robustní, ultra rychlý/efektivní a fungovat dalších 20+ let bych finální verzi čekal když už ne přímo ve strojovém kódu/assembleru tak v něčem opravdu nízkoúovňovém kde v jazyce ovlivníte každý byte paměti a každou instrukci (C, C++ a podobné).Jako rozumím že jde o přehlednost/jednoduchost při vývoji, ale finální verze?Assembler je assembler (a žádný "optimalizátor" překladače se poctivé ruční práci nevyrovná 😃 - na druhou stranou zjevně bude výhodnějšá rychlost/přehlednost při vývoji i za cenu pár obětovaných procent výkonu a dožene se to hrubou silou na superpočítačích). Jenom si říkám kdo teda když už ne ani NASA. která má s optimalizacemi a s "šetřením každé instrukce" v misích desítky let dozadu praxi? (např. "user friendly" počítač na misích Apollo - naprostý technický klenot a bomba). Dnes se už v Assembleru nepíšou ani drivery pro mikročipy :( (nostalgický povzdech) 😃
Názor byl 7× upraven, naposled 9. 12. 2021 14:26
Python, ac je pro opice, je celkem pouzitelny i pro vypocty. Zkuste se podivat na matematicke knihovny dostupne pro python a uvidite... Pro AI se treba Python primo nabizi (tensorflow)...FP precision ujde: https://docs.python.org/3/tutorial/floatingpoint.... ...
Zrovna tensorflow je hlavně v C++, pro Python to je jen napojení. Stejně tak numpy je v C.
Tohle fakt nemá cenu psát dneska v assembleru - myslím, že takhle komplexní programy se v něm nepsaly nikdy.Z čeho přesně plyne vaše přesvědčení, že dokážete optimalizovat kvalitněji, než programy, které mají diametrálně větší výpočetní výkon a napsalo je mnoho chytrých lidí?Ale jinak Pythonu se tu taky divím. Trošku bych myslel, že v něm budou jen nějaké méně náročné části a samotná simulace příběhe v Fortranu, protože jinak by to fakt muselo být zoufale pomalé
"myslím, že takhle komplexní programy se v něm nepsaly nikdy."JJ, máte pravdu, nemyslel jsem úplně celé, ale minimálně ty nejexponovanější a kritické (z hlediska rychlosti) části, zbytek v C, C++ --- a zrovna tyhle dva přístupy (Assembler + C) jdou krásně dohromady."Z čeho přesně plyne vaše přesvědčení, že dokážete optimalizovat kvalitněji, než programy, které mají diametrálně větší výpočetní výkon a napsalo je mnoho chytrých lidí?"Nejde o to, že bych přeložený kód optimalizoval lépe než dnešní překladače (to zcela určitě ne :), ale jde o ten samotný překlad. Prostě přeložený kód např. 'x=255' v jakémkoliv jazyce z principu bude obsahovat mnohem více instrukcí než (např) 'mov ax, 0xff' a 'push ax' a následné 'pop ax' ... o cyklech/podmínkách a dalším nemluvě --- Dřív, vždycky když někdo chtěl ukázat efektivitu assembleru/strojového kódu tak jsem mu řekl, ať ve svém překladači vytvoří prázdný program který nic nedělá, jen se ukončí. Výsledný .EXE (nebo jiný binární soubor dle platformy) měl od několika Kb až po několik stovek Kb, a já následně napsal jednobytový .COM s instrukcí #c9 (ret --- return) 😃 😃 😃 (ano, není to fér, .COM který z překladače např C# nedostanente vs .EXE :) ... nicméně pokud byl ten dotyčný alespoň trochu mazaný, následně mi odpověděl, že to je hezké a teď ať zase já napíšu v Assembleru program který spočítá např. odmocninu z čísla a kdo to bude mít rychleji a byl jsem namydlený já 😃 😃 😃 ... tohle bude to jádro pudla, prostě výsledné úsilí zabije případné benefity rychlosti.Spíš mi šlo o to např. C vs Python, ten mi - stejně jako Vám - tak nějak nesedí k "bleeding edge hi tech" řešení
Názor byl 5× upraven, naposled 10. 12. 2021 12:37
Potvrďte prosím přezdívku, kterou jsme náhodně vygenerovali, nebo si zvolte jinou. Zajistí, že váš profil bude unikátní.
Tato přezdívka je už obsazená, zvolte prosím jinou.