OldComp.cz

Komunitní diskuzní fórum pro fanoušky historických počítačů

Old Comp Prty VI - 11. a 13. z 2020

Právě je 07.08.2020, 12:22

Všechny časy jsou v UTC + 1 hodina [ Letní čas ]




Odeslat nové téma Odpovědět na téma  [ Příspěvků: 48 ]  Přejít na stránku Předchozí  1, 2, 3, 4  Další
Autor Zpráva
 Předmět příspěvku: Re: Clovek verzus kompiler
PříspěvekNapsal: 23.09.2018, 23:22 
Offline
Pan Generální
Uživatelský avatar

Registrován: 18.06.2013, 20:26
Příspěvky: 2678
Has thanked: 110 times
Been thanked: 391 times
berk píše:
Hezké zamyšlení nad tím, proč programy psané v assembleru jsou rychlejší a efektivnější. Autor ukazuje, že i zde platí Jevonsův paradox, který se používá v ekonomii.

https://board.asm32.info/why-assembly-p ... anced.222/

Copak o to, čte se to pěkně, jen si myslím, že v tom článku je přání otcem (závěrečné) myšlenky 8-)

_________________
"Je lepší rozsvítit byť jen malou svíčku, než jen proklínat temnotu." (Konfucius)

www.zxsparrow.com


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Clovek verzus kompiler
PříspěvekNapsal: 24.09.2018, 12:20 
Online
Pan Generální

Registrován: 22.05.2013, 21:14
Příspěvky: 2673
Bydliště: Bratislava
Has thanked: 280 times
Been thanked: 506 times
Jiiira píše:
Copak o to, čte se to pěkně, jen si myslím, že v tom článku je přání otcem (závěrečné) myšlenky 8-)
Podla mna iba precenujes kompilery vyssich jazykov ;)


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Clovek verzus kompiler
PříspěvekNapsal: 24.09.2018, 19:05 
Offline
Pan Generální
Uživatelský avatar

Registrován: 18.06.2013, 20:26
Příspěvky: 2678
Has thanked: 110 times
Been thanked: 391 times
Busy píše:
Jiiira píše:
Copak o to, čte se to pěkně, jen si myslím, že v tom článku je přání otcem (závěrečné) myšlenky 8-)
Podla mna iba precenujes kompilery vyssich jazykov ;)
O tom nemluvím - závěrečná myšlenka přece byla:

*SPOILER ALERT*
- že výkon hardware už neporoste takovým tempem, ba co hůř, poroste jen velmi pomalu, a že tudíž výrobci software začnou optimalizovat své programy
*SPOILER ALERT END*

Podobné přání jsem měl mnohokrát taky, takže si umím představit, proč to autor napsal, ale v tomto ohledu si skepticky myslím, že se spíš najde nějaký jiný způsob zvyšování výpočetního výkonu, než současné zvětšování taktovací frekvence a počtu jader (a podobně i pokud jde o operační paměť). Prostě výrobci v honbě za konkurenční výhodou zvanou "uvést produkt na trh dřív, než konkurence" půjdou radši touto cestou dokud to jde, než by se zdržovali s nějakou optimalizací - bohužel... :shrug:

_________________
"Je lepší rozsvítit byť jen malou svíčku, než jen proklínat temnotu." (Konfucius)

www.zxsparrow.com


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Clovek verzus kompiler
PříspěvekNapsal: 25.09.2018, 06:28 
Offline
Pan Štábní
Uživatelský avatar

Registrován: 06.10.2015, 17:37
Příspěvky: 1851
Bydliště: Praha východ
Has thanked: 11 times
Been thanked: 145 times
Zvyšování výkonu počítačů pomocí stále výkonnějších procesorů nemůže růst donekonečna, protože konstrukce procesorů zvyšování frekvence naráží na technologické problémy, které jsou dané fyzikálními zákony. Jednou z možností jak zvýšit výkon procesorů je zcela jiná konstrukce procesorů, například návrat k transputerům, anebo zcela jiné materiály pro jejich konstrukci. Obojí je problém, který se nevyřeší za jeden rok.
Optimalizace software je u většiny aplikací žádoucí, jenže je mnohem nákladnější, než výroba výkonnějšího, rychlejšího CPU. Uživatelé, pokud budou chtít výkonný systém dosažený optimalizovaným software, si budou muset připlatit mnohem více, než za stejně výkonný systém dosažený rychlejším CPU.
Je to jako s auty - je levnější vyrobit auto, než pro něj vytvářet a udržovat efektivní a optimalizovanou síť silnic. Chcete se rychle dostat z bodu A do bodu B? Buď si kupte rychlejší auto, anebo optimaluzujte silniční síť. Levnější je koupit si rychlejší auto, které je však brzděno nedokonalou silniční sítí. Co na tom, že auto je schopno vyvinout rychlost 240 km/h, když na většině silničních síti může jet max. třetinovou rychlostí.
Stejné to je s operačními systémy a software pro počítače. Naprostá většina software je neefektivní, španě navržená s mnoha chybami. Důvodem je cena. Uživatelé nechtějí drahý software. Uživatelé chtějí software ideálně zadarmo, stejně tak, jako majitelé aut nejsou ochotni platit za efektivní kvalitní silniční síť a raději si koupí rychlejší auto.

_________________
Hyperinzerce - historické počítače

ComputerAsylum WEB: http://www.computerasylum.co.uk
Twitter: https://twitter.com/COMPUTERASYLUM
Zprávy: https://www.euronews.com/ https://www.aljazeera.com/
Obrázek


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Clovek verzus kompiler
PříspěvekNapsal: 25.09.2018, 07:55 
Online
Pan Generální

Registrován: 22.05.2013, 21:14
Příspěvky: 2673
Bydliště: Bratislava
Has thanked: 280 times
Been thanked: 506 times
computerasylum píše:
konstrukce procesorů zvyšování frekvence naráží na technologické problémy, které jsou dané fyzikálními zákony
Presne tak. Navrhari uz davno narazili na limit maximalnej frekvencie CPU, vsimnite si ze ziadny CPU nema takt viac ako cca 5 GHz. Problem robi jeden z najzakladnejsich fyzikalnych zakonov - rychlost svetla. Na jeden takyto takt svetlo nestihne preletiet ani 6 cm, a sirenie interakcie elektronov v realnom materiali je este pomalsie. Teoreticky nie je problem vyrobit elektroniku ktora by zvladla rychlejsie taktovanie, problem je prave v tom ze pri obvodoch velkych niekolko cm elektricky signal z jednej casti obvodu uz proste nestiha prist dostatocne rychlo do inej casti obvodu.

Preto sa vyrobcovia CPU rozhodli, vzhladom na mutlitaskovost operacnych systemov, ist radsej cestou viacerych jadier, pretoze to je jeden zo sposobov ako znasobit vykon CPU bez nutnosti vymyslat nejake sialene technologie ktore by riesili fyzikalny limit rychlosti svetla.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Clovek verzus kompiler
PříspěvekNapsal: 06.04.2019, 15:21 
Offline
Profík
Uživatelský avatar

Registrován: 09.10.2013, 19:04
Příspěvky: 858
Has thanked: 96 times
Been thanked: 33 times
Busy píše:
Az vam bude niekto tvrdit, ze dnesne moderne sofistikovane kompilery generuju VELMI efektivny kod, a ze clovek TAZKO napise lepsi, tak mu mozete oplieskat o hlavu tento ukazkovy priklad :)

Jedna sa o obycajnu jednoduchu trivialnu obsluhu sprav okna. Povodny zdrojovy text vyzera takto:
Kód:
LRESULT CALLBACK MyWindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
  if (uMsg != WM_DESTROY) return DefWindowProc(hwnd, uMsg, wParam, lParam);

  PostQuitMessage(0);
  return 0;
}
Ak prisla sprava WM_DESTROY tak sa zavola PostQuitMessage, vo vsetkych ostatnych pripadoch sa vola DefWindowProc. Velmi jednoduche.

Moderne kompilery dokazu vyplut takyto, celkom efektivny kod:
Kód:
55                   MyWindowProc push    ebp
89 E5                             mov     ebp, esp
8B 45 0C                          mov     eax, [ebp+Msg]
83 F8 02                          cmp     eax, WM_DESTROY
74 36                             jz      destroy
FF 75 14                          push    [ebp+lParam]    ; lParam
FF 75 10                          push    [ebp+wParam]    ; wParam
FF 75 0C                          push    [ebp+Msg]       ; Msg
FF 75 08                          push    [ebp+hWnd]      ; hWnd
FF 15 50 B1 44 00                 call    [DefWindowProcA]
EB 54                             jmp     end


6A 00                destroy      push    0               ; nExitCode
FF 15 74 B1 44 00                 call    [PostQuitMessage]
31 C0                             xor     eax, eax
C9                   end          leave
C2 10 00                          retn    10h
Standartny zaciatok procedurky pre adresaciu parametrov, podmienka, napushovanie parametrov pre DefWindowProc, zavolanie DefWindowProc a potom uz len skok na navrat s vycistenim zasobnika. A plus vetva pre pripad WM_DESTROY. Tam uz niet co optimalizovat (obvykly nazor zastancov modernych kompilerov).

A teraz ukazka, ze KAZDY program sa da skratit, ak sa do toho vlozi clovek. Tento kod robi presne to iste:
Kód:
8B 44 24 08         WindowProc  mov     eax,[esp+0x08]   ; eax = parameter Msg
83 E8 02                        sub     eax,WM_DESTROY
74 1D                           jz      destroy
FF 25 34 31 40 00               jmp     [DefWindowProcA]

50                  destroy     push    eax              ; nExitCode (eax = 0)
FF 15 74 B1 44 00               call    [PostQuitMessage]
31 C0                           xor     eax, eax
C2 10 00                        retn    10h
Kedze DefWindowProc ma tie iste parametre ako MyWindowProc, mozeme pre volanie DefWindowProc priamo vyuzit blok parametrov pripravenych na zasobniku pre MyWindowProc. A kedze po vykonani DefWindowProc sa prakticky hned vraciame sa na miesto odkial bolo volane nase MyWindowProc, mozeme spolu s parametrami zneuzit aj na zasobniku ulozenu navratovu adresu. Ak si teda zasobnik nezabordelujeme EBP-ckom, uplne postaci normalne JUMPom skocit na DefWindowProc. A usetrili sme 18 bajtov :)

Dalsi bajt sme usetrili tym ze sme povodne CMP nahradili SUB-om. V pripade WM_DESTROY bude register EAX nulovy a namiesto pushovania konstanty 0 mozeme na zasobnik pushnut priamo nas EAX.

A nakoniec aj vykonavanie programu bude rychlejsie, pretoze navrat z DefWindowProcskoci priamo na povodne miesto odkial bolo volane nase MyWindowProc, namiesto toho aby skocil nazad do MyWindowProc a vzapeti z MyWindowProc na toto povodne miesto.

A na zaver jedna uloha. Kedze plati, ze KAZDY program sa da skratit, da sa samozrejme skratit aj tato kratsia verzia MyWindowProc. Kto si trufne ?

Pozrel by som sa na to tak, že kompilátor z toho spravil to, čo si chcel, ale ty si spravil niečo ako "inline" verziu. Lenže to už nie je presne to, čo bolo v zdrojáku.

Kompilátor je len jedinec s IQ 60, čo robí to, čo ho naučili, resp. ako ho naprogramovali. Neurobí o nič menej ani viac. Ak budeš mať kompilátor s umelou inteligenciou, ktorý sa bude učiť od človeka, určite dá ešte lepší kód a možno ti ešte navrhne inline direktívu pre vyššie uvedenú procedúru. Je samozrejmé, že zbytočné zásobníkovanie pri krátkych funkciách spomaľuje a inline by tu bolo oveľa vhodnejšie.

V jednom PC Worlde (alebo to bol iný časopis) bol článok o tom, že jazyk C bol vytvorený ako 1. aprílový žart, pretože kompiluje extrémne veľa riadkov. Len samotný "hello world" si vyžaduje niekoľko 1000 riadkov. Dlho som tomu článku veril, až mi známy po rokoch povedal, že ten článok bol v aprílovom čísle a bol aj v tom zmysle písaný, hoci nikde nebolo uvedené, že ide o žart.

Java nepodporuje bezznamienkové celé čísla, takže ak potrebuješ čísla z vyššieho rozsahu, musíš siahnuť po inom číselnom type, znamená to, že je zlá a neefektívna? Takto by sa dali chyby nájsť na každom prekladači.

Chcem teda povedať len toľko, že mnoho rôznych prípadov (jeden z nich uvádzaš ty) môže vytvoriť neefektívny kód, ale na druhú stranu, zahrnutie týchto drobností do prekladača tak, aby robil optimálnejší kód môže znamenať jeho zväčšenie a tým aj spomalenie niekoľkonásobne.

_________________
Sharp MZ-821
Milsa MZ-841


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Clovek verzus kompiler
PříspěvekNapsal: 06.04.2019, 19:26 
Offline
Pan Generální
Uživatelský avatar

Registrován: 23.03.2014, 20:13
Příspěvky: 2046
Has thanked: 103 times
Been thanked: 391 times
Milsa píše:
že jazyk C bol vytvorený ako 1. aprílový žart,

To bylo C++: http://programujte.com/clanek/2006030305-rozhovor-s-bjarne-stroustrupem/

Naopak, C stvořili dva kryptomaniaci a vystačí s úplným minimem :lol:

Kód:
#include                                     <math.h>
#include                                   <sys/time.h>
#include                                   <X11/Xlib.h>
#include                                  <X11/keysym.h>
                                          double L ,o ,P
                                         ,_=dt,T,Z,D=1,d,
                                         s[999],E,h= 8,I,
                                         J,K,w[999],M,m,O
                                        ,n[999],j=33e-3,i=
                                        1E3,r,t, u,v ,W,S=
                                        74.5,l=221,X=7.26,
                                        a,B,A=32.2,c, F,H;
                                        int N,q, C, y,p,U;
                                       Window z; char f[52]
                                    ; GC k; main(){ Display*e=
 XOpenDisplay( 0); z=RootWindow(e,0); for (XSetForeground(e,k=XCreateGC (e,z,0,0),BlackPixel(e,0))
; scanf("%lf%lf%lf",y +n,w+y, y+s)+1; y ++); XSelectInput(e,z= XCreateSimpleWindow(e,z,0,0,400,400,
0,0,WhitePixel(e,0) ),KeyPressMask); for(XMapWindow(e,z); ; T=sin(O)){ struct timeval G={ 0,dt*1e6}
; K= cos(j); N=1e4; M+= H*_; Z=D*K; F+=_*P; r=E*K; W=cos( O); m=K*W; H=K*T; O+=D*_*F/ K+d/K*E*_; B=
sin(j); a=B*T*D-E*W; XClearWindow(e,z); t=T*E+ D*B*W; j+=d*_*D-_*F*E; P=W*E*B-T*D; for (o+=(I=D*W+E
*T*B,E*d/K *B+v+B/K*F*D)*_; p<y; ){ T=p[s]+i; E=c-p[w]; D=n[p]-L; K=D*m-B*T-H*E; if(p [n]+w[ p]+p[s
]== 0|K <fabs(W=T*r-I*E +D*P) |fabs(D=t *D+Z *T-a *E)> K)N=1e4; else{ q=W/K *4E2+2e2; C= 2E2+4e2/ K
 *D; N-1E4&& XDrawLine(e ,z,k,N ,U,q,C); N=q; U=C; } ++p; } L+=_* (X*t +P*M+m*l); T=X*X+ l*l+M *M;
  XDrawString(e,z,k ,20,380,f,17); D=v/l*15; i+=(B *l-M*r -X*Z)*_; for(; XPending(e); u *=CS!=N){
                                   XEvent z; XNextEvent(e ,&z);
                                       ++*((N=XLookupKeysym
                                         (&z.xkey,0))-IT?
                                         N-LT? UP-N?& E:&
                                         J:& u: &h); --*(
                                         DN -N? N-DT ?N==
                                         RT?&u: & W:&h:&J
                                          ); } m=15*F/l;
                                          c+=(I=M/ l,l*H
                                          +I*M+a*X)*_; H
                                          =A*r+v*X-F*l+(
                                          E=.1+X*4.9/l,t
                                          =T*m/32-I*T/24
                                           )/S; K=F*M+(
                                           h* 1e4/l-(T+
                                           E*5*T*E)/3e2
                                           )/S-X*d-B*A;
                                           a=2.63 /l*d;
                                           X+=( d*l-T/S
                                            *(.19*E +a
                                            *.64+J/1e3
                                            )-M* v +A*
                                            Z)*_; l +=
                                            K *_; W=d;
                                            sprintf(f,
                                            "%5d  %3d"
                                            "%7d",p =l
                                           /1.7,(C=9E3+
                              O*57.3)%0550,(int)i); d+=T*(.45-14/l*
                             X-a*130-J* .14)*_/125e2+F*_*v; P=(T*(47
                             *I-m* 52+E*94 *D-t*.38+u*.21*E) /1e2+W*
                             179*v)/2312; select(p=0,0,0,0,&G); v-=(
                              W*F-T*(.63*m-I*.086+m*E*19-D*25-.11*u
                               )/107e2)*_; D=cos(o); E=sin(o); } }

To je zdroják leteckého simulátoru, pokud by to někdo na nějakém prastarém Unixu nebo Linuxu chtěl zkusit zkompilovat, tak
Kód:
cc banks.c -o banks -DIT=XK_Page_Up -DDT=XK_Page_Down \
        -DUP=XK_Up -DDN=XK_Down -DLT=XK_Left -DRT=XK_Right \
        -DCS=XK_Return -Ddt=0.02 -lm -lX11 -L/usr/X11R6/lib

_________________
V uplynulých pěti týdnech zaregistrovala evropská železniční agentura Erail 15 kritických událostí na železnici – 10 z toho v České republice!


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Clovek verzus kompiler
PříspěvekNapsal: 28.02.2020, 09:49 
Online
Pan Generální

Registrován: 22.05.2013, 21:14
Příspěvky: 2673
Bydliště: Bratislava
Has thanked: 280 times
Been thanked: 506 times
Nedavno som riesil taku (v podstate) jednoduchu ulohu - mam zadanu mnozinu CRC32 hashov ktore boli vytvorene z nejakych jednoduchych a kratkych textovych retazcov a mojou ulohou je zistit, akym retazcom zodpovedaju. Algoritmus bol jasny - brute force generovat vsetky mozne retazce (aaa,aab,aac...zzz,aaaa,aaab...), a pre kazdy skontrolovat ci jeho CRC32 nesedi s niektorym z mnoziny zadanych.

Tak som si povedal, ze toto je vhodna uloha na prakticke overenie kto dokaze napisat rychlejsi kod - clovek alebo kompiler. Tak som si napisal dva programy - ten isty algoritmus v asembleri a v cecku. A nasledne vyskusal porovnat rychlost programu v asembleri s rychlostou kodu vygenerovaneho niektorymi ceckovymi kompilermi, s roznymi stupnami optimalizacie generovaneho kodu.

Testovaci procesor: Intel Core i7-4770 / 3.4GHz
Program vzdy bezal iba na jednom jadre.

Kód:
Rychl.  Kompiler        Optimalizacia
=====   =============   ==============
 1540   Assembler       (samozrejme rucne)

  750   MS VS 2015      /O2 maximize speed
  746   MS VS 2015      /Ox full optimalization
  735   MS VS 2015      /O1 minimize size
  322   MS VS 2015      /Od disabled

  847   MinGW 8.2.0     -O3
  831   MinGW 8.2.0     -O2
  816   MinGW 8.2.0     -O1
  324   MinGW 8.2.0     none

  783   MinGW 4.4.0     -march=native -O3
  300   MinGW 4.4.0     none
  267   MinGW 4.4.0     -O3
  265   MinGW 4.4.0     -O2
  251   MinGW 4.4.0     -O1

Prvy stlpec tabulky (rychlost) znamena kolko milionov retazcov sa takto stihlo vygenerovat a otestovat za jednu sekundu.

Treba uznat (klobuk dole!), ze moderne kompilery dokazu generovat skutocne rychly kod, ale na poctivo manualne napisany a zoptimalizovany asembler sa proste nechytaju.

Takze ak by vam stale niekto chcel tvrdit, ze moderne kompilery dokazu vygenerovat rychlejsi kod ako by dokazal napisat clovek, tak mu kludne mozete oplieskat o hlavu tuto tabulku :)


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Clovek verzus kompiler
PříspěvekNapsal: 28.02.2020, 10:34 
Offline
Radil

Registrován: 06.02.2019, 11:47
Příspěvky: 433
Has thanked: 8 times
Been thanked: 76 times
Busy píše:
Nedavno som riesil taku (v podstate) jednoduchu ulohu - mam zadanu mnozinu CRC32 hashov ktore boli vytvorene z nejakych jednoduchych a kratkych textovych retazcov a mojou ulohou je zistit, akym retazcom zodpovedaju.

Ďalší krok je dešifrovanie Threemy?


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Clovek verzus kompiler
PříspěvekNapsal: 28.02.2020, 10:46 
Offline
Pan Generální
Uživatelský avatar

Registrován: 23.03.2014, 20:13
Příspěvky: 2046
Has thanked: 103 times
Been thanked: 391 times
OROROK OREBUH :lol:

_________________
V uplynulých pěti týdnech zaregistrovala evropská železniční agentura Erail 15 kritických událostí na železnici – 10 z toho v České republice!


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Clovek verzus kompiler
PříspěvekNapsal: 28.02.2020, 11:10 
Offline
Profík
Uživatelský avatar

Registrován: 24.05.2018, 22:32
Příspěvky: 853
Bydliště: Most, Praha
Has thanked: 255 times
Been thanked: 227 times
Busy píše:
...Takze ak by vam stale niekto chcel tvrdit, ze moderne kompilery dokazu vygenerovat rychlejsi kod ako by dokazal napisat clovek, tak mu kludne mozete oplieskat o hlavu tuto tabulku :)
Bohužel dokážou. :-( Podle toho jak co. Člověk může využít finty a instrukce, které kompilátor neumí využít. Ale člověk selhává u příliš komplikovaných funkcí, kde si už nedokáže udržet přehled o toku dat. Člověk v tom případě si obvykle popíše obsah registrů a lokálních proměnných v zásobníku a těchto významů se striktně drží, protože jinak by se v tom ztratil. Naproti tomu kompilátor dokáže obsahy registrů dost dobře optimalizovat, zkrátit toky dat na minimum, registry sdílet a přehazovat a i dobře zoptimalizovat pipelining. Kompilátor se dokáže orientovat i ve zcela nepřehledném, ale zoptimalizovaném, kódu.

Když chci něco zoptimalizovat do assembleru, tak je dobře to nejdříve přeložit do C a ten překlad použít jako vzor. Jsou místa která člověk jasně napíše líp, ale často nacházím v překladu optimalizační fígle, které mě nenapadly (např. místo dělení použít násobení). A někdy se stane, že svůj kód stále tak optimalizuji a vylepšuji, až se nakonec dostanu až k přesné shodě s překladem, protože zjistím že byl optimálnější. Ale jo, při velké snaze se člověk může dostat na znatelné zrychlení, jen teda se ten kód pak stává už neupravitelný. Udělat tam změnu znamená všechno znefunkčnit a týden to zas procházet. Na to je compiler mnohem pružnější.

Když jsem kdysi řešil hlavolam Eternity 2, tak jsem si říkal že pohoda, napíšu to v assembleru a řešení bude rychlé. Algoritmy jsem napsal nejdříve v C a pak převedl do assembleru - jenže se to zrychlilo vždy maximálně tak o 10%, takže místo 1000 let by to brutal force řešil 900 let ... asi by mi i tak za tu dobu to kafe vystydlo.

_________________
i++ (INC) increment
i-- (DEC) decrement
i@@ (EXC) excrement


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Clovek verzus kompiler
PříspěvekNapsal: 28.02.2020, 11:28 
Offline
Pan Štábní
Uživatelský avatar

Registrován: 07.07.2019, 22:14
Příspěvky: 1173
Has thanked: 53 times
Been thanked: 90 times
No ale zase rozběhnout to na 1000 jádrech paralelně tak by to bylo 0,9 roku a to už je docela dobré. Určitě by pronájem takové farmy na 10,5 měsíců nevyšel na miliony. A taky bych věřil spíš tomu že člověk dokáže optimalizovat jednotlivé kroky ale nějaký hodně komplexní program prakticky nemá šanci obsáhnout, leda by to byl nějaký übergénius co se rodí jednou za 100 let ve stylu von Neumanna co si bezchybně pamatoval stovky knih slovo od slova po jednom přečtení a ještě na smrtelné posteli bavil svého bratra recitací z nich.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Clovek verzus kompiler
PříspěvekNapsal: 28.02.2020, 19:06 
Online
Pan Generální

Registrován: 22.05.2013, 21:14
Příspěvky: 2673
Bydliště: Bratislava
Has thanked: 280 times
Been thanked: 506 times
Panda38 píše:
Busy píše:
...Takze ak by vam stale niekto chcel tvrdit, ze moderne kompilery dokazu vygenerovat rychlejsi kod ako by dokazal napisat clovek, tak mu kludne mozete oplieskat o hlavu tuto tabulku :)
Bohužel dokážou. :-( Podle toho jak co. Člověk může využít finty a instrukce, které kompilátor neumí využít. Ale člověk selhává u příliš komplikovaných funkcí, kde si už nedokáže udržet přehled o toku dat. Člověk v tom případě si obvykle popíše obsah registrů a lokálních proměnných v zásobníku a těchto významů se striktně drží, protože jinak by se v tom ztratil.
Tak v tomto pripade je jasne, ze voci cloveku, ktory programuje takymto sposobom, tie kompilery vygeneruju lepsi kod. O tom samozrejme vobec nie je ziadnych pochyb a to ani nijak nerozporujem.
Panda38 píše:
Naproti tomu kompilátor dokáže obsahy registrů dost dobře optimalizovat, zkrátit toky dat na minimum, registry sdílet a přehazovat a i dobře zoptimalizovat pipelining.
Ale toto vsetko dokaze aj clovek, znaly danej platformy. A ked sa k tomu prida co spomenul vyssie (finty a instrukce, které kompilátor neumí využít) tak kompiler proste nema sancu :)
Panda38 píše:
Kompilátor se dokáže orientovat i ve zcela nepřehledném, ale zoptimalizovaném, kódu.
Tak s tymto som ja problem nikdy nemal. V kode, ktory som si sam napisal, som sa vzdy dokazal bez problemov orientovat. Je pravda, ze pokial som nieco komplikovanejsie videl prvy krat po 30 rokoch, tak mi chvilku trvalo kym som sa zorientoval, ale potom som sa uz orientoval bez problemov.
Panda38 píše:
Když jsem kdysi řešil hlavolam Eternity 2, tak jsem si říkal že pohoda, napíšu to v assembleru a řešení bude rychlé. Algoritmy jsem napsal nejdříve v C a pak převedl do assembleru - jenže se to zrychlilo vždy maximálně tak o 10%, takže místo 1000 let by to brutal force řešil 900 let ... asi by mi i tak za tu dobu to kafe vystydlo.
No, podla mojho konkretneho testu by to dobry kod v asembleri zmakol za cca 500 rokov, to by ti ani to kafe nestihlo vychladnut :) :D
Ale samozrejme kazdy algoritmus ma ine moznosti optimalizacie, takze v pripade toho Eternity to kludne mohlo byt aj tych 900 rokov. Ale s nejakou novou fintou (ktora ta proste nenapadla) by sa to kludne mohlo stihnut aj za (povedzme) 200 rokov :)


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Clovek verzus kompiler
PříspěvekNapsal: 03.03.2020, 09:04 
Offline
Pan Generální
Uživatelský avatar

Registrován: 18.06.2013, 20:26
Příspěvky: 2678
Has thanked: 110 times
Been thanked: 391 times
Člověk dokáže... kompilátor dokáže... Není náhodou kompilátor vytvořený rovněž člověkem? :poke: :P

_________________
"Je lepší rozsvítit byť jen malou svíčku, než jen proklínat temnotu." (Konfucius)

www.zxsparrow.com


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Clovek verzus kompiler
PříspěvekNapsal: 03.03.2020, 09:47 
Offline
Radil

Registrován: 14.10.2013, 23:12
Příspěvky: 369
Has thanked: 233 times
Been thanked: 18 times
Busy píše:
Panda38 píše:
Naproti tomu kompilátor dokáže obsahy registrů dost dobře optimalizovat, zkrátit toky dat na minimum, registry sdílet a přehazovat a i dobře zoptimalizovat pipelining.
Ale toto vsetko dokaze aj clovek, znaly danej platformy. A ked sa k tomu prida co spomenul vyssie (finty a instrukce, které kompilátor neumí využít) tak kompiler proste nema sancu :)


no, prilis softu v asm, ktery by skutecne zohlednoval pipelining, jsem teda nepotkal. bez specialniho editoru je ten kod prakticky necitelny...


Nahoru
 Profil  
 
Zobrazit příspěvky za předchozí:  Seřadit podle  
Odeslat nové téma Odpovědět na téma  [ Příspěvků: 48 ]  Přejít na stránku Předchozí  1, 2, 3, 4  Další

Všechny časy jsou v UTC + 1 hodina [ Letní čas ]


Kdo je online

Uživatelé procházející toto fórum: Žádní registrovaní uživatelé a 2 návštevníků


Nemůžete zakládat nová témata v tomto fóru
Nemůžete odpovídat v tomto fóru
Nemůžete upravovat své příspěvky v tomto fóru
Nemůžete mazat své příspěvky v tomto fóru
Nemůžete přikládat soubory v tomto fóru

Hledat:
Přejít na:  
Založeno na phpBB® Forum Software © phpBB Group
Český překlad – phpBB.cz