OldComp.cz

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


Právě je 28.03.2024, 20:49

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 1, 2, 3, 4  Další
Autor Zpráva
 Předmět příspěvku: Clovek verzus kompiler
PříspěvekNapsal: 08.11.2017, 18:14 
Offline
Óm Nejvyšší

Registrován: 22.05.2013, 21:14
Příspěvky: 3642
Bydliště: Bratislava
Has thanked: 371 times
Been thanked: 788 times
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 ?


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

Registrován: 31.08.2014, 16:27
Příspěvky: 994
Bydliště: Praha
Has thanked: 63 times
Been thanked: 373 times
Když ono to nebohé C musí zaručit, že každá volaná funkce má svoji lokální kopii parametrů v paměti určené též pro automatické proměnné, které jsou i měnitelné. Ruční úprava je samozřejmě rychlejší, ale tu zásadu jaksi poruší.

Co je to za překladač?


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Clovek verzus kompiler
PříspěvekNapsal: 08.11.2017, 18:44 
Offline
Radil
Uživatelský avatar

Registrován: 13.05.2013, 17:48
Příspěvky: 529
Bydliště: Košice
Has thanked: 423 times
Been thanked: 265 times
Busy píše:
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 ?

Kód:
8B 44 24 08         WindowProc  mov     eax,[esp+0x08]   ; eax = parameter Msg
83 E8 02                        sub     eax,WM_DESTROY
                                jnz      [DefWindowProcA]
50                              push    eax              ; nExitCode (eax = 0)
FF 15 74 B1 44 00               call    [PostQuitMessage]
31 C0                           xor     eax, eax
C2 10 00                        retn    10h

_________________
https://pmd85.borik.net - PMD 85 Emulátor, PMD 85, PMD 32-SD
https://pp01.borik.net - PP 01 Emulátor, PP 01, SD-ROM Modul


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Clovek verzus kompiler
PříspěvekNapsal: 08.11.2017, 19:20 
Offline
Óm Nejvyšší

Registrován: 22.05.2013, 21:14
Příspěvky: 3642
Bydliště: Bratislava
Has thanked: 371 times
Been thanked: 788 times
rombor píše:
jnz [DefWindowProcA]
Taku instrukciu x86 zial nema :) (ale toto ako prve napadlo aj mna)


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Clovek verzus kompiler
PříspěvekNapsal: 08.11.2017, 19:22 
Offline
Óm Nejvyšší

Registrován: 22.05.2013, 21:14
Příspěvky: 3642
Bydliště: Bratislava
Has thanked: 371 times
Been thanked: 788 times
baktra píše:
Když ono to nebohé C musí zaručit, že každá volaná funkce má svoji lokální kopii parametrů v paměti určené též pro automatické proměnné, které jsou i měnitelné. Ruční úprava je samozřejmě rychlejší, ale tu zásadu jaksi poruší.
A toto je prave jedna z veci, kedy ludsky pristup vitazi nad automatizovanym kompilovanim :)
baktra píše:
Co je to za překladač?
To taky obecny genericky prekladac :) Pozrel som kod vela roznych prekladacov (vratane najnovsieho Visual Studia od MS) a tento kod cca zodpoveda tomu co dokazali vygenerovat tie najlepsie z nich.


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

Registrován: 20.02.2017, 01:17
Příspěvky: 800
Has thanked: 19 times
Been thanked: 48 times
No říkal to i Fuka, že moderní kompilátory to umí lépe než člověk...


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

Registrován: 31.08.2014, 16:27
Příspěvky: 994
Bydliště: Praha
Has thanked: 63 times
Been thanked: 373 times
Předpokládám, že ten překladač byl nastaven na agresivní optimalizace a velkou tendenci k vkládání funkcí (to je vlastně přesně to co jsi udělal ručně).

Já bych kompilátory ale nezatracoval.
Třeba u architektury s 16stupňovým proudovým zpracováním, složitější hierarchií skrytých pamětí, složitou predikcí skoků, klonováním registrů a spekulativním prováděním instrukcí má dobrý překladač jazyka C větší šanci tohle všechno zohlednit.

Třeba IBM každé dva roky uspoří 3-6 % procesorového času databáze Db2 jen tím, že zdokonalí překladač jazyka, ve kterém je ta databáze napsaná. Myslím, že to píšou v PL/X.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Clovek verzus kompiler
PříspěvekNapsal: 09.11.2017, 00:31 
Offline
Radil

Registrován: 27.09.2014, 23:56
Příspěvky: 446
Has thanked: 436 times
Been thanked: 230 times
Téměř 30 let starý text.

Kód:
        Higher level languages are primarily a method of producing software
useful for corporations, because it can be written and understood by pro-
grammers with little knowledge of the equipment. This work can then be
passed on to another after he leaves, and little is lost. This same work
can also be moved to another environment simply by changing compilers.
Complex programs can be written quickly (This may be a fiction) and sent to
market.
        This all sounds pretty good, right? No. The price that we have to
pay for this is far too high. The size of these programs is becoming absurd.
This forces users (and that's what we all are) into a continual quest for
larger memory. The major debugging programs available leave no room in a
512k pclone to fit the program being debugged. Spreadsheet and database
programs are as bad and get worse with every new release of an 'improved'
version.
        The main program we use continuously is a major offender this way.
DOS has grown almost geometrically and has come to occupy a significant
fraction of available memory while adding few (if any) improvements since
version 2.0 (the continuing standard of compatibility).
        This situation is bad enough, but it is just the tip of the real
damage done by the NECESSARY use of high level language by the leading
software companies. Speed-- the magic word in computing is so thoroughly
compromised that the hardware industry is just holding its head above the
morass.
        Within the last year I have tried the latest release of the
assembler package from a major software company. I'm sure you know which
one I mean, but I'd rather not use names at this time so I don't have to
strictly document my figures. It was significantly larger than the previous
version (though somewhat faster 35 seconds as opposed to 50 seconds on the
program I tested it with). It would not assemble my source code from the
previous version without a number of silly modifications. The involved
syntax this package has traditionally used has annoyed me since the first
version I purchased. About this same time I tried a shareware assembler that
supports largely the same functions though in slightly differing form to
reflect the preference of the author. I won't say that it was without
flaws. No program is. After *removing* the instructions that have so irritated


me in the other I assembled the same program with this. It is a fraction
of the size (about 20k). It loaded itself, loaded and assembled my program,
delivered a complete COM file, and inserted some trivial error messages *into*
a copy of my original source file in ** 4 ** seconds. This is around the
same length of time it took the other assembler to load itself.
       The editor contained in the commercial package while very versatile,
and using some very clever techniques to speed up the usage, the first
time I tried to load a file in I thought my poor machine had bombed and
I reset it, but then I noticed that the disk was being accessed and it even-
tually displayed my file. The same situation occurred when I asked it to
show me it's help file. The shareware editor I am using now allows me even
greater versatility, only occupies about 15% of the memory and I can be
editing my file long before the other one would have loaded itself. And it's
not even completely written in assembly.
        In summation, while high level language may have its place, it is
not in programs expected to have high usage or when speed or size are
significant factors. The end users need to be given a choice and shown the
difference between quality programming and the corporate programming (much
of it vaporware) that they are now being offered.


Editorial z THE ASSEMBLY LANGUAGE "MAGAZINE" 1989

_________________
ZX Spectrum DELTA, D80, Melodik, XY4150, Aritma 0512
PGP: A6EA 1F93 EF6B D8D1 35AD B6D7 1E79 73E5 1B28 17F9


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

Registrován: 20.02.2017, 01:17
Příspěvky: 800
Has thanked: 19 times
Been thanked: 48 times
Tak nevím, ale pokud je pointou zkracovat programový kód a tím šetřit paměť, tak se obávám, že to v roce 2017 a na PC nedává příliš smysl. Zvláště když si uvědomím, kolik lidí asi i zde má naprosto nesmyslných 8 GB a více RAM. (Já sám mám 4 ale vlastně "pouze" 2,88 a i to jen proto, že prostě ASUS nenabízel nižší konfigurace)


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

Registrován: 05.09.2013, 14:08
Příspěvky: 1067
Bydliště: Smolenice
Has thanked: 130 times
Been thanked: 473 times
Keby mal takýto názor každý, tak už dávno potrebuješ 48GB pamäte, nie 8. Každá optimalizácia má zmysel, špeciálne ak sa na to pozrieš tak, že programátor sa tým učí priamo písať dobrý kód. A nemusí byť nutne kratší.

_________________
To err is human, but to really foul things up requires a computer.


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

Registrován: 31.08.2014, 16:27
Příspěvky: 994
Bydliště: Praha
Has thanked: 63 times
Been thanked: 373 times
Dobrý program by měl spotřebovat tolik paměti kolik je potřeba na jeho správnou a efektivní funkci.

Hezké jsou programy, u kterých lze škálovat jejich spotřebu paměti - máš méně paměti, dobře běžím normálně. Můžeš si dovolit více, řekni mi a já ji použiji na zrychlení (cache, pooly, buffery).

Zkracování spustitelného kódu může mít smysl, třeba tehdy, když je to velmi často pouštěný kód a je důležité aby se celý vešel do skryté paměti určené právě pro kód.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Clovek verzus kompiler
PříspěvekNapsal: 09.11.2017, 10:06 
Offline
Óm Nejvyšší

Registrován: 22.05.2013, 21:14
Příspěvky: 3642
Bydliště: Bratislava
Has thanked: 371 times
Been thanked: 788 times
baktra píše:
Předpokládám, že ten překladač byl nastaven na agresivní optimalizace
Urcite ano. Mojim cielom bolo ziskat kompilaciou co najkratsi kod.
baktra píše:
a velkou tendenci k vkládání funkcí (to je vlastně přesně to co jsi udělal ručně).
Urcite nie. MyWindowProc je funkcia ktoru vola system z kniznice a ta nemoze byt nikam vlozena. Podobne tak DefWindowProc, to je zase uz hotova kniznicna funkcia a vobec nie je sucastou aplikacie (leda zeby sisi zohnal user32.dll vo forme zdrojaku a ten skompiloval spolu s aplikaciou, co by bolo vylozene kontraproduktivne pretoze use32.dll je priamo sucastou systemu). To co som urobil ja, nebolo vlozenie funkcie, iba ina forma jej zavolania.
baktra píše:
Já bych kompilátory ale nezatracoval.
Ale ved ani ja ich nezatracujem :) Tam kde je prioritou co najrychlejsie nejak (jedno ako) 'zlepit' aplikaciu aby aspon nejak fungovala a casova/dlzkova efektivita a spolahlivost kodu nema velku prioritu, tam je samozrejme nejaky vysoky jazyk a jeho kompiler idealna cesta k cielu.
baktra píše:
Třeba u architektury s 16stupňovým proudovým zpracováním, složitější hierarchií skrytých pamětí, složitou predikcí skoků, klonováním registrů a spekulativním prováděním instrukcí má dobrý překladač jazyka C větší šanci tohle všechno zohlednit.
Je uplne jedno o aky programatorsky problem sa jedna, vzdy plati ze kompiler bude lepsi ako bezny clovek (pripad o ktorom pises ty), kdezto clovek ktory sa v danej platforme velmi dobre vyzna vie napisat lepsi kod nez akykolvek kompiler (o tomto pripade zase pisem ja).
baktra píše:
Třeba IBM každé dva roky uspoří 3-6 % procesorového času databáze Db2 jen tím, že zdokonalí překladač jazyka, ve kterém je ta databáze napsaná. Myslím, že to píšou v PL/X.
Keby venovali potrebny cas prepisaniu a odladeniu v asembleri, usetrili by hned 30-60% strojoveho casu :)
tommik píše:
Tak nevím, ale pokud je pointou zkracovat programový kód a tím šetřit paměť, tak se obávám, že to v roce 2017 a na PC nedává příliš smysl.
Evidentne si asi este nikdy nepocul o demoscene a roznych 256b, 1k, 4k, 64k intrach :poke: :)
tommik píše:
Zvláště když si uvědomím, kolik lidí asi i zde má naprosto nesmyslných 8 GB a více RAM. (Já sám mám 4 ale vlastně "pouze" 2,88 a i to jen proto, že prostě ASUS nenabízel nižší konfigurace)
Ako uz napisal z00m, keby (aspon niektori) ludia nemali snahu o dobry a efektivny kod, tak dnes by si s 8 GB ani neskrtol ale rovno potreboval 48GB pamete :shrug:

Cisto len pre zaujimavost. Posledny MSDOS zaberal v pameti okolo 100kB. Win3.11 bez problemov bezali na 2 az 4 MB pamete. Win98 uz potrebovali 16 az 32 MB. WinXP len sami o sebe po spusteni zabrali cca 350 MB. Ak by mikrosoft pokracoval v tomto trende, tak by Win8 zaberali 4GB a Win10 mozno aj rovno 40GB. Lenze (nastastie) po velmi zlej skusenosti s neefektiviou vo Vista sa aspon trosku uvedomil a ciste Win7 si obsadia uz "len" 1.2 GB ram a Win8 + Win10 nie o moc viac. Takze aspon nejaka optimalizacia ma vyznam aj v komercnej sfere.


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

Registrován: 18.06.2013, 20:26
Příspěvky: 2487
Has thanked: 115 times
Been thanked: 424 times
Busy píše:
Cisto len pre zaujimavost. Posledny MSDOS zaberal v pameti okolo 100kB. Win3.11 bez problemov bezali na 2 az 4 MB pamete. Win98 uz potrebovali 16 az 32 MB. WinXP len sami o sebe po spusteni zabrali cca 350 MB. Ak by mikrosoft pokracoval v tomto trende, tak by Win8 zaberali 4GB a Win10 mozno aj rovno 40GB. Lenze (nastastie) po velmi zlej skusenosti s neefektiviou vo Vista sa aspon trosku uvedomil a ciste Win7 si obsadia uz "len" 1.2 GB ram a Win8 + Win10 nie o moc viac. Takze aspon nejaka optimalizacia ma vyznam aj v komercnej sfere.

Už dlouhá léta se nemůžu zbavit pocitu, že kdyby Windows (jakákoli) dělaly jen to, co má z definice operační systém dělat, tedy zprostředkovat aplikacím přístup k HW prostředkům daného počítače (plus grafické prostředí pro uživatele, což dávám do závorky proto, že je to nad rámec definice OS, nicméně je to původním smyslem existence Windows, takže to k nim patří), zabíraly by daleko méně paměti, než jaká je realita.

_________________
"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: 09.11.2017, 10:53 
Offline
Óm Nejvyšší

Registrován: 22.05.2013, 21:14
Příspěvky: 3642
Bydliště: Bratislava
Has thanked: 371 times
Been thanked: 788 times
Jiiira píše:
zprostředkovat aplikacím přístup k HW prostředkům daného počítače (plus grafické prostředí pro uživatele...
Este k tomu pridaj multitasking viacerych aplikacii naraz. Ale inak plne suhlasim, na to aby OS robil to co ma, naozaj nepotrebuje zabrat tolko pameti.


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

Registrován: 31.08.2014, 16:27
Příspěvky: 994
Bydliště: Praha
Has thanked: 63 times
Been thanked: 373 times
To grafické prostředí je docela velké. Každé okénko, tlačítko a vůbec prvek uživatelského rozhraní potřebuje svoji datovou strukturu. A že je to okének a tlačítek. I ta podpora hardware leccos zabere - každý momentálně přítomný kousek hardware má svůj ovladač a ty také spolknou dost paměti. A nemluvíme o systému ovládání souborů. Samotný multi-tasking kernel u Windows zas tak velký nebude. Spíš "příslušenství kolem".


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 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