Tein aikoinaan vuosia sitten ohjelman jossa main osiossa on functiokutsuja loopissa, functiot saa kaikki tiedot globaalien muuttujien kautta, ei parametreina. Noita functioita kutsutaan muistaakseni parisenmiljoonaa kertaa ellei enemmälti.
Nyt olen oppinut oliopohjasesti ohjeilmoimaan. Joten kysymys kuuluukin jos teen tuosta ohjelmasta oliopohjaisen niin nopeutuuko se? Jos niin kuinka paljon?
Ei huvittaisi turhaan koodata ohjelmaa uusiksi huomatakseen, että ainoa hyöty onkin vain koodin selkeys jne... ja nopeus samana.
Nyt olen oppinut oliopohjasesti ohjeilmoimaan. Joten kysymys kuuluukin jos teen tuosta ohjelmasta oliopohjaisen niin nopeutuuko se? Jos niin kuinka paljon?
Ei huvittaisi turhaan koodata ohjelmaa uusiksi huomatakseen, että ainoa hyöty onkin vain koodin selkeys jne... ja nopeus samana.
Vastaukset 87
Vanhimmat
olioistamisesta olisi kauheasti hyötyä.
Ei tuohon osaa vastata ilman lisäinfoa. Ensinnäkin pitäisi tietää tehtävään menevät ajat tai kokonaisaika. Sitten pitäisi tietää onko funktioissa käytetty inline:a vai ei.
Voihan se oliopohjaikseksi muuttaminen lisättäkin kuluvaa aikaa. Mahdoton sanoa noiden tietojen pohjalta.
Ohjelman suoritus kestää siinä minuutin verran joten siinä mielessä lisänopeus ei olisi pahitteeksi. Functiossa on inline määre ilman niitä kestää viel kauemmin.
Lähinnä vaan meinasin sitä tuoko tuo olioistaminen mitään nopeus hyötyä, ilmeisesti ei saattaa jopa hidastaakin, joten ilmeisesti pikkuohjelmia missä nopeus tärkeintä ei kannata oliolla tehdä?
täällä edes yksi aa tee koo neropatti kerrankin itse etenkin itselleen myöntää, ettei varsinaisestikaan tiedä mistä puhuu, mutta voihan hän olla mitä ilmeisimminkin lähtö kohtaisesti provo katiivisesti kalastelemassa täällä olio pohjaisen ohjelmoinnin perusteita ja hienouksia nut shellinä eli helppo tajuisena pähkinän kuorena, mutta turhaan, niin turhaan: eihän siinä mitään vaikea tajuista edes ole.
jos nopeus on tärkeintä, teet assemblyllä
Jos ohjelman funktioiden välillä ei ole mitään yhteistä (parametrit / muuttujat) tai jos siinä ei hyödynnetä templateja, ei oliopohjasta ole hyötyä. Lisäksi pienissä ohjelmissa koodin kirjoittamiseen menevä aika on ratkaiseva eli pitäisi löytää mikä on omasta mielestä nopein tapa päästä ratkaisuun.
Yleensä tuollaiseen kysymykseen 'Mikä on nopein ?' vastaus etsitään Profiler -ohjelmilla. Siinä ohjelmasta mitataan kaikkiin kohtiin menevä aika ja Profiler ehdottaa mitä kohtaa kannattaisi muuttaa.
X86 puolella olio-ohjelmat ovat yleensä hieman hitaampia, kun funktion parametreille tehdään enemmän tarkastuksia ja yksi koneen rekistereistä on olion osoittimen käytössä. Mutta suuremmilla ohjelmilla tai jos templateista hyödytään, koodin kirjoittamiseen menee vähemmän aikaa.
Käsittääkseni kukaan ei ole edes kuullut kaupallisesti menestyneestä tahi edes varteenotettavasta ohjelmistotuotteesta, joka olisi ohjelmoitu assemblyllä. Joskus toki kieltämättä kuulee huhuja, että nyt ne taaskin tekee assylla niin nopeaa kaupallista sovellusta, ettei varmana oo kellään, mutta se on niillä mitäilmeisimminkin taaskin vieläkin tekeillä.
kuka puhui koko softan koodaamisesta assylla???
"Käsittääkseni kukaan ei ole edes kuullut kaupallisesti menestyneestä tahi edes varteenotettavasta ohjelmistotuotteesta, joka olisi ohjelmoitu assemblyllä."
Mm. BIOS'it ja DOS-alustat väännetään assemblyllä.
omalla viestilläsi ja vain pienellä muutoksella:
" täällä edes yksi aa tee koo neropatti kerrankin itse etenkin itselleen myöntää, ettei varsinaisestikaan tiedä mistä puhuu, mutta voihan hän olla mitä ilmeisimminkin lähtö kohtaisesti provo katiivisesti kalastelemassa täällä olio pohjaisen ohjelmoinnin perusteita ja hienouksia nut shellinä eli helppo tajuisena pähkinän kuorena, mutta turhaan, niin turhaan: eihän siinä mitään vaikea tajuista edes ole."
tuon oliopohjaisen ohjelmoinnin kohdan poistaen..
;D
peliä tai aikakriittistä sovellusta. tärkeintä on aina koodin ylläpidettävyys ja selkeys ja siihen kuuluu olennaisesti olioistaminen. laskentateho kasvaa kaiken aikaa...
molemmista assembly-listauksen ja tutkit. Ei tarvitse koko koodia kääntää vaan yhden funktion ja siihen kutsuvan funktion ..
Teet pienen testiohjelman pätkän.
Käsittääkseni globaalit muuttujat ovat nopein tapa käsitellä.
Jos tehdään aliohjelma joka käyttää sisäisiä muuttujia, niin muuttujan siirto toiseen muistipaikkaan tulee aina lisäksi. Olio-ohjelmathan toimivat tietysti samoin.
Aikaero ei ole suuri, mutta siinä olio-ohjelma kyllä aina häviää.
"Jos tehdään aliohjelma joka käyttää sisäisiä muuttujia, niin muuttujan siirto toiseen muistipaikkaan tulee aina lisäksi."
Miksi tulisi siirtää 'toiseen paikkaan'?
Suorittimen rekisteri on tietysti nopein tapa muuttujille, mutta C/C ei mahdollista monen muuttujan säilyttämistä funktioiden välillä rekisterissä. Toiseksi nopein on X86:ssa on pinomuisti (funktion parametrit, paluuosoitteet ja funktion sisäiset muuttujat, jotka eivät mahdu rekistereihin). Koska muisti on jatkuvasti käytössä, sen sisältö on pienillä tietomäärillä aina suorittimen välimuistissa.
Mutta jos funktiossa on edes osa tiedosta muualla kuin pinossa (esim. tekstit ja liukuluvut), ero valitun muistipaikan (globaali pino) välillä pienenee.
Pinoa ei kannata käyttää siis muistipaikkana valmiiksialustetuille tiedoille, koska sama asia on silloin kahdessa paikassa ja hidastaa ohjelmaa:
void funktio(void)
{
//Tieto on tässä kahteen kertaan (koodissa ja funktion alkaessa pinossa)
int taulu[] = {1,5,2,6,7,4,8,...}; //Parempi määritellä static
.
:
}
Aiheesta voi lukea tarkemmin esim.:
http://www.agner.org/optimize/optimizing_cpp.pdf kohta 6.1 (sivu 18)
Siis kun aliohjelmalle välitetään muuttuja ja jos aliohjelma käyttää sitä laskentaan, mutta ei sen arvo ei saa palautua pääohjelmaan.
Jos Aliohjelma-modulissa (tai funktiossa) on esim. Muuttuja1=Muuttuja1 2.
Basic 6:ssa kutsu Call Aliohjelma(Muuttuja1) tekee sen että aliohjelma Muuttuja1 arvo muuttuu myös pääohjelmassa.
Jos kutus on Call Aliohjelma(Byval Muuttuja1), niin aliohjelman Muuttuja1 arvo ei muutu pääohjelmassa.
Olio-ohjelmointihan aina tarkoittaa että ei käytetä kutsussa tulevaa muistipaikkaa vaan tehdään uusi. Eihän muuten rekursiiviset kutsut onnistuisi. Ja kun useita olioita voidaan suorittaa yhtäaikaa, niin arvo muuttuisi satunnaiseen aikaan pääohjelmassa siinä tapauksessa että pääohjelma ei jää odottamaan olion suorituksen loppumista.
Nykyiset prosessorit suorittavat useita käskyjä liukuhihnalla yhtä aikaa. Ne yrittävät myös ennustaa mitkä käskyt kannattaa suorittaa. Kun tuo ennustus meni väärin, niin liukuhihna tyhjennetään ja tehdään samat asiat uudestaan. Eli kun vierekkäiset liukuhihnat ovat käsitelleet asiaa jossa esim. sama muistipaikka on muuttunut.
Nykyprosessorien toiminta kuulostaa kyllä aika ufo-meiningiltä.
http://fi.wikipedia.org/wiki/Intel_Pentium
"Suurin ero i486:een verrattuna on se, että Pentiumissa on kaksi liukuhihnaa ("U" ja "V"), joten se voi suorittaa enemmän kuin yhden käskyn kellojaksoa kohti. U-liukuhihna voi suorittaa minkä tahansa käskyn, kun taas V pystyy suorittamaan vain jonkin yksinkertaisen käskyn. Tämä ominaisuus on tyypillinen RISC-suorittimille. Tämä olikin ensimmäinen kerta, kun RISC-suorittimien ominaisuus lisättiin x86-arkkitehtuurin suorittimeen. Pentiumissa on lisäksi 64-bittinen datapolku, eli se saa muistista kaksi kertaa enemmän dataa kellojaksoa kohti."
http://www.cs.hut.fi/Publications/Reports/C9204.pdf
"Pipeline stall: käsky ei pääse etenemään seuraavaan vaiheeseensa liukuhihnalla, ja liukuhihna "pysähtyy", jotta tarvittavat operaatiot saadaan suoritettua ja käsky pääsee jatkamaan matkaansa. Stall on ei-toivottu tilanne, sillä se hidastaa kokonaissuoristusta.
...
Ohjelmakoodin haarautumiseen (hyppyihin) liittyviä ongelmia on kahdenlaisia: ehdolliset
hypyt (kontrollirakenteet) ja hypyt tuntemattomaan (funktio-osoittimet). Kummassakaan tapauksessa
ei voida olla varmoja, mitä käskyjonoa pitäisi suorittaa ennen kuin suoritus on jo
pitkällä liukuhihnalla ja pahimmassa tapauksessa jono oli väärä, eli kaikki tehty työ meni
hukkaan ja liukuhihna täytyy tyhjentää.
Väärän käskyjonon suorittaminen on monessa suhteessa ongelmallisin hasardityyppi;
sitä vastaan ei voida taistella esim. rekisterien uudelleennimeämisellä. Lisäksi etäisyys virheen
tapahtumisesta virheen havaitsemiseen liukuhihnalla on suuri, jolloin menetetään paljon
työtä. Lisäksi voi syntyä vielä käskyvälimuistin kanssa ongelmia. Normaalisti käskyvälimuisti
esihakee käskyjonoa, jotta liukuhihnaa pystyttäisiin ruokkimaan mahdollisimman
tehokkaasti (täyttä suoritustehoa varten käskyvälimuistista pitää pystyä lataamaan neljä tai enemmänkin käskysanaa per kellojakso), joten huti käskyvälimuistissa voi olla melkoinen
katastrofi."
http://www.compusmart.ab.ca/fenske/cpasm06s.txt
.. ymmärtäisitte mitä lopultakin tapahtuu jalommissa kielissä.
Pinoja ja osoittimia ja intelin ja sen sukuisissa prosessoreissa segmenttejä ..
Joskus 20 vuotta sitten tein konekielellä (Debuggerilla suoraan) tiedonsiirto-ohjelman cp\m-tietokoneelle. Toinen kone oli joku kuvankäsittelijä, jonka tallennuspalikat olivat kalliita, joten tietokoneratkaisu oli halpa asiakkaalle. Silloisissa prosessoreissa (8080) oli suppea käskykanta, joten ei se ollut vaikeaa.
Konekielellä siksi kun basic ei ollut riittävän nopea.
Nykyään ohjelmointivälineet ovat kehittynyt huimasti, joten en näe mitään syytä tavallisen ohjelmoijan enää opiskella konekieltä.
Pinoja ja sellaisia silloin tuli käytettyä.
Mutta se on historiaa. Nykyään nuo ovat vain triviaaleja juttuja.
Koneet ovat nopeutuneet eikä koneen sisällöstä tarvitse ohjelmoijan tietää enää mitään.
Kertoisitko sinä nyt vuorostaan perustelusi siihen, miksi meidän tulisi syventyä konekieleen?
ne nykyisetkin ohjelmointikielet toimivat, niin teidän tulee tietää miten ne kääntävät kaiken mömmön KONEKIELELLE.
; 284 : != ios_base::left)
000c0 8b 45 08 mov eax, DWORD PTR __O$[ebp]
000c3 8b 08 mov ecx, DWORD PTR [eax]
000c5 8b 55 08 mov edx, DWORD PTR __O$[ebp]
000c8 03 51 04 add edx, DWORD PTR [ecx 4]
000cb 8b ca mov ecx, edx
000cd e8 00 00 00 00 call ?flags@ios_base@std@@QBEHXZ ; std::ios_base::flags
000d2 25 c0 01 00 00 and eax, 448 ; 000001c0H
000d7 83 f8 40 cmp eax, 64 ; 00000040H
000da 74 6c je SHORT $L16672
; 285 : for (; 0 < _M; --_M)
000dc eb 09 jmp SHORT $L16673
$L16674:
000de 8b 45 e0 mov eax, DWORD PTR __M$[ebp]
000e1 83 e8 01 sub eax, 1
000e4 89 45 e0 mov DWORD PTR __M$[ebp], eax
$L16673:
000e7 83 7d e0 00 cmp DWORD PTR __M$[ebp], 0
000eb 76 5b jbe SHORT $L16675
; 287 : _O.rdbuf()->sputc(_O.fill())))
000ed 8b 4d 08 mov ecx, DWORD PTR __O$[ebp]
000f0 8b 11 mov edx, DWORD PTR [ecx]
000f2 8b 4d 08 mov ecx, DWORD PTR __O$[ebp]
000f5 03 4a 04 add ecx, DWORD PTR [edx 4]
000f8 e8 00 00 00 00 call ?fill@?$basic_ios@DU?$char_traits@D@std@@@std@@QBEDXZ ; std::basic_ios::fill
000fd 50 push eax
000fe 8b 45 08 mov eax, DWORD PTR __O$[ebp]
00101 8b 08 mov ecx, DWORD PTR [eax]
00103 8b 55 08 mov edx, DWORD PTR __O$[ebp]
00106 03 51 04 add edx, DWORD PTR [ecx 4]
00109 8b ca mov ecx, edx
0010b e8 00 00 00 00 call ?rdbuf@?$basic_ios@DU?$char_traits@D@std@@@std@@QBEPAV?$basic_streambuf@DU?$char_traits@D@std@@@2@XZ ; std::basic_ios::rdbuf
00110 8b c8 mov ecx, eax
00112 e8 00 00 00 00 call ?sputc@?$basic_streambuf@DU?$char_traits@D@std@@@std@@QAEHD@Z ; std::basic_streambuf::sputc
00117 89 45 d8 mov DWORD PTR $T17961[ebp], eax
0011a e8 00 00 00 00 call ?eof@?$char_traits@D@std@@SAHXZ ; std::char_traits::eof
0011f 89 45 d4 mov DWORD PTR $T17962[ebp], eax
00122 8d 45 d8 lea eax, DWORD PTR $T17961[ebp]
00125 50 push eax
00126 8d 4d d4 lea ecx, DWORD PTR $T17962[ebp]
00129 51 push ecx
0012a e8 00 00 00 00 call ?eq_int_type@?$char_traits@D@std@@SA_NABH0@Z ; std::char_traits::eq_int_type
0012f 83 c4 08 add esp, 8
00132 25 ff 00 00 00 and eax, 255 ; 000000ffH
00137 85 c0 test eax, eax
00139 74 0b je SHORT $L16678
; 288 : {_St |= ios_base::badbit;
0013b 8b 55 ec mov edx, DWORD PTR __St$[ebp]
0013e 83 ca 04 or edx, 4
00141 89 55 ec mov DWORD PTR __St$[ebp], edx
; 289 : break; }
00144 eb 02 jmp SHORT $L16675
$L16678:
; 290 : if (_St == ios_base::goodbit
00146 eb 96 jmp SHORT $L16674
$L16675:
$L16672:
; 291 : && _O.rdbuf()->sputn(_X, _N) != _N)
00148 83 7d ec 00 cmp DWORD PTR __St$[ebp], 0
0014c 75 2d jne SHORT $L16679
0014e 8b 45 dc mov eax, DWORD PTR __N$[ebp]
00151 50 push eax
00152 8b 4d 0c mov ecx, DWORD PTR __X$[ebp]
00155 51 push ecx
00156 8b 55 08 mov edx, DWORD PTR __O$[ebp]
00159 8b 02 mov eax, DWORD PTR [edx]
0015b 8b 4d 08 mov ecx, DWORD PTR __O$[ebp]
0015e 03 48 04 add ecx, DWORD PTR [eax 4]
00161 e8 00 00 00 00 call ?rdbuf@?$basic_ios@DU?$char_traits@D@std@@@std@@QBEPAV?$basic_streambuf@DU?$char_traits@D@std@@@2@XZ ; std::basic_ios::rdbuf
00166 8b c8 mov ecx, eax
00168 e8 00 00 00 00 call ?sputn@?$basic_streambuf@DU?$char_traits@D@std@@@std@@QAEHPBDH@Z ; std::basic_streambuf::sputn
0016d 3b 45 dc cmp eax, DWORD PTR __N$[ebp]
00170 74 09 je SHORT $L16679
; 292 : _St |= ios_base::badbit;
00172 8b 4d ec mov ecx, DWORD PTR __St$[ebp]
00175 83 c9 04 or ecx, 4
00178 89 4d ec mov DWORD PTR __St$[ebp], ecx
$L16679:
; 293 : if (_St == ios_base::goodbit)
0017b 83 7d ec 00 cmp DWORD PTR __St$[ebp], 0
0017f 75 6e jne SHORT $L16680
; 294 : for (; 0 < _M; --_M)
00181 eb 09 jmp SHORT $L16681
$L16682:
00183 8b 55 e0 mov edx, DWORD PTR __M$[ebp]
00186 83 ea 01 sub edx, 1
00189 89 55 e0 mov DWORD PTR __M$[ebp], edx
$L16681:
0018c 83 7d e0 00 cmp DWORD PTR __M$[ebp], 0
00190 76 5d jbe SHORT $L16683
; 296 : _O.rdbuf()->sputc(_O.fill())))
00192 8b 45 08 mov eax, DWORD PTR __O$[ebp]
00195 8b 08 mov ecx, DWORD PTR [eax]
00197 8b 55 08 mov edx, DWORD PTR __O$[ebp]
0019a 03 51 04 add edx, DWORD PTR [ecx 4]
0019d 8b ca mov ecx, edx
0019f e8 00 00 00 00 call ?fill@?$basic_ios@DU?$char_traits@D@std@@@std@@QBEDXZ ; std::basic_ios::fill
001a4 50 push eax
001a5 8b 45 08 mov eax, DWORD PTR __O$[ebp]
001a8 8b 08 mov ecx, DWORD PTR [eax]
001aa 8b 55 08 mov edx, DWORD PTR __O$[ebp]
001ad 03 51 04 add edx, DWORD PTR [ecx 4]
001b0 8b ca mov ecx, edx
001b2 e8 00 00 00 00 call ?rdbuf@?$basic_ios@DU?$char_traits@D@std@@@std@@QBEPAV?$basic_streambuf@DU?$char_traits@D@std@@@2@XZ ; std::basic_ios::rdbuf
001b7 8b c8 mov ecx, eax
001b9 e8 00 00 00 00 call ?sputc@?$basic_streambuf@DU?$char_traits@D@std@@@std@@QAEHD@Z ; std::basic_streambuf::sputc
001be 89 45 d0 mov DWORD PTR $T17963[ebp], eax
001c1 e8 00 00 00 00 call ?eof@?$char_traits@D@std@@SAHXZ ; std::char_traits::eof
001c6 89 45 cc mov DWORD PTR $T17964[ebp], eax
001c9 8d 45 d0 lea eax, DWORD PTR $T17963[ebp]
001cc 50 push eax
001cd 8d 4d cc lea ecx, DWORD PTR $T17964[ebp]
001d0 51 push ecx
001d1 e8 00 00 00 00 call ?eq_int_type@?$char_traits@D@std@@SA_NABH0@Z ; std::char_traits::eq_int_type
001d6 83 c4 08 add esp, 8
001d9 25 ff 00 00 00 and eax, 255 ; 000000ffH
001de 85 c0 test eax, eax
001e0 74 0b je SHORT $L16686
; 297 : {_St |= ios_base::badbit;
001e2 8b 55 ec mov edx, DWORD PTR __St$[ebp]
001e5 83 ca 04 or edx, 4
001e8 89 55 ec mov DWORD PTR __St$[ebp], edx
; 298 : break; }
001eb eb 02 jmp SHORT $L16683
$L16686:
; 299 : _O.width(0);
001ed eb 94 jmp SHORT $L16682
$L16683:
$L16680:
001ef 6a 00 push 0
001f1 8b 45 08 mov eax, DWORD PTR __O$[ebp]
001f4 8b 08 mov ecx, DWORD PTR [eax]
001f6 8b 55 08 mov edx, DWORD PTR __O$[ebp]
001f9 03 51 04 add edx, DWORD PTR [ecx 4]
001fc 8b ca mov ecx, edx
001fe e8 00 00 00 00 call ?width@ios_base@std@@QAEHH@Z ; std::ios_base::width
; 300 : _CATCH_IO_(_O) }
00203 eb 1c jmp SHORT $L17966
$L17967:
00205 6a 01 push 1
00207 6a 04 push 4
00209 8b 45 08 mov eax, DWORD PTR __O$[ebp]
0020c 8b 08 mov ecx, DWORD PTR [eax]
0020e 8b 55 08 mov edx, DWORD PTR __O$[ebp]
00211 03 51 04 add edx, DWORD PTR [ecx 4]
00214 8b ca mov ecx, edx
00216 e8 00 00 00 00 call ?setstate@?$basic_ios@DU?$char_traits@D@std@@@std@@QAEXH_N@Z ; std::basic_ios::setstate
0021b b8 00 00 00 00 mov eax, $L16671
00220 c3 ret 0
$L16671:
$L17966:
00221 c7 45 fc 00 00
00 00 mov DWORD PTR __$EHRec$[ebp 12], 0
$L16670:
; 301 : _O.setstate(_St);
00228 6a 00 push 0
0022a 8b 45 ec mov eax, DWORD PTR __St$[ebp]
0022d 50 push eax
0022e 8b 4d 08 mov ecx, DWORD PTR __O$[ebp]
00231 8b 11 mov edx, DWORD PTR [ecx]
00233 8b 4d 08 mov ecx, DWORD PTR __O$[ebp]
00236 03 4a 04 add ecx, DWORD PTR [edx 4]
00239 e8 00 00 00 00 call ?setstate@?$basic_ios@DU?$char_traits@D@std@@@std@@QAEXH_N@Z ; std::basic_ios::setstate
; 302 : return (_O); }
0023e 8b 45 08 mov eax, DWORD PTR __O$[ebp]
00241 89 45 c8 mov DWORD PTR $T17965[ebp], eax
00244 c7 45 fc ff ff
ff ff mov DWORD PTR __$EHRec$[ebp 12], -1
0024b 8d 4d e4 lea ecx, DWORD PTR __Ok$[ebp]
0024e e8 00 00 00 00 call ??1sentry@?$basic_ostream@DU?$char_traits@D@std@@@std@@QAE@XZ ; std::basic_ostream::sentry::~sentry
00253 8b 45 c8 mov eax, DWORD PTR $T17965[ebp]
00256 8b 4d f4 mov ecx, DWORD PTR __$EHRec$[ebp 4]
00259 64 89 0d 00 00
00 00 mov DWORD PTR fs:__except_list, ecx
00260 5f pop edi
00261 5e pop esi
00262 5b pop ebx
00263 8b e5 mov esp, ebp
00265 5d pop ebp
00266 c3 ret 0
_TEXT ENDS
; COMDAT text$x
text$x SEGMENT
omaa sisäistä hierarkiaa ja niihin ei taida päästä käsiksi edes konekielellä.
:)
Minä tiedän miten ohjelmointikieli toimii. Kun siinä on Form.Print "abc"
niin ruutuun tulostuu abc. Miksi pitäisi sen tarkemmin tietää?
Televisiostakin minulle riittää että siihen tulee kuva ilman tietoa miten se ilman kautta välittyy.
Kun olen joutunut aikaisemmin puuttumaan koneenläheisiin hommiin ohjelmoinnissa, niin nyt kun ei tarvitse niin se on hyvä.
Kato ku nykyään ohjelmointikielet ja käyttöjärjestelmän ovat avittaneet ohjelmoijia suuresti, eikä tarvitse biteistä tietää. Koneet on nopeita ja niissä on riittävästi muistia ja tiedonsiirtokin toimii vinhasti. Joten en halua enää edes muistella niitä aikoja kun oli juhlaa saada 1200 baudin modeemi 300 baudisen tilalle.
Jokainen ohjelmoija tajuaa tuon. Kysy vaikka jos tunnet jonkun tietokoneohjelmoijan.
Niin se käsittääkseni on.
Onneksi koneet ovat nykyään niin hyviä ettei tarvitse välittää kuin oman ohjelman toiminnasta.
Nopeutta ja muistikapasiteettia riittää tuhlattavaksi asti, joten sikäli ohjelmointi on helpottunut.
Netistä löytää ohjeita vaikka mihin.
On tää helppoa nykyään.
http://keskustelu.suomi24.fi/show.fcgi?category=108&conference=4500000000000140&posting=22000000025629710
.. olla varma mitä helvettiä te esitätte?
:D
Minulle konekieli on itsestään selvyys ja se on pohjana muittenkin kielien ymmärtämiselle.
Rivibasic'istä 70 luvun lopulta DeSmetin C'stä nykyisiin C vääntimiin - tiukasti sulautetut mukana.
Visionääri-petteri: -"C-kieli? Eihän sillä voi edes merkkijonoja käsitellä"
Päivätty: 29.07.1999
void main(int argc, char *argv[], char *envp[])
{
DeCode();
/*
char char8;
int luku = 0x0123, c_bit;
// kelataan käsiteltävän datan alkuun...
for(int start = 0; start < 44; start )
{
fin.get(char8);
fout
void gray_plot(double r, double kulma, unsigned int luku)
{
unsigned int c_bit, digit;
static int pos = 0;
double aste, X, Y;
aste = (double)RAD(kulma);
X = (double) (r * sin((double)aste));
Y = (double) (r * cos((double)aste));
digit = 0;
/* Seuraavassa sotkussa on tarkoitus saada vähiten merkitsevät
bitit ulkokehälle ja eniten merkitsevät sisäkehälle.
*/
for(int i = 13; i >= 0; i--)
{
/* C-kielessä ei ole suoraa mahdollisuutta CARRY-bitin
testaamiseen, joten koko tavun oikealle siirto tehdään
tässä assembly-kielisellä pätkällä....
*/
__asm
{
ror luku, 1
jc carry
mov c_bit, 0
jmp ulos
carry: mov c_bit, 1
ulos:
}
pt[i].x = X * i;
pt[i].y = Y * i;
pt[i].z = c_bit;
}
// SCREEN:
_moveto(ScreenXoffset, ScreenYoffset);
for(int j = 0; j
Kääntäjä pyrkii järjestelemään käskyt niin, että käskyjä suoriutuisi mahdollisimman paljon kullakin kellonlyömällä, jollei käytössä ole debug -tyyppinen käännös. Lopputulos riippuukin sitten paljon millä kääntäjällä käännöksen tekee.
Nykyiset kääntäjät osaavat melko hyvin ennustaa mitkä käskyt suoriutuvat kerralla kunhan kohde suoritin on tiedossa. Esim. IntelC :n listauksessa nuo ovat näkösällä.
sellaisesta käännöksestä - ilman debuggaus-hiluja, niin eivät ole sotkemassa.
:)
Konekieli on prosessorikohtainen, joten jos teen ohjelman toimimaan windowsilla, niin pitäisikö minun siis tietää mitä konekielen käskyjä mikäkin prosessori ohjelmaani suorittaessa käyttää?
En minä mitään esitä. Olen tehnyt 20 vuotta työkseni tietokoneohjelmia ja nähnyt ohjelmoinnin kehityksen. Siksi tiedän ettei kukaan tietokoneohjelmia työkseen tekevä halua pahemmin rasittaa päätään sillä miten prosessori konekielellä ohjelman suorittaa, sillä ei siitä ohjelman teon kannalta ole hyötyä.
Jos pitäisi tajuta miten konekieli asian hoitaa, niin sittenhän pitäisi myös selvittää miten käyttöjärjestelmä asiat hoitaa.
Sanoit konekielen olevan sinulle itsestään selvyys. Tarkoitatko että osaat kaikkien nykyisten prosessorien konekielen ulkoa? Vai mitä sinulle konekielestä on itsestään selvää?
Jos sinä tekisit työksesi tietokoneohjelmia, niin ymmärtäisit väitteisi triviaalisuuden ja typeryyden.
Ihan miten vaan.
Nysvännyt perforoitujen IBM-korttien kanssa jo kuuskytluvulta aina ensimmäisen omakutoisen Telmac'in kautta (70-lukua) ensimmäisen 'yhteensopivan' PC'n kautta tänne (maksoi n. 50000 markaa 80 luvun alkuvuosina).
Ohjelmaa olen vääntänyt ja oheiselektroniikaa suunnitellut - niin alusta loppuun kuin PC' ISA jne väylään. Senkin väylän osaan ulkoa.
Haluatteko selvittää 'ohjelmoijana' miten DMA toimii käytännössä?
Osaan periaatteen ulkoa joten on helppoa siirtyä kielestä toiseen - kokeillut eksoottisiakin kieliä vain siksi että tulivat markkinoille - kuten LISP ja PROLOG - eikä ole estettä sellaisen tekemiseenkään - kuten huomaatte tai arvaatte joku ohjelmoija niitäkin on tehnyt - tietäisi vaan määrän?
Kolmannen kaupallisen PC'n mukana sain täydellisen teknisen käsikirjan kytkentäkaavioineen ja BIOS-listauksineen - ilmaiseksi? _Ei - pumaska piti ostaa erikseen ja maksoi tasan tuhannen markkaa. BIOS-listaus oli täydellinen aina kommentoimista myöten. Saatko tänään - rahalla?
Taidan painia eri sarjassa kuin te ja tuntemanne 'ohjelmoijat'?
:D
Keiden aervelette ohjelmoivan käyttöjärjestelmät ja ohjaimet? Molempaa olen tehnyt. Te?
:D
mukana suomessa ottamassa käyttöön C-kieltä - miksi? Siksi, että se oli lähellä KONEKIELTÄ.
Löyty netistäkin käsikirjaa ja levykettä - omani ovat varastossa:
http://www.desmet-c.com/ver_303.shtml
Tuon jälkeen siirryin Microsoftin puolelle ja aina ostoksen ohessa tuli lähes metrinen pino käsikirjallisuutta ja kielen dokumentaatiota.
"Taidan painia eri sarjassa kuin te ja tuntemanne 'ohjelmoijat'?"
Totta, sillä sinä painit dinosaurusten kanssa.
"Keiden aervelette ohjelmoivan käyttöjärjestelmät ja ohjaimet? Molempaa olen tehnyt."
Toki noita nykyäänkin tehdään, mutta windows-käyttöjärjestelmät ovat niin käteviä, ettei itse tarvitse niihin puuttua. Samoin laiteohjaimet tulevat laitteiden mukana valmiina.
Itse pidän sovellusohjelmien koodauksesta enkä halua enää puuttua bittitasolle. Jos sinä pidät nautittavana konekielikoodausta, niin siitä vaan.
Ts. Teette ohjelmakehittimillä ohjelmaa ja kutsutte itseänne ohjelmoijaksi.
:D
Jos teen Visual Basicilla ohjelmia, niin miten niin en ole ohjelmoija?
Miksi heität vain yleisiä väitteitä joita nettikeskustelut ovat täynnä, etkä perustele väitteitäsi?
http://keskustelu.suomi24.fi/show.fcgi?category=108&conference=4500000000000140&posting=22000000025629710
http://keskustelu.suomi24.fi/show.fcgi?category=108&conference=4500000000000140&posting=22000000025671031
http://keskustelu.suomi24.fi/show.fcgi?category=108&conference=4500000000000140&posting=22000000025632197
ohjelmoijat ovat teille valmiiksi tehneet - osaatte lähinnä siirtää valmiita palikoita ja kasata niitä.
Paljon havainnollisempi on VTunen aikaansaannokset, josta esimerkki:
source clockticks,instructions
prev_length = match_length, prev_match = match... 369,535
mov edi,dword[0134a54h] 15,7
shl edx,5 10,13
xor edx,eax 0,1
xor eax,eax 23,29
and esi,07fffh 10,5
mov dword [04147f0h],edx -,-
mov ax,word[edx*2 04348ah] 21,35
mov word[esi*2 04248c0h],ax 260,361
mov esi,ebp 30,43
eihän tällä ole juurikaan tekemistä sen kanssa miten funktioita kutsutaan (stdcall, thiscall, fastcall, cdecl) - saati sitten globaalien muuttujien kanssa. Teksti on lisäksi 90 -luvun alusta eikä kaikki sovellu nykyisiin koneisiin.
Minä käytän vain tätä xxxxx nimimerkkiä, joten muut kirjoitukset eivät ole minun.
Ohjelmointihan on palikoiden siirtoa. Prosessorintekijät rakentavat prosessorinsa transistoripalikoista.
Sinä kokoat konekieliohjelman prosessorintekijöiden konekielipalikoista. Ja todennäköisesti käytät siihen jotain helpottavaa apuvälinettä etkä koodaa suoraan debuggerilla.
Minä teen sitten ohjelmat vb-ohjelmointikielen sisältämistä palikoista. Oma koodaus on sitten sitä mitä ei varsinaisesti ole palikoina. Peruslaskenta (a=a 1) vissiin kääntyy samalla tavalla kuin jos tekisi suoraan konekielellä. Ylemmän tason ohjelmointikielet, kuten Visual Basic, ovat suunniteltu helpottamaan ohjelmoijien työtä. Ja tietysti fiksu tyyppi hoitaa hommat mahdollisimman helposti.
Eli ohjelmointi on palikoiden kasaamista. Isaac Newton taisi olla se, joka sanoi seisovansa jättiläisen harteilla. Kuten me kaikki seisomme. Itse teemme vain pienen osan työstämme ja suurin osa perustuu muiden aikaisemmin tekemään työhön.
Triviaaliahan tämä keskustelu globaalien muuttujien vaikutuksesta on.
En minä tällä varsinaisesti mihinkään tähtää.
Käsittelin vain aihetta, jossa mietittiin ohjelman nopeutta.
Funktioiden kutsussa käytettäessä globaalimuuttujaa jää yksi sijoituskäsky pois kun aliohjelman ei täydy varata sille omaa muistipaikkaa ja siirtää arvo ensin siihen. Tätähän alkuperäinen aihe koski, joten sitä käsittelin. Mitään käytännön vaikutusta nopeuteen ei ole, mutta globaalimuuttujien käyttö on käsittääkseni aina nopeampaa.
Jos joku tekee jollakin kielellä esimerkin ettei noin ole, niin minä voin sitten tehdä saman testin VB6:lla.
No vb6 ei ole kovin hyvä vertailtava, kun se ei tuota listausta prosessorin käskyistä, mutta C:llä esimerkiksi:
void __fastcall foo(int);
void __stdcall foo(int);
void __cdecl foo(int);
void __thiscall foo(int);
tuovat erilaisen tuloksen. fastcall ja thiscall antavat parametrit rekisterissä kun taas muut pinossa (X86/X64). Jos parametreja jakelee rekisterin kautta, ei minkäännäköistä kirjoittelua tarvita.
Jos vilkailit sitä linkkiä:
http://www.agner.org/optimize/optimizing_cpp.pdf
niin siinähän se oli kohdassa 6.1 sanottu. Et vain pysty sitä tekemään vb:llä.
Kyllä minä pystyn väitteeni perustelemaan.
Sanoin että globaalit muuttujat ovat nopeampia käsitellä funktiossa kuin että funktio käyttää paikallisia muuttujia. Ei se haittaa että VB:llä ei saa listaa käännetystä konekielikoodista. Puhe oli vain nopeudesta ja sen voi testata tekemällä testiohjelman, jossa suoritetaan aliohjelma molemmilla tavoilla ja otetaan molemmista tavoista aika.
Tuollaisen testiohjelman voi tehdä.
Tuollaisen testiohjelman teinkin.
Tein testiohjelman VB 2005:llä. Formiin luodaan Button1 ja TextBox1. Buttonin painalluksella suoritetaan sama aliohjelma globaalilla muuttujalla ja paikallisella (=aliohjelman tekemällä).
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
Dim Alkuaika As Double
Dim Ero1 As Double, Ero2 As Double
Dim ProsEro As Double
Dim i As Integer, j As Integer, k As Integer
Const LuuppiLkm = 1000000000'aikaeron selvittämiseksi tehdään kutsu miljardi kertaa
'muuttujan arvolla
Alkuaika = Microsoft.VisualBasic.DateAndTime.Timer
For i = 1 To LuuppiLkm
j = 0
Call Testi1(j)
Next
Ero1 = Microsoft.VisualBasic.DateAndTime.Timer - Alkuaika
TextBox1.Text = TextBox1.Text + "Ero1=" & Ero1 & Chr(13) & Chr(10)
'globaalilla muuttujalla
Alkuaika = Microsoft.VisualBasic.DateAndTime.Timer
For i = 1 To LuuppiLkm
j = 0
k = Testi2(j)
Next
Ero2 = Microsoft.VisualBasic.DateAndTime.Timer - Alkuaika
TextBox1.Text = TextBox1.Text & "Ero2=" & Ero2 & Chr(13) & Chr(10)
ProsEro = CDbl(100.0# * (CDbl(Ero2) / CDbl(Ero1)))
TextBox1.Text = TextBox1.Text & "Globaalitapa on " & ProsEro & " %:a paikallisen muuttujan käsittelystä" & Chr(13) & Chr(10)
End Sub
Public Function Testi1(ByVal A As Integer) As Integer
A = A + 1
Testi1 = A
End Function
Public Function Testi2(ByRef A As Integer) As Integer
A = A + 1
Testi2 = A
End Function
Ajoin testin ohjelmointitilassa ja käännettynä 3 kertaa.
VB 2005:n ohjelmointitilassa ajo:
Ero1=11,5
Ero2=12,984375
Globaalitapa on 112,907608695652 %:a paikallisen muuttujan käsittelystä
Ero1=11,484375
Ero2=12,46875
Globaalitapa on 108,571428571429 %:a paikallisen muuttujan käsittelystä
Ero1=11,5
Ero2=12,46875
Globaalitapa on 108,423913043478 %:a paikallisen muuttujan käsittelystä
=> Eli ohjelmointitilassa se on hitaampaa, mutta sehän on testausta varten. Joten exe-vaihtoehto alla kertoo totuuden.
Ja käännettynä exenä:
Ero1=7,484375
Ero2=2,5
Globaalitapa on 33,4029227557411 %:a paikallisen muuttujan käsittelystä
Ero1=7,5
Ero2=2,484375
Globaalitapa on 33,125 %:a paikallisen muuttujan käsittelystä
Ero1=7,5
Ero2=2,5
Globaalitapa on 33,3333333333333 %:a paikallisen muuttujan käsittelystä
=> Eli käännetyssä ohjelmassa ero on huomattava; globaali käsittely vie vain kolmasosan ajasta verrattuna paikalliseen muuttujaan.
Vastaväitteitä saa esittää, mutta ne pitää sitten perustella. Minä olen pannut koodia kehiin todistukseksi, joten siitä vaan vastaanväittäjät: perustelkaa kantanne tai vaietkaa.
Tiedättekö miten tietokone toimii?
Niin sinne laitetaan sisään kortti ja jotenkin se tulee reitettynä sieltä ulos - vai olikohan tuo tulostin
Eronahan noilla oli:
Call Testi1(j)
k = Testi2(j)
eli ensimmäisessä ei oteta lopputulosta talteen ja toisessa se talletetaan muuttujaan k. VB6:n ajoilta tuo vb on muuttunut sen verran, että muuttujan määrittäminen globaaliksi on hyvin vaikeaa: http://msdn2.microsoft.com/en-us/library/aa289529(VS.71).aspx
(sivun puolessa välissä kohta "Global data in .NET")
Tuossa koodissasi ei ole siis globaaleja muuttujia.
osoittimista?
tää taitaa olla muuten C palsta?
Kiitos tarkkaavaisuudesta. Tuo koodivirhe oli mokani, mutta se ei näköjään vaikuta suoritusaikaan. Globaaleilla muuttujilla tarkoitin ettei niitä tarvitse aliohjelman luoda. VB 6:ssa globaaleja muuttujia ovat toki vain ne jotka luodaan Global-määritteellä. Sen tiesin, mutta nyt olen vasta opettelemassa VB 2005:ttä. Eiköhän se tästä :)
Paransin ohjelmaani ja lisäsin kolmannen tavan, jossa aliohjelmaa ei käytetä ollenkaan.
Tässä ajat VB:n editointitilassa (ajoin testin 3 kertaa):
Aliohjelman muuttujilla 13,46875 sekuntia
Globaalitapa 23,125 sekuntia on 171,69373549884 %:a paikallisen muuttujan käsittelystä
Globaalitapa ja koodi pääohjelmassa (ilman aliohjelmakutsua) 4,484375 sekuntia 33,2946635730858 %:a paikallisen muuttujan käsittelystä
Aliohjelman muuttujilla 13,46875 sekuntia
Globaalitapa 22,84375 sekuntia on 169,605568445476 %:a paikallisen muuttujan käsittelystä
Globaalitapa ja koodi pääohjelmassa (ilman aliohjelmakutsua) 4,5 sekuntia 33,4106728538283 %:a paikallisen muuttujan käsittelystä
Aliohjelman muuttujilla 13,46875 sekuntia
Globaalitapa 23,3125 sekuntia on 173,085846867749 %:a paikallisen muuttujan käsittelystä
Globaalitapa ja koodi pääohjelmassa (ilman aliohjelmakutsua) 4,484375 sekuntia 33,2946635730858 %:a paikallisen muuttujan käsittelystä
Ja tässä käännettynä:
Aliohjelman muuttujilla 7,484375 sekuntia
Globaalitapa 2,5 sekuntia on 33,4029227557411 %:a paikallisen muuttujan käsittelystä
Globaalitapa ja koodi pääohjelmassa (ilman aliohjelmakutsua) 2,03125 sekuntia 27,1398747390397 %:a paikallisen muuttujan käsittelystä
Aliohjelman muuttujilla 7,484375 sekuntia
Globaalitapa 2,5 sekuntia on 33,4029227557411 %:a paikallisen muuttujan käsittelystä
Globaalitapa ja koodi pääohjelmassa (ilman aliohjelmakutsua) 2,015625 sekuntia 26,9311064718163 %:a paikallisen muuttujan käsittelystä
Aliohjelman muuttujilla 7,46875 sekuntia
Globaalitapa 2,5 sekuntia on 33,4728033472803 %:a paikallisen muuttujan käsittelystä
Globaalitapa ja koodi pääohjelmassa (ilman aliohjelmakutsua) 2,03125 sekuntia 27,1966527196653 %:a paikallisen muuttujan käsittelystä
Erot ovat selkeät. Jos ohjelmaan haluaa nopeutta, niin aliohjelmat eivät käytä omia muuttujiaan. Lisää nopeutta saa kun aliohjelmat sijoittaa pääohjelmaan. Mutta kuten olen aikasemmin sanonut, niin ohjelmoinnissa on ohjelmoijan itsensä kannalta tärkeää tehdä helposti ylläpidettävää koodia. Kätevimmin sen saa selkeillä mokkuloilla. Vai mitä olioita ne onkaan :)
Tässä uusi ohjelmaversio (lisää Formille Button1 ja Text1):
Public Class NopeustestiForm
Public Function Testi1(ByVal A As Integer) As Integer
A = A + 1
Testi1 = A
End Function
Public Function Testi2(ByRef A As Integer) As Integer
A = A + 1
Testi2 = A
End Function
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
Dim Alkuaika As Double
Dim Ero1 As Double, Ero2 As Double, Ero3 As Double
Dim ProsEro As Double
Dim i As Integer, j As Integer, k As Integer
Const LuuppiLkm = 1000000000
'muuttujan arvolla
Alkuaika = Microsoft.VisualBasic.DateAndTime.Timer
For i = 1 To LuuppiLkm
j = 0
k = Testi1(j)
Next
Ero1 = Microsoft.VisualBasic.DateAndTime.Timer - Alkuaika
TextBox1.Text = TextBox1.Text + "Aliohjelman muuttujilla " & Ero1 & " sekuntia" & Chr(13) & Chr(10)
TextBox1.Refresh()
'globaalilla muuttujalla
Alkuaika = Microsoft.VisualBasic.DateAndTime.Timer
For i = 1 To LuuppiLkm
j = 0
k = Testi2(j)
Next
Ero2 = Microsoft.VisualBasic.DateAndTime.Timer - Alkuaika
ProsEro = CDbl(100.0# * (CDbl(Ero2) / CDbl(Ero1)))
TextBox1.Text = TextBox1.Text & "Globaalitapa " & Ero2 & " sekuntia on " & ProsEro & " %:a paikallisen muuttujan käsittelystä" & Chr(13) & Chr(10)
TextBox1.Refresh()
'globaalilla muuttujalla ilman aliohjelmakutsua
Alkuaika = Microsoft.VisualBasic.DateAndTime.Timer
For i = 1 To LuuppiLkm
j = 0
j = j + 1
k = j
Next
Ero3 = Microsoft.VisualBasic.DateAndTime.Timer - Alkuaika
ProsEro = CDbl(100.0# * (CDbl(Ero3) / CDbl(Ero1)))
TextBox1.Text = TextBox1.Text & "Globaalitapa ja koodi pääohjelmassa (ilman aliohjelmakutsua) " & Ero3 & " sekuntia " & ProsEro & " %:a paikallisen muuttujan käsittelystä" & Chr(13) & Chr(10)
TextBox1.Text = TextBox1.Text & Chr(13) & Chr(10)
End Sub
End Class
Voisitko sinä kirjoittaa tuollaisen vertailun C- tai C#-kielellä. C:llä kirjoitettaessa voit käyttää haluamiasi pointtereita.
Panisitko käytännössä käyttämäsi esimerkkikoodin C-kielisestä koodistasi, jossa olet käyttänyt pointtereita. Olen sitä tällä palstalla aina aikaisemminkin kysynyt kun joku inisee pointtereista, mutta ensimmäistäkään oikeassa ohjelmassa käyttävää pointterikoodia ei ole näkynyt.
katellaan sitä tuossa illemmalla kunhan nää työt loppuupi. laitanpåa sitten vaikka jotain.
Olio-ohjelmoinnissa puhutaan jäsenmuuttujista, kun muuttuja sijaitsee luokan sisällä ;)
Tässä mun kyhäelmä aiheesta. Käytin seuraavanlaisia funktioita:
static unsigned eka,toka;
static unsigned Globaali(void)
{
return eka toka;
}
static unsigned Pino(unsigned eka, unsigned toka)
{
return eka toka;
}
static unsigned __fastcall Rekisteri(unsigned eka, unsigned toka)
{
return eka toka;
}
static void Tyhja(void)
{
}
Tuloksiksi sain kahdella muuttujalla:
- rekisteri noin 0 uops
- pino 2 uops
- globaali 2 - 170 uops (useammin noin 170)
Ensimmäinen suoritus globaalilla on noin 5000 uops.
Tuosta voi sitten päätellä kuinka monta tallennusta tarvitaan ennen kuin ajalla on jonkinlaista merkitystä (uops jaetaan siis kellotaajuudella).
"Panisitko käytännössä käyttämäsi esimerkkikoodin C-kielisestä koodistasi, jossa olet käyttänyt pointtereita. Olen sitä tällä palstalla aina aikaisemminkin kysynyt kun joku inisee pointtereista, mutta ensimmäistäkään oikeassa ohjelmassa käyttävää pointterikoodia ei ole näkynyt. "
en ala mitään vertailuja väsäämään kun en oikein tällähetkellä ehdi mutta tässäpä pointteria:
int main()
{
char* merkkijono1=("Paljon tekstiä?"); //ptr?
char* merkkijono2=("vähän tekstiä?");
printf(merkkijono1);
printf(merkkijono2);
//char* on osoitin(pointer) merkkijonon alkuun
//ja aikamoni? ohjelma käyttää jonkinlaisia
//merkkijonoja ;D
return 0;
}
Minä pyysin jotain käytännön esimerkkiä jota olet käyttänyt toimitetussa ohjelmassasi. Sellaista missä pointtereiden käytöstä on hyötyä: sama olisi vaikea tai suoritus hidas perinteisellä tavalla (siis ilman pointtereita).
Eli lyhyt ohjelmapätkä jostain vanhasta ohjelmastasi. Kai sinulla niitä on satoja, kun pointtereita kerran hehkutat?
jotain... (sorsat on cd:illä "jossain" mutta eiköhän ne löydy)
ei ole satoja ohjelmia ei... useita kuitenkin..
elämää? Ottakaapa assembly-listaus visualbasic-viritelmästänne ja katsokaa käytetäänkö siellä pointtereita? Esim. SP, BP, ..
jospa tää nyt tällä avautuis näin pikaisen etsinnän jälkeen:
-en pastea koko sorsaa tänne kun se on aika "iso" kooltaan..
eli:
//taa_on_dll.cpp
//OSA-siitä
/////////////////////////////
__declspec(dllexport) bool KeyOff(void)
{
if (hHook)
if (UnhookWindowsHookEx(hHook)) hHook = NULL;
return (!hHook);
};
__declspec(dllexport) bool KeyOn(void)
{
if (hHook) KeyOff();
hHook = SetWindowsHookEx(
WH_KEYBOARD,
(HOOKPROC)KeyboardProc,
(HINSTANCE)hInstance,
0
);
return (hHook != NULL);
};
/////////////////////////////////////////////////
//tämä on osa exe.h
/////////////////////////////////////////////////
#include
typedef bool (*LPKEYOFF)(void);
typedef bool (*LPKEYON)(void);
typedef bool (*LPLOADSET)(bool);
typedef void (*LPSETHWND)(HWND);
////////////////////////////////////////////////
tartteeko selittää tuota pointterien hyödyllisyyttä?
http://www.csee.umbc.edu/~plusquel/310/slides/micro_arch1.html
//main_exe.cpp
///////////////
//lisää...
//
LPKEYON KeyOn;
LPKEYOFF KeyOff;
////////////////
//lisää koodia
///////////////
//....
//////////////////
//ladataan funktiot
KeyOn = (LPKEYON)GetProcAddress(h_key,"KeyOn");
KeyOff = (LPKEYOFF)GetProcAddress(h_key,"KeyOff");
http://doc.ddart.net/asm/Microsoft_MASM_Programmers_Guide_v6.1/Chap_12.htm
sp ja bp kuuluivat 80 -luvulle ja 90 -luvun alkuun. Ei niitä nykyisistä vb:stä löydy.
Mutta sellaisia assembly -listauksia ei vb:n windows puolelta löydy, jossa noita pointtereita ei olisi hyödynnetty.
Nuo on juuri sellaisia sivuja, joihin ei koskaan pitäisi antaa linkkejä. Sivut eivät kerro mitä suoritinta tiedot koskevat.
Käyttäkää siis aina joko linkkejä valmistajan oppaisiin tai sellaisiin, jossa kerrottu edes jotain eroista, esim:
http://www.agner.org/optimize/microarchitecture.pdf
Oho?! Täytyy olla joku todellinen taavi jos ei tunne em. arkkitehtuuria?
hiekkalaatikkobasicianne luulette pyörittävän?
C-kielen VOIMA onkin siinä, että se on tiukasti kiinni konekielessä ja se on yhtä juhlaa kun sen ymmärtää.
Saatte olla varma, että se basic - kun olette niitä palikoita kasannut - käännetään konekielelle vaikka olisi tulkattavaa laatua ja olen tatti siitä, että siellä ne osoittimet sitten löytyvät.
OPETELKAA ALKEET.
Mistäs haudasta heräsit ?
Eihän 16 -bittisiä ohjelmia oo tehty enää aikoihin.
Sitten niitä taaveja on täällä aika runsaasti. Luitko tän palstan otsikon "C-ohjelmointi" ? Perusteokset menevät paremmin jakeluun kuin oudot katkelmat, jossa ei ole mistä edes on kyse.
Tässä esimerkki paremmasta:
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24592.pdf
(kappaleessa 3.1 sivulla 55 on nyt se rekisteriasia, johon viittasit)
mukana - sieltä ne lähtee 8088 .. alusta päätyen nykyisiin 64-bittisin - nimet vain muuttuvat pointtereilla muuttuvat kuvaavimmiksi - ts. tavalla tai toisella indeksoidaan.
http://keskustelu.suomi24.fi/show.fcgi?category=108&conference=4500000000000140&posting=22000000025794657
http://keskustelu.suomi24.fi/show.fcgi?category=108&conference=4500000000000140&posting=22000000025662464
Osoittimia toki on, mutta bp ja sp kuuluvat historiaan. Niitä ei siis nykyisistä vb:n assemblyistä löydä.
Mikä ihmeen linkki toi on ?
Jos kyse on siitä mikä on hyvä lähdekirjallisuus rekistereihin (tai ylipäänsä arkkitehtuuriin), tossa ei ainakaan siitä ole sanottu pätkääkään.
Mitä merkitystä sillä on mitä vb-koodista tulee kännettynä konekieleen? Ei vb-koodaajan tarvitse sitä tietää.
Totta kai osoittimet on. Osoittimiahan on muuttujatkin. Ne viittaavat tiettyyn muistipaikkaan. Kaikki muuttujathan on osoittimia.
Lainataan pätkä: "Esim. SP, BP, .." - mitä siinä kerrotaan?
Ja opetelkaa lukemaan.
http://keskustelu.suomi24.fi/show.fcgi?category=108&conference=4500000000000140&posting=22000000025790622
Ei 16-bittisyys - ei liioin 8-bittisyyskään ole kadonnut minnekään.
Intelin/AMD'n alustalla pyöritetään muutakin kuin teidän visuaalilaatikoitanne.
:D
287 : _O.rdbuf()->sputc(_O.fill())))
000ed 8b 4d 08 mov ecx, DWORD PTR __O$[ebp]
000f0 8b 11 mov edx, DWORD PTR [ecx]
000f2 8b 4d 08 mov ecx, DWORD PTR __O$[ebp]
000f5 03 4a 04 add ecx, DWORD PTR [edx 4]
Mitä tuossa tapahtuu?
asiaan oikeestaan mitenkään mutta ainakin vb koodi on jotain 1000 kertaa hitaampaa kuin C/C ja vielä paljon hitaampaa suoraan konekieleen verraten.
muutenkin vb on javan kaltainen "hirvitys" joka tarvitsee kirjaston jos toisenkin että mikään ohjelma edes toimisi.
tämä "java-hirvitys", koska olen ihan livenä nähnyt kun aletaan tehdä arviolta 500000€ maksavaa ohjelmaa ja joku pässi valitsee koodauskieleksi javan??? lopputulos: ohjelmasta tulee VITUNHIDAS, sekoileva,epävakaa yms. ja kustannukset n.2000000€. se on sitte perkeleen tuotanto tehokasta odotella jonkun tulkin tulkkaamisia koneen ymmärtämäksi ja wait wait wait ja tietokantahaut on tietenkin helvetin "toimivia" ja "nopeita" yms. totta että OSA näistä ohjelman sekoilu hommista johtuu koodausvirheistä, suurin osa nopeuteen liittyvistä hommista taas ei.
korkeamman-korkean-tason kielet sopii kyllä pikkuprojekteihin ja kännyköihin mutta ei muuhun.
jäänne historiasta, jota pidetään väkisin hengissä?
http://support.intel.com/support/performancetools/sb/CS-020958.htm
Näkyy puuttuvan basicit?
:D
Huomasitko, että nyt oli kyse VB2005:stä eikä muista versioista. .NET on nykyisellään joissain asioissa hitaampi kuin suora konekieli, mutta katsotaan sitten seuraavassa winkkarin versiossa.
Jos katsot mitä vtunella pystyy optimoimaan, löydät vb:n kyllä listoilta. VB.net taitaa olla tälläkin hetkellä vielä suosituin .NET:n kielistä.
on massoittain 'kotilaatikkokoodaajia' - sellaisia etenkin, jotka uskovat osaavansa jotain - vaikka eivät tunne edes koneen sielunelämää.
:D
Visual-basic'illa ei tehdä todellista mämmiä.
sunkin kannattaisi joskus perehtyä ohjelmistotuotantoon niin ymmärtäisit että kaikkea ei ehkä tehdä nopeutta silmällä pitäen. javaa ja vb:tä on ihan turha verrata keskenään, vb on mikkisofta-ympäristöön sidottu, palikkaohjelmien vääntämiseen tarkoitettu lelu ja java enterprise-tason työkalu jolla työstetään pääasiassa laajat hajautetut tietokantasovellukset.
ja mitä tuohon sekavuuteen tulee, niin javaa on kyllä 100 kertaa miellyttävämpää lukea kuin C/C sekamelskaa eikä yhtä altis "inhimillisiin" koodimokiin.
Eipä sillä vb2005:llä koodatessa tarvitsekaan tietää sielunelämästä mitään. Koodin nopeus riippuu sitten miten mikkisofta on optimoinut käytettävät toiminnot ja funktiot
".. ja mitä tuohon sekavuuteen tulee, niin javaa on kyllä 100 kertaa miellyttävämpää lukea kuin C/C sekamelskaa eikä yhtä altis "inhimillisiin" koodimokiin."
.. vakuutan, että koodin luettavuus on VAIN koodaajan taidoissa ja jos jo lähdössä livetään, että ei ymmärretä että mitä sitä ollaan edes tekemässsä niin kunnon mämmin sijasta ryvetään PUUROSSA - monta kertaa lämmitetyssä puurossa.
Tiedän, että on parempi tehdä asiansa osaajasta ohjelmoija kuin päinvastoin, että ohjelmoija/systeemisuunnittelija selvittäisi laitekokonaisuuden tai muun merkityksellisen hierarkian ennen kuin mämmiä väännetään.
OLEN NÄHNYT SELLAISTA PUUROA, ETTÄ HIRVITTÄÄ - JA KUULLAKSENI VAIN TOTEaMUKSEN - "KYLLÄ MINÄ SIITÄ SELVÄÄ SAAN".
VB 2005 on ihan eri basic kuin mitä ne oli 10 vuotta sitten. Huippuhyvä ohjelmointiympäristö.
Tuossa sinun listassa basikkia ei tietysti ollut, sillä siinä oli Intelin omat ohjelmointikielet joita se tukee.
Microsoftin VB on niin loistava ettei Intelin kannata tehdä omaa versiotaan siitä, sillä ei Microsoftille pärjää.
Täytyy muistaa että Microsoft tunnettiin 20 vuotta sitten ensisijaisesti ohjelmointikielistä. Vasta niiden jälkeen tuli MS-dos ja taulukkolaskenta. Word ja Excel taas niiden jälkeen.
ENNEN Microsoftin maailman ilmestymistä - konekielisenä, rivibasicilla, DeSmetin C'llä - se aukaisi silmät - ja hyllystä löytyy myös ENSIMMÄINEN Miocrosoftin Visual Basic manuaaleineen päivineen ja samaisen talon Pascal ja Fortran kierrekansioineen ja tietty MASM'in eri versiot että C-kielet ALUSTA saakka ja niistäkin on pumaskaa jo parin metrin verran yhteensä.
Sitten voisimme siirtyä sulautettuihin: Mitähän niistä en olisi käyttänyt? NEC - se jäi vain manuaalien hankinnaksi - 4-bittinen prossu.
Jne...
"Huippuhyvä ohjelmointiympäristö. "
miten tuon saa linuxiin?
http://www.microsoft.com/msj/backissues86.aspx
.. julkaisuun vuodelta 'May 1988 VOL3 NO3 - Ten dollars'
..
pitää tietysti olla 'QuickBASIC' ja sen ensimmäisestä nelosversioon.
Nopeutta lisää heti tai ainakin isommat tuopit!
OO:lla tuskin saat nopeutta lisää vaan luultavasti päinvastoin. Olihan käännös optimoitu (nopeutta hakien). Esim. gcc valinnalla -O2 tai -O3 voi olla jopa 3 kertaa nopeampi, kuin ilman optimointia. Tietysti itse koodiakin voi viritellä ja saada vaikka 100x nopeammaksi (esim. jos on mahdollista käyttää ns. lookup-taulukoita), mutta johtuu paljon tapauksesta onnistuuko.