Pa bilo je za ocekivati da ce to parce koda raditi brze ako ti samo ono predstavlja tvoj kernel. Sam operativni sistem, kao sto je Linux, ima milion problema o kojima treba da misli u toku rada, a taj tvoj programcic je za linux samo "jedna sitna riba u moru". Ti si uporedio:
- Linux koji moze sve i svasta da pokrene, znaci univerzalan je po tom pitanju
- Tvoj kernel koji je pravljen namenski i koji nista drugo ne moze da radi

Znaci razlika je ogromna u samom principu izrade, to je poredjenje babe i zabe. Usput si verovatno ovaj tvoj programcic pokrenuo pod linuxom kao obican proces, bez ikakvog prioriteta nad ostalima, a ovamo si ga pokrenuo samog sa potpunom kontrolom nad racunarom. Probaj ga uporedi sa nekim operativnim sistem koji radi u real-time modu... Imas i neke patcheve za linux da bi radio u real-time... Verujem da bi tada rezultati bili dosta povoljniji po linux...
Alati poput John-a se mogu ubrzati na ovaj nacin, samo ako imas zivaca sve lepo prepisati... I tu imas dve solucije: ako pravis svoj libc i sve ostalo sto ti treba da bi portovao John laganice, onda opet malo gubis na brzini. A ako bi sve to prepisao u ASM, e to bi vec bila prava stvar ;)

Shvacam ja to da linux ima malo vise stvari za obavljat i zbog toga mislim da bi bilo bolje na ovakav nacin rjesit takve programe jer dok se to radi obicno nema potrebe da se radi nesto drugo na kompu (npr dok spavam). Probat cu skinut i instalirat te patcheve pa vidjet kolka je razlika, ako je zamjetna onda mislim da cu prepisat johna u asm i bootat ga u real modu, jer ipak je brzina vazna.

Koliko puta si pod linuxom ponovio test? I da li su rezultati bili uvek slicni/identicni? Mozda je linux bas u trenutku izvrsavanja tvog kooda odlucio da uradi nesto zahtevno, npr. defragmentira malo RAM, upise zaostale IO transfere, ili sta god vec linux radi u slobodno vreme.

ss.

ps. ako ti je brzina vazna, real-mode nije najsrecnije resenje. mozda je bolje da se drzis protected moda.

Pa bitan je real-mode, kao i veca brzina odziva sistema... Andrew Morton je uradio patch za linux kernele za smanjenje latency-ja (patch se zove low latency). Cini mi se da je taj patch i ugradjen u nove kernele, tako da nema potrebe za njim. Inace, postoji TimeSys-ov patch za kernel koji radi bas fino... proguglaj malo pa ces naici na to...

Test sam ponovio jedno 4 puta s tim da sam resetirao komp nakon 2 testa, i rezltati su bili +-1 ili 2 sec.

Imam 2.6.3 verziju kernela, pa pretpostavljam da imam taj patch, ali cu probat skinut nesto novo i testirat. Sad mene zanima jel se isplati radit takav projekt (prepisivanje johna) i dali mogu ocekivat dobre rezultate?

Moje misljenje je da je problem int 0x80. Sve ostalo je isuvise smesno - na svim procesorima se izvrsava za smesno kratko vreme. Sta uopste predstavlja poziv int 0x80 na linuxu?????

Cheers

cek, cek, int 80 je na linux-u poziv systemskog API-ja ... ?! (fopen i slicne stvari ..)

U ovom topicu se ne radi o problemu :) int 0x80 ti prebacuje code execution iz user moda (ring 3) u kernel mode (ring 0) i sluzi za pozivanje sistemskih poziva.


.

Da, ali bas si fulao primjer :-) fopen() je implementiran na razini glibca.

Omasio sam primer, nije bitno, hteo sam da napomenem da kod koji se samostalno butuje i izmedju ostalog poziva int 80 nije isto sto i slican kod koji pod Linux-om pozove int 80? Sad cu jos da lupam ali kad se samostalno butuje pozivanje int80 ne radi nista - ili pozove neki (pitaj boga koji, najverovatnije prazan) interup handler, dok isto to pod Linux-om prebaci na kernel execution mode, onda verovatno proveri parametre i ukapira da je u pitanju nebuloza i vrati exekuciju user modu - ali u sustini pojede veliko vreme (prelazak rin3 -> ring0 -> ring3) ? Dakle to moze biti razlog drasticne razlike u vremenu izvrsavanja.

Sto se tice fopen() - prilicno sam siguran da mora da ima posla sa kernel-om , mozda nije cela implementirana u kernel-u ali negde u sebi mora da se obrati VFS-u, ili gresim ?

Mozda sam ja kriv jer nisam bio dovoljno preciza, ono je kod koji se vrti u linuxu i poziva exit syscall (koji pozovem preko int 0x80) da izadje van, dok u kodu koji se boota ne poziva int 80 jer nepostoji vec na drugi nacin izlazi iz koda.


Pa ona ima "posla" sa kernelom preko open sistemskog poziva.

Ma da, pre nego sto smo poceli da filozofiramo o int 80 trebalo je da pogledamo kod, ocigledno je kolko smo pazljivo pogledali onaj asembler gore :)