Eli yksinkertaisesti optimoimisesta. Olen aihetta toki tutkinut ja siinä mm. nopeuden että muistin optimointia, että itse sen koodin saamista niin pieneen tilaan kuin mahdollista. Nyt tietämyksen rajojen ilmetessä tahdon kuulla aiheesta enemmän. Eritoten käyttäjien omat kokemukset aiheesta ovat tervetullutta kuultavaa..
-Grey-
"Premature optimization is the root of all evil." -Donald Knuth
gcc -o jeequake5yhdessasorsatiedostossa kveikki.c -lSIKKRETKUAKELIPRARY -omg-optimize
Pääpaino siis tuossa -omg-optimizessa, se kato on niin kätevä :d
Sain aikanaan samaan kysymykseen sen yksinkertaisen vastauksen, että minun ei kannata olla huuolissani optimoinnista, koska esimerkiksi C-kielen kääntäjät huolehtivat optimoinnista tilanteen mukaan parhaalla tavalla. JVM
Ja mitenköhän teidän "neuvonne" vaikuttavat koodiin itsensä kehnouteen? Eipä taida paljoakaan kuules auttaa. Jos vittuilu taas oli kyseessä, niin neuvon sen heittämään menemään. Mielenterveydellisten ongelmien hoitoon kyllä löydätte psykiatrinkin, tai sitten napatkaa muutama tabletti.
Jotta tämä ei menisi off-topiciksi, niin aiheena on se miten helkutissa jotkut saavat sen koodin niin pieneksi. Jos demokoodaus ja eritoten oldskool on tuttua, päämääräni lienee tietäville selvä. Toki epäilen että olevani ainoa täällä, joka sitä koodia harrastaa, eikä vain rehentelyä, mutta saa nähdä miten käy..
Edit: @Jormi
Kuulehan, suoraan sanoen nykypäivän koodaus on evvk minulle. En ole aikeissani tehdä työkseni koodausta. Se on harrastus ja harrastuksessa ei ole mitään järkeä jos jokin über-hieno juttu rakentaa kaiken sinun puolesta. Lisäksi, ristisanoja ja sudokua karsastavana koodaus myös käy aivojumpasta minulle..
-Grey-
Mielestäni koodin saaminen pieneen tilaan oli aikaisemmin tärkeämpi asia, koska muistia oli käytettävissä vähemmän. Siinä ahtamisessa saattoi koodin selkeys kärsiä (esimrkikisi lyhyet muuttujien nimet), varsinkin kommenttien puuttuminen harmitti myöhemmin. JVM
P. S. Puhummekohan nyt samasta asiasta. Sama
No, jos jotain koittaisi vastata tähän. Jotain sekalaista tässä.
Alotetaan ihan niistä itse tiedostoista. Seuraava pätee ainakin Linuxin puolella, joka käyttää elffejä. Yleensähän se itse binääritiedosto sisältää kovin paljon turhaa tavaraa, jotka kasvattavat kokoa turhaan ja joilla ei oikeasti ohjelmaa ajettaessa tehdä mitään. Ne saa yleensä helposti pois oikealla linkkerin optiolla. Katso manuaalista mikä on sopiva.
Windowsissa kai ainakin ennen kikkailtiin jotenkin com-tiedostojen kanssa, koska nykyisen käytössä oleva PE (Portable executable) tiedostoformaatti vie paljon enemmän tilaa. Tarkemmin en tuosta muista miten se tapahtuu.
Itse koodiakin voi tietty koittaa pienentää, mutta esim. C-kielellä ohjelmoitaessa voi vain arvata millaista assemblykoodia kääntäjä tuottaa, niin homma voi mennä harakoille.
Assemblykielistä koodia voi helpommin koittaa muokata pienemepään tilaan käskyjä vaihtamalla. Tämä kuitenkin vaatii tietoa käskyjen muodostumisesta ja onkin yleensä vasta se viimeinen optimointitoimi tilan säästämiseksi. Harvoin kuitenkaan on tarvetta ihan ne viimiset tavut puristaa pois siitä koodin koosta.
Demoista kun puhe oli, niin pitänee vielä mainita .krieger (http://en.wikipedia.org/wiki/.kkrieger), näyttävä 3D FPS-peli, jolla kokoa vain 97 280 tavua. Aika vaikuttava taidonnäyte kyseessä.
Näkisin, että keskustelussa on turha alkaa väittelemään tämänkaltaisen optimoinnin tarpeellisuudesta. Totta on, että kääntäjät tuottavat yleensä paljon parempaa koodia kuin suurin osa ohjelmoijista. Pienten yksityiskohtien optimointiin ei yleensä tarvitse mennä, vaan keskittyä suuriin viivoihin.
Kuitenkin mahdollisimman nopean/pienen koodin tuottaminen voi tarjota mukavia haasteita ja eriomaisiin tuloksiin pääseminen edellyttää yleensä hyvää tuntemusta niin käytetystä kielestä, alustasta kuin kääntäjästäkin.
Tästähän saisi putkaan vaikka jonkun kivan kisan. Kuka tekee pienimmän ennaltamäärätyn yleisen ohjelman tai ongelman ratkaisevan algoritmin. Itse ainakin voisin osallistua sellaiseen.
Nah, ei niitä selkeitä muuttujia tai kommentteja ole ennenkään käytetty. Ja kysehän ei ole nyt tärkeydestä, vaan haasteesta. Kaikki logiikallani löytyvät keinot on jo käytetty, jotenka on keksittävä jotain uutta. Kyse on tosiaankin harrastuksena koodaamisesta. Niiden on vaikea ymmärtää asiaa, jotka vain rakentavat ohjelmia, harrastamatta itse sitä koodausta. Nykypäivän koodaus tuppaa olemaan niin tylsää, ja sitä ei kannata edes kuvitella harrastavansa silloin kun tavoitteena ei ole rakentaa mitään projektia. Tietenkin jollei sitten perehdy 64k demoihin, mutta oldskool sattuu vetämään enemmän puoleensa. Mitä vähemmällä aineksella on saatu jotain näyttävää aikaan, sen enemmän se tuppaa kiehtomaan..
edit: @Päärynämies
Yep, aivan noin ja aivan samaa mieltä..
-Grey-
Tässä ilmeisesti oli puhe suorittevan koodin koosta, eikä sen lähdetiedoston? Suoritettavan tiedoston koko ei kasva, vaikka muuttujat nimeäisi kuinka pitkästi hyvänsä. Myöskään kommentit eivät vaikuta syntyvän suoritettavan koodin kokoon.
Itsellä jonkinlaisia suunnitelmia tässä ollut, että koodailisi jotakin pientä peliä tai jotain mahd. pieneen tilaan ja niin, että mahdollisimman paljon (grafiikka) luodaan lennosta erilaisia kaavoja käyttäen. Pitäisi vain ideaa kehitellä pidemmällä, että tietää kannattaako koodailla ja löytyykö intoa.
Olen harrastellut matematiikkaa ja käyttänyt avuksi mikroja 1980 luvun alusta lähtien. Matematiikaasa pätee mielestäni se, että koodia pitää tiivistää ennen koodausta. Teimme amerikkalaisen harrastekirjan pohjalta demoa planeettojen liikkeistä. Ohjelma lyheni ja nopeutui, kun Newtonin fysiikan kaavakokoelma sievistettiin mahdollisimman pitkälle. Sumean logiikan ohjelmaa tehdessäni havaitsin, että kolmiolukujen laskennan kaavojen tiivistäminen paransi ohjelmaa. JVM
P. S. Mitä haasteisiin tulee, terveydenhoito suositteli minulle jotain tarpeeksi vaikeaa aivojumppaa. Nyt esillä oleva yhdistelmäni: merenkulun tähtitiede, pallotrigonometria ja C-kieli on juuri sitä. Ja päälle tulee vielä englanninkieli, koska koulussa luin saksaa ja venäjää. Sama
Voihan se olla niin, että kun noita kaavoja tiivistää ja pyörittelee, niin saattaa turhia muuttujia jäädä pois tai koodi vain muuttuu sellaiseen muotoon, että kääntäjä tuottaakin nopeampaa koodia. Vaikka ero ei kovin iso olisi, niin silti jos kyseistä funktiota kutsutaan useasti, niin nopeusero voi olla jo merkittävä.
Jos halutaan optimoida ohjelma toimimaan nopeasti, niin silloinhan on tärkeätä hyvä ohjelman rakenteen ja käytettävien algoritmien suunnittelu. Siitä sitten, jos haluaa vielä lisää nopeutta, niin voi niitä algoritmien yksityiskohtia alkaa hiomaan ihan assemblytasolla. Tietysti vielä suorituksen nopeuttamiseksi voi huomioida eri välimuistien tehokkaan käytön ja prosessorin tavan suorittaa käskyjä. Ne menevät kyllä sellaisen optimoinnin puolelle, joka hyvin harvoin on tarpeellista.
Joo. Puhe taisi olla enemmänkin suoritettavan tiedoston koon pienentämisestä äärirajoille.
Grey: Jos tarkentaisit mitä tiedät tällä hetkellä ja missä ne rajat tulevat vastaan, niin olisi helpompi antaa neuvoja, jos sattuisi olemaan aihealue, josta jotain tiedän/osaan.
Tiedän jotain perustason optimoimisesta. Esim. muuttujanimet, aliohjelmien käyttö toistuviin toimintoihin, ym. Siis todellakin sen minkä huomaa käytännössä itse vähän päästä. Että osaan jo olevaa koodia aina karsia paria kiloa pienemmäksi, mutta siitä eteenpäin ei sitten millään. Eli kun puhutaan perustasoa kovemmasta optimoisesta, omat taidot eivät riitä..
-Grey-
Jos ohjelma käsittelee suuria tietovarastoja, ovat lista- ja puurakenteet tehokkaampia kuin taulukot. Tarkoitan nimenomaan tieojen hakemisen nopeutta. JVM
Heippa taas!
@Grey
Jotenki minulle on jäänyt sellanen kuva, että olet QB-ihmisiä. Jos on näin, niin pukkaa vähän kamaa kirjastoihin, eli teet ikäänkuin systeemin systeemin sisään elikä nyt jos vaikka haluat esim hiiren käyttöön ohjelmaasi niin lue se data (HEX$) stringiin ja siitä sit SADD(stringi) ja niin sulla on valmis machine-code stringi, jonka tallennat tiedostoon, jonka sitten kopioit ram-levylle QB (.BAT|PUTKI) avaamisen yhteydessä, mistä se on jouheva lukea, kun tarvitaan. No kun sit tarvitset niin luet stringin RAM-levyn tiedostosta ja suorittelet tämän osuuden Call Absolutella(stringi, para, met, rit). Toinen kiva QB-jutska on CHAIN/COMMON joiden avulla voit tarvittaessa kirjoitella suoritettavia ohjelmia RAM-lvylle lennossa ja ajella taustalla. Esim. jos ajatellaan vaikkapa laskinta QB:llä niin menee aika pieneen se koodi kun... ***
'LASKIN.BAS COMMON SHARED STRINGI AS STRING COMMON SHARED LASKETTU AS STRING COMMON SHARED TULOS AS DOUBLE '... IF LASKETTU <> "TRUE" THEN STRINGI = "" FOR I = 1 to 80 STRINGI = STRINGI + CHR$(SCREEN(1, I)) NEXT I MAKE_LASKE END IF IF LASKETTU = "TRUE" THEN PRINT TULOS LASKETTU = "FALSE" END IF SUB MAKE_LASKE() '*** kirjoittelee itse laskennan suorittamiseen tarvittavan 'osuuden vaikkapa lennossa RAM-levylle tyyliin... '(tätä ei tietenkään ole mikään pakko kirjoitella lennossa 'vaan ohjelma voi olla valmiiksi ladattuna RAM-levylle jne...) OPEN "Z:\LASKE.BAS" FOR OUTPUT AS #1 'TÄSSÄ SIIS LASKIN PRINT #1, "COMMON SHARED STRINGI AS STRING" PRINT #1, "COMMON SHARED LASKETTU AS STRING" PRINT #1, "COMMON SHARED TULOS AS DOUBLE" PRINT #1, "TULOS = " + STRINGI PRINT #1, "LASKETTU = " + CHR(32) + "TRUE" + CHR(32) PRINT #1, "CHAIN LASKIN.BAS" PRINT #1, "END" CLOSE #1 CHAIN LASKE.BAS END SUB
@everyone
Nyt jos käytössä on esim. WIN XP niin ram-levyn saa käyttöön vaikkapa kun...
imppaa täältä sen XP.PRO trial paketin (älä asenna! vaan pura asennuspaketti esim. UniExtract-ohjelmalla), jonka voi impata esim. täältä
ja siirtelee %windir%\inf -kansion tiedostot C:\WINDOWS\INF -kansioon ja lukee sitten täältä ohjeet
@Neau33
Muistin aika selvästi että sinähän olet noita purkan perään olevia. Siis, tuo on niin älytöntä ei-optimaalista purkkaa, että jos sitä kutsuu koodaukseksi, suosittelen alan vaihtoa asianomaiselle välittömästi. Sitä paitsi, teet myös virheolettamuksia, etkä vain ympäristöstä. XP, hmph. Sitä en omista edes pääkäyttiksenä, eikä löydy edes warena.
Koodauksen puolella asiat kohdistuvat puhtaasti Dosin suuntaan, ja sillä ei taida toimia XP-purkka, eikä muukaan Windows-purkka. Kun sellaista ei simppelisti ole. Jotenka unohda Windows, jos tahdot minulle olla avuksi. Unohda myös megojen kokoinen muisti ja nopeus. Koko voidaan laskea kiloissa ja nopeus muutamassa megahertzissa, jos sitäkään.
Ja jos vielä haulla katsot tuolla muista kielistä, niin huomaat että olen esittänyt melko mielenkiintoisen kysymyksen assemblyyn liittyen, eikä kyse ole 80486:n kannasta, mutta parista vanhemmasta. Että siinä sinulle ympäristöä. Olikos sitä jotain puhetta joskus sinulta ohjelman sovittamisesta 48 kiloon ja alle? Aika näyttää onkos ne puheet olleet sinulla totta..
-Grey-
Heippa taas!
harvoin tulee vastaan toista moista itseriittoisuutta...
Sori väärinymmärrtäminen, että kyse ei ollutkaan systeemin optimoinnista vaan yksittäisen ohjelman koodin karsiminen lähes olemattomiin, josta seurauksena vähintään henkinen orgasmi...
neau33 kirjoitti:
...josta seurauksena vähintään henkinen orgasmi...
Näkyykö se silti ulospäin?
Mikä on kun ei taidot riitä, mikä on kun ei onnistu. http://www.agner.org/optimize/ tsa tsa tsa. Olet varmaan noita jo lukenutkin?
Optimointi on turhaa, ennenkuin siitä on mitään hyötyä. Ja siitä on hyötyä vasta silloin, kun sen vaikutukset näkyvät käyttäjälle (sinä?). Oli sitten harrastus tai ei, optimointia ei kannata aloittaa ennen testausta. Toki ohjelma kannattaa suunnitella alusta asti sellaiseksi että se on tarkoitukseensa sopivan tehokas mutta mitään funktiotasoa alempaa manuaalista optimointia on ihan turha tehdä ennenkuin näkee lopputuloksen. Tärkeintä on kuitenkin koodin profilointi - eli manuaaliseen optimointiin kannattaa panostaa vain niissä ohjelman osissa joissa siitä on oikeasti jonkinmoista hyötyä.
Binäärin koon rajoittaminen onnistunee parhaiten komentamalla kääntäjää. Sama pätee myös tähän, jos tiedostokoko on liian suuri ala sitten vasta optimoimaan. En voi sanoa että olisin mistään muinaisohjelmoinnista kiinnostunut (vähän kokemusta tosin perus 68k:sta ja 6510:sta, sekä ARM:eista) eikä että osaisin niille erityisen kompaktia koodia varsinaisesti tehdä.
Tiedostokoon rajoittaminen vain periaatteen vuoksi (ymmärrettävää rajoittuneilla alustoilla) kuten demoskenessä on vain ajanhukkaa.
anttipanda kirjoitti:
Tiedostokoon rajoittaminen vain periaatteen vuoksi (ymmärrettävää rajoittuneilla alustoilla) kuten demoskenessä on vain ajanhukkaa.
Väittämäsi on ristiriitainen siinä mielessä että koodaus itsestään on ajanhukkaa, jos siitä ei saa rahaa. Näin ollen, tuon väittämäsi pohjalla voitkin saman tien suositella minua luopumaan koodauksesta, koska en sitä tee ensinnäkään työkseni ja toiseksi tähtäimessä ei ole edes mitään projektia. Vähäiset kiitokset kuitenkin linkeistä, vaikka koetakin saarnata minulle sinäkin Brutukseni..
-Grey-
Grey kirjoitti:
Väittämäsi on ristiriitainen siinä mielessä että koodaus itsestään on ajanhukkaa, jos siitä ei saa rahaa. Näin ollen, tuon väittämäsi pohjalla voitkin saman tien suositella minua luopumaan koodauksesta, koska en sitä tee ensinnäkään työkseni ja toiseksi tähtäimessä ei ole edes mitään projektia.
En ole vastauksessani väittänyt että koodaus olisi ajanhukkaa ilman palkkaa. Ei suinkaan, mutta _turha_ optimointi on sitä itseään. Turhana näen _edelleen_ sellaisen optimoinnin joka ei vaikuta ohjelman toimintaan mitenkään, tai jolla ei ole mitään muuta virkaa kuin "skeneily" eli elimensuurennus. Voithan tehdä itsellesi tai kavereillesi hyödyllisen ohjelman tai huvittaa itseäsi. Hyötyä se on sekin. Koodailen itse jatkuvasti omia pieniä ohjelmia joilla teen asioita, enkä näe sitä ajanhukkana. Vaikka softainsinööri olenkin ammatiltani.
Grey kirjoitti:
Vähäiset kiitokset kuitenkin linkeistä, vaikka koetakin saarnata minulle sinäkin Brutukseni..
Näin ollen, voisit vähän miettiä asennettasi. Toki saat tehdä ajallasi mitä haluat, kuten mekin teemme vastaillessamme sinulle. Ja ei niitä pdf:iä ole pakko lukea jos osaat jo homman paremmin. Ihme asenne jampalla... Ensin pyytää apua ja sitten kun sitä yritetään antaa niin väitetään saarnaamiseksi.
anttipanda, yritätkö nyt tulla tänne tuputtamaan käsitystäsi siitä, mikä on ajanhukkaa? Jos demoskeneily on jonkun mielestä hauskaa, niin ei se silloin ole ajanhukkaa. Hauskat asiat eivät ole ajanhukkaa, saipa sitten nautintoa vaikka veteen piereskelystä. Mene samantien vaikka moottoripyöräfoorumeille huutamaan että moottoripyöräily on ajanhukkaa, siitä ei ole mitään hyötyä kenellekään. Pelkkää hupia...
Tumpelo kirjoitti:
anttipanda, yritätkö nyt tulla tänne tuputtamaan käsitystäsi siitä, mikä on ajanhukkaa? Jos demoskeneily on jonkun mielestä hauskaa, niin ei se silloin ole ajanhukkaa. Hauskat asiat eivät ole ajanhukkaa, saipa sitten nautintoa vaikka veteen piereskelystä. Mene samantien vaikka moottoripyöräfoorumeille huutamaan että moottoripyöräily on ajanhukkaa, siitä ei ole mitään hyötyä kenellekään. Pelkkää hupia...
En. Vastasin vain minua vastaan esitettyihin "syytoksiin". Mutta jos ajattelee optimointia järkevästi (kuten ohjelmoijan kannattaisi tehdä), kannattaa panostaa sellaiseen josta on hyötyä.
Tuo moottoripyöräanalogia oli siinä mielessä ontuva, ettei ohjelmointiputka käsittääkseni ole demosivusto, eikä optimoinnin hyödylisyyden arvostelu satuta juurikaan lukijoiden sydämiä.
Pakkohan tällaiseen kinasteluun on osaa ottaa, kun jo aiemminkin ketjuun postasin.
Minusta on edelleen turha tässä alkaa kinastelemaan siitä, että onko se tiedostokoon optimointi nyt niin hyödyllistä vai ei. Eihän sillä enää oikeasti paljoa tee, kun nykylaitteissa alkaa olla jo aika kivasti sitä tilaa niille ohjelmille. Suoraa hyötyä siitä siis ei taida paljoa olla.
Jos ohjelmointi on kuitenkin vain harrasta, niin ei kai sen hyödyllistä tarvitse ollakaan. Itse ainakin valitsen harrastukseni sen mukaan mistä pidän ja mikä on mukavaa, en sen mukaan mikä on hyödyllistä.
Anttipanda taas koodausta työkseen tekevänä tietää, että ei se pomo iloinen välttämättä ole, jos työaikansa käyttää sellaiseen optimointiin, jolla ei oikeasti ole väliä ohjelman/tuotteen kannalta.
Tottahan toki asiat näyttävät erilaisilta harrastelijan ja ammattilaisen silmin.
Käsittääkseni tässä langassa Grey halusi vinkkejä optimointiin saadakseen tiedostokoon alle esim. 4k:n. Ymmärtääkseni tämä johtuu kiinnostuksesta demo-skeneä kohtaan. Lähes kaikissa demo-kompoissa on sarjat, joihin osallistuminen edellyttää tarpeeksi pieneen tiedostokokoon pääsemistä. Usein kompoja vaikeutetaan tarjoamalla alustaksi vähätehoinen laitteisto, jolloin melko raskaskin optimointi on tarpeen.
Tällaisessa tapauksessahan tiedostokoon optimoinnin voi sanoa olevan hyödyllistä.
Vaikkei mihinkään kompoon olisi aikomusta heti osallistuakaan, niin on kuitenkin järkevää suunnilleen päästä haluttuun tiedostokokoon heti alkuvaiheessa, jotta saa edes jonkinlaisen käsityksen mitä voi tähän kokoon ahtaa ja mitä ei.
Suurin osahan tästä oli vain omaa spekulaatiotani - enhän voi tietää mitä Grey tällä haki. Valitettavasti itse ein ole näiden alustojen koodaukseen juurikaan perehtynyt, joten en voi itse kysymykseen vastata.
Grey, <jokin pieni luku>k -demokoodauksen salaisuus: Käytössä ovat käyttöjärjestelmän dynaamiset kirjastot, työkalut, fontit, äänet...
Toisin sanoen ohjelmaan koodataan minimalistinen dynaamisten kirjastojen lataaja, joka lataa vain ja ainoastaan tarvittavat funktiot. Tämän avulla kaikki mahdollinen toiminnallisuus linkitetään ohjelmaan dynaamisesti OpenGL:stä, Direct3D:stä, Glutista tai ihan mistä pystytään. Kaikki mahdolliset bittikartat ja äänet generoidaan tai ripataan käyttöjärjestelmästä, jos voidaan.
Kääntäjän tekemiin tiedostoihin jää pieniä määriä turhaa roskaa, jonka voi karsia pois. Ainakin Unix-pohjaisissa demoissa ohjelma on käytännössä aina shell-skripti, joka unzippaa varsinaisen ohjelmakoodin ja ajaa sen. Lisäksi käytetään tuhatta ja yhtä muuta kikkaa, joilla viimeisetkin tavut saadan karsittua pois.
Tämä ei ole mitään normaalia "koodin optimointia" vaan hakkereiden ja demo-koodareiden urheilulaji, jonka tuloksena saadut ohjelmatiedostot toimivat pahimmassa tapauksessa ainoastaan yhdellä tietokoneella.
Tässä välissä voisin esittää ilman sen kummempia kommentteja tavan, jolla Chuck Moore ohjelmoi. Ympäristö on saatu kutistettua aika pieneen tilaan, ja se toimii ilman käyttöjärjestelmää useilla PC-koneilla. Lienee mahdollista kokeilla myös QEMU:n kanssa.
Sivulla on eräitä varsin yllättäviä mielipiteitä mm. käyttöjärjestelmien tarpeellisuudesta. Kannattaa tutustua vähän erilaiseenkin ajatteluun joskus, vaikka ei sitä haluaisi omaksuakaan. Wikipediasta voi vilkaista, kuka tämä kaveri oikein on...
Riippuu toki millä kielellä ja kääntäjällä koodaa. Jos käytössä on jokin muu kuin assembly, vaikkapa C/C++, niin olisi syytä perehtyä siihen millaista konekielistä koodia se sylkee. Windowsissa ainakin MinGW:llä ja Visual Studion kääntäjillä on tapana lisätä funktioon epilogi ja prologi aina, vaikka sille ei olisi tarvetta (ne PUSH EBP; MOV EBP,ESP ja POP EBP). __declspec(naked) attribuutin määrittämällä funktiolle VC++:ssa voi kieltää kääntäjää luomasta näitä -> tadaa! 13 sykliä tai jotain sinne päin ja 4 tavua säästetty :p
__fastcall-tyyppiset funktiokutsut ovat hyviä nopeuden kannalta, mutta en ole varma kuinka on koon puolesta. Jos kääntäjä haluaa väkisin työntää ne parametrit stackkiin jossain vaiheessa, niin eipä siinä ainakaan kovin montaa tavua säästä. Ehkä tää on just sitä pilkunviilausta, josta ei loppupelissä ole mitään silminnähtävää hyötyä. Mikäs siinä jos kiinnostaa, minua ainakin.
Koodin koosta voi saada helposti puristettua jopa 50% pois käyttämällä jotain pakkeria, huonona (?) esimerkkinä UPX. En juuri demoskeneilystä tiedä, että onko pakkerien käyttö kuinka suotavaa. Tosin os tuossa kyllä taisi mainita että Unix-pohjaisissa demoissa tälläisiä käytetään ja olen joskus kuullut demoille suunnatuista pakkereista.
Aihe on jo aika vanha, joten et voi enää vastata siihen.