A mai gépek miért nem tudnak a másodperc tört része alatt 0..2147483647 értékig elszámolni?

Előző vagyok... Az előző hozzászólásomban van egy kis bug.. ez 4 milliárdig számol..tehát az időt le kell osztani 2vel:)

#22-es: gyanítom, hogy a C(++) fordító a te kódodnál jobban optimalizál.

Bár én nem fordítottam most assemblyt, de nekem elég gyanús, hogy gyorsabb a C fordító által generált kód, mint a te inc-cmp-jnz kódod... az valahogy beépítetten tudja ismételni a ciklusmagot, gyanítom hasonlóan, mint ahogy írtam. Jó lenne kipróbálni, hogy ténylegesen mit is generál a fordító, de most lusta vagyok :)

Szóval ha van időd, sztem nézd meg és hasonlítsd össze a te assembly kódoddal.

Hát nézzük...

1 GHz az egymilliárd órajelciklus egy másodperc alatt. Ez első hangzásra nagyon soknak tűnhet... de ha az ember kicsit képben van, hogy akár maga a processzor, akár alacsonyabb szinteken a programozás hogyan működik, akkor tudni fogja, hogy azért annyira nem szép a helyzet.

Az az egymilliárd az elemi műveletként értendő. A többszálúságról most ne beszéljünk, ahhoz eleve többszálúan kellene a programot megírni. (Már amelyik részét lehet.) Alapból egy program egyetlen szálat használ. Ami pedig egyetlen műveletnek tűnik, az igazából van, hogy nagyon sok elemi művelet egymásutánja. Az osztás például kifejezetten sok műveletet jelent. De az, hogy minden egyes cikluslefutáskor ellenőrizni kell a ciklusváltozó értékét, az is jópár elemi utasítás. Kétmilliárdszor kb. 10 műveletet lefuttatni egy 1 GHz-es procin pedig nagyjából 20 másodperc. Mert bár a mai processzorokat már semmiképp nem lehetne lassúnak nevezni, de kétmilliárd meg rohadt sok. És normális körülmények között elég ritkán van rá szükség, hogy ennyi nyers műveletet végezzünk másodpercenként. A programot megfelelően optimalizálva pedig az eredeti algoritmus nagyságrendekkel gyorsítható. Jó algoritmus mellett még egy nagyon gyenge gépből is bámualtosan sokat ki lehet hozni. Főleg, ha van egyéb hardveres segítségünk is. Mondjuk ha sikerül kihasználni, hogy már a tízéves gépekben is legalább két procimag van, illetve ha a grafikus processzort is sikerül munkára bírni, a sokszorosát ki lehet hozni annak, amire egy optimalizálatlan lépegetésnél képes a rendszer.

Mondjuk a 20. hozzászólásodban írt kódot két helyen is lehetne optimalizálni: szam := maxlongint; Hiszen végeredményben ezt valósítja meg. Az első ciklus meg el is hagyható, hiszen miután a végső értékét felvette, a változót egyszerűen nullázod.

De tekintve, hogy fel sem használod az értékét, a programodból mindent ki lehet törölni a két writeln kivételével. ;-)

Szia.

Delphiben Konzolos alakalmazásban : [link]

Az általad irt kód 0.73 és 0.722 másodperc alatt futott le, egy Intel(R) Core(TM)2 Dou CPU E8400@ 3.00 GHz 2.99 GHz-es gépen, kép : [link]

Sok sikert. Üdv.

33:

"2147483647 értékig elszámolni"

Egy másodpercnél kevesebb idő alatt. Ez az óhaj.

Már pedig ez bőven teljesíthető valamelyik regiszter inkrementálásával.

Az INC meg egy ciklusigényű művelet, ahogy a közeli JUMP is.

Szóval, a kérdésbeli kivánságnak egy P-II-esen is teljesülnie kell.

Teljesül is az, ha nem fut vele párhuzamosan semmi más.

Jut eszembe, a mai gépek órajele jellemzően 3 GHz, nem 1.

"de nekem elég gyanús, hogy gyorsabb a C fordító által generált kód, mint a te inc-cmp-jnz kódod... "

LoL

"az valahogy beépítetten tudja ismételni a ciklusmagot, gyanítom hasonlóan, mint ahogy írtam."

Aha. És mikor végez feltétel ellenőrzést, amikor kedve szottyan?

"Aha. És mikor végez feltétel ellenőrzést, amikor kedve szottyan?"

Ennyire sötét vagy? Konstans számú ismétlés van, simán bele lehet tenni 16, 32, stb darab ciklusmagot és utána jumpolni vissza...

Nem én pontoztalak le, de látom mások is egyetértenek, mert 0%-on állsz.

"Nem én pontoztalak le, de látom mások is egyetértenek,"

Mivel értenek egyet, a marhasággal, amit ide nyomtál?