FOR silmukka 1 => 1000000000 (yhteen miljardiin) vie aikaa vain 3.94 sekuntia.
NO, kokeile itse:
#!/usr/bin/env lua
local x = os.clock()
local s = 0
for i=1,1000000000 do end
print(string.format("Suoritus kesti: %.2f sekuntia.\n", os.clock() - x))
NO, kokeile itse:
#!/usr/bin/env lua
local x = os.clock()
local s = 0
for i=1,1000000000 do end
print(string.format("Suoritus kesti: %.2f sekuntia.\n", os.clock() - x))
Vastaukset 29
Vanhimmat
Jäi tuohon tuo
local s = 0
Joka ei tähän nyt kuulu, se oli mukana kun tutkin paljonko aikaa menee kun kasvatetaan silmukassa muuttujankin arvoa samalla. No se vei melkein kaksinkertaisen ajan.
Silmukka joka ei tee mitään? Onpa hidas, Rust-kielellä tuohon kuluu aikaa 0,000000397 sekuntia.
let start = std::time::Instant::now();
for i in 1..1_000_000_000 {}
let elapsed = start.elapsed();
println!("Suoritus kesti: {:.9} sekuntia", elapsed.as_secs_f64());
Onko Rust miten helppo saada toimimaan Visual Studiossa?
Enpä ole kokeillut, mutta lyhyitä Rust-koodinpätkiä voi kokeilla netissäkin ilman asentamista. Tässä esimerkiksi tuo koodi (yllä olevasta esimerkistä jäi puuttumaan main-funktio):
https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=840d7afca013712fd4801df1fbe8cad7
Mikähän siinä on pielessä kun silmukan pienentää 1..100, niin aikaa menee tuhansia kertoja pitempään.
Suoritus kesti: 0.0000013 sekuntia (1..100)
Suoritus kesti: 0,000000397 sekuntia
Taitaa olla päin persettä tuo koodisi.
Koodissa ei ole mitään vikaa, mutta enpä kerro syytä tuohon koska sitä kannattaa kyllä miettiä.
Enpä ihmettele että aluksi unohtui laittamatta mukaan.
Eipä tarvitse kertoakkaan, sokeakin näkee jo kepillään että päin persettähän tuo on.
No minä korjasin sen, ja tulos on yli 11 sekuntia, että se siitä RUSTin tehosta.
LUA on edelleen se nopein, kun huomioidaan sen toimenkuva.
Yllä olevan koodin voit tallentaa vaikka testi.lua ja ajaa;
./testi.lua
lua on oletusarvoisesti kaikissa linux jakeluissa, joten ei tarvita mitään asentamisia.
höpöhöpö, ei ole Debian 11 jakelussa oletuksena
Minä nyt puhuinkin oikeista Linux jakeluista, enkä mistään maailman reikäisimmästä räpellyksestä.
Järjestelmääsi kuuluvan version voit tarkistaa;
lua -v
Ja se vastaa:
Lua 5.4.3 Copyright (C) 1994-2021 Lua.org, PUC-Rio
malaire$ lua -v
bash: lua: command not found
Debianissa voi tarvita sudoa. Osa komennoista on piilotettu sudon taakse, kuten shutdown.
Voit käyttää lua komentotulkkia aivan samoin kuin python tulkkiakin:
lua
for i=0,100,10 do print(i) end
Huomaa; silmukan askeltaminen, on yksinkertaisempaa kuin pythonissa.
Nodella kesti näköjään sekunnin.
$ cat ./luuppi.js
const hep=Date.now()
for(let i=0; i<1000000000;i ) {;}
console.log(Date.now()-hep)
$ node luuppi.js
1029
Pitkäänkö menee hakea listaus kaikista järjestelmään kuuluvista tiedostoista?
En tiedä, mutta aloituksen lua-juttu kesti samassa järjestelmässä 6x pidempään kuin Node.js:llä.
....
Suoritus kesti: 6.11 sekuntia.
Joo, kyllä se lua on hitaampi, mutta kun niiden toimenkuva on niin erillainen, ettei niitä voi pitää toistensa kilpailijana.
Toimenkuvalla tarkoitan sitä että lua:lla ei voi korvata JavaScript -sovelluksia, eikä JavaScript:llä voi korvata lua -ohjelmia. Vaikka ne nyt tässä silmukkka testissä voidaankin asettaa rinnakkain.
Jonkun markkinoimalla rustilla kesti ja kesti.
...
Suoritus kesti: 43.095976634 sekuntia
....
Kärjessä tällä hetkellä siis node sekunnin tuloksella.
Ei se välttämättä aja sitä silmukkaa ollenkaan jos se täysin tyhjä eikä tee mitään prosssori vain hyppää sen turhan koodin yli kokonaan.
Mittaatko aikaa Real Time Clockilla, vai DMA-counterin rekisteriä lukemalla?
Jos tietää väylän nopeuden, niin DMA;n saa luettua kohtuullisen hyvän ajan myöskin.
Eli DMA-0:n eli muistin päivityksen counter-rekisteristä otat ajan.
Minä käytin kerran juurikin DMA;n, ohjelman optimoinnissa oikeastaan, kun videon digitoijakortti digitoi videokuvaa keskusmuistiin, niin yleensä odotetaan että se kuva on valmis, siis yksittäinen frame, en odottanut, vaan:
Luin DMA:n siirron kohdasta, että milloin se aloittaa sen kuvan digitoimisen, tiesin että prosessori ei käsitellä sitä kuvaa yhtä nopeasti kuin muistisiirto menee, niin voi aloittaa jo laskemisen ennen kuin kuva on digitoitukaan valmiiksi.
Eli DMA; n muistisiirto menee vähän edellä ja prosessori vähän perässä, lähtevät kuvan alkaessa samalta "maaliviivalta".
Lua:lla on oma editorinsakkin ZeroBrane Studio. Asentelin ja testasin, tulin siihen tulokseen, että pois joutaa, Geany on parempi.
https://studio.zerobrane.com/
Tarkistin netistä huvikseni paljonko DMA;n siirtonopeus on niin noin 4Gigatavua sekunnissa kun joku SATA3 on vain noin 300Megatavua sekunnissa :D
UTF-8 koodisivun merkit ovat osittain kaksitavuisia. Python ja Lua pohjautuu C-kieleen ja perivät C-kielestä kyvyttömyytensä muuntaa pientä kirjainta isoksi ja päin vastoin.
-- print Ä ja ä
print(string.char(195,132))
print(string.char(195,164))
Toistaiseksi ainoa syy käyttää LUAa, johon minä olen törmännyt, on Löve2D, joka on ylivoimaisesti näppärin pelimoottori nopean peliprototyypin kyhäämiseen pienellä vaivalla. Kaksiulotteisuus toki aiheuttaa joskus harmaita hiuksia jos lopputuloksen pitäisi olla 3D, mutta pienellä grafiikkakikkailulla siitäkin yleensä selviää.
Muuten en käytä LUAa mihinkään, koska sen syntaksi on kuvottavan samankaltainen JavaScriptin kanssa.