Forum » Programiranje » Najhitrejši programski jezik?
Najhitrejši programski jezik?
darkolord ::
ja, to je ze res... samo ce napises clabo kodo, ti je tudi dober kompiler ne more prevest v 'dober' ASM... v ASMju pa ne vem kako slabe kode ne mores pisat - v VB na primer zlahka napises ultra pocasno kodo...
OwcA ::
Darko: ne prvo, ne drugo ni res. 
Če se odločiš implementirati neustrezen (prepočasen) algoritem, bo ta nnatančno toliko neustrezen tako v ASMju kot VBju.
Če se odločiš implementirati neustrezen (prepočasen) algoritem, bo ta nnatančno toliko neustrezen tako v ASMju kot VBju.
Otroška radovednost - gonilo napredka.
darkolord ::
ne govorim o algoritmu samem ampak o neustreznem pisanju kode (uporaba nepotrebnih funkcij, pisanje lastnih namesto uporaba ze obstojecih, pa take stvari sej veš kaj msilim)... 
pa recimo v VB lahko uporabis napacne tipe spremenljivk ("dim x" je tudi 20x pocasneje kot "dim x as tip_spremenljivke")
pa recimo v VB lahko uporabis napacne tipe spremenljivk ("dim x" je tudi 20x pocasneje kot "dim x as tip_spremenljivke")
Zgodovina sprememb…
- spremenilo: darkolord ()
OwcA ::
Če hočeš biti banalen, tudi v ASMju lahko delaš nepotrebne skoke, ne upoštevaš velikosti ragistrov ...
Tvoji pomisleki opazni predvsem pri jezikih, ki se interpretirajo, ker pa pri teh interpreter tako ali tako ne optimizira kode ravno izrazito (če jo sploh) je to irelevantno.
Tvoji pomisleki opazni predvsem pri jezikih, ki se interpretirajo, ker pa pri teh interpreter tako ali tako ne optimizira kode ravno izrazito (če jo sploh) je to irelevantno.
Otroška radovednost - gonilo napredka.
darkolord ::
mnja, moj point je bil v temu, da če si popolni kreten, v ASMju ne boš znal ničesar narest, brez da se malo poučiš o teh registrih in takih stvareh, medtem ko lahko vsak 'seronja' nardi en programcek v VBju... pa tole o praštevilih je že desetletja zelo prežvečena tema (dostikrat je bil zaključek, da se ne da kar tako s praštevili določiti najhitrejšega jezika in da ima vsak jezik svoj namen) in se meni zdi, kot da nekdo proba toplo vodo odkritvat tukaj 
Zgodovina sprememb…
- spremenilo: darkolord ()
Gandalfar ::
(dostikrat je bil zaključek, da se ne da kar tako s praštevili določiti najhitrejšega jezika in da ima vsak jezik svoj namen)
Argumentiraj z linki prosim.
asPeteR ::
-> (dostikrat je bil zaključek, da se ne da kar tako s praštevili določiti najhitrejšega jezika in da ima vsak jezik svoj namen)
Gandalfar: Tole ma darkolord cist prav. Resnicno drzi, da ima vsak jezik svoj namen in je v svojem podrocju najboljsi. To je 100%. Toda, ce se pa RES omejimo na golo hitrot jezika, pa stvar ni vec tako relativna. Ceprav je se vedno tezko dolociti absolutno merilo, za hitrost nekega jezika, kakor to velja za merjenje same hitrosti racunalnikov oz. razlicnih arhitektur. Mislim, da stvar pri sofwaru dokaj podobna.
Gandalfar: Tole ma darkolord cist prav. Resnicno drzi, da ima vsak jezik svoj namen in je v svojem podrocju najboljsi. To je 100%. Toda, ce se pa RES omejimo na golo hitrot jezika, pa stvar ni vec tako relativna. Ceprav je se vedno tezko dolociti absolutno merilo, za hitrost nekega jezika, kakor to velja za merjenje same hitrosti racunalnikov oz. razlicnih arhitektur. Mislim, da stvar pri sofwaru dokaj podobna.
http://blog.stegnar.com
|CyGNUS-x ::
Sreča zate, ker si narobe razložu.
Ni in ne more biti nobenega drugega načina za preizkušanje
resnične moči kapitalistične države kot je vojna.
resnične moči kapitalistične države kot je vojna.
EZ2BHard ::
Samo dodal bi rad, da se za kakrsnokoli resno tovrstno primerjavo uporabljajo profilerji, ker se z njimi tocno vidi, koliko casa je bilo porabljenega v dolocenih odsekih, zankah, funkcijah in sele na osnovi tega so mozne relevantne primerjave, ne pa zgolj na osnovi skupne dolzine izvajanja.
Thomas ::
// The algorithm has been enhanced For 83.53%
$DIMENSION sieve[10000]
$MINIMIZE LINES 40
$SOUND ON
$RINVAR upto(9999,9999)
$RETVAR sieve[]
// int sieve[1000]; int two=0;int index=0;int primecandidate=0;int one=0;int upto=0;int critticall1=0;
two=2; //[ 14]
index=0; //[ 14]
sieve[index]=two; //[ 14]
index=1; //[ 14]
sieve[index]=two; //[ 14]
$BES
primecandidate=4; //[ 14]
while (primecandidate<=upto) { //[ 1862]
sieve[primecandidate]=index; //[ 1848]
primecandidate=two+primecandidate; //[ 1848]
} //[ 0]
two^=1; //[ 14]
primecandidate=two*two; //[ 14]
critticall1=two+two; //[ 14]
while (primecandidate<=upto) { //[ 46]
sieve[primecandidate]=index; //[ 32]
primecandidate=critticall1+primecandidate; //[ 32]
two+=2; //[ 32]
while (primecandidate<=upto) { //[ 942]
sieve[primecandidate]=index; //[ 910]
primecandidate=critticall1+primecandidate; //[ 910]
} //[ 0]
primecandidate=two*two; //[ 32]
critticall1=two<<index; //[ 32]
while (primecandidate<=upto) { //[ 576]
sieve[primecandidate]=index; //[ 544]
primecandidate=critticall1+primecandidate; //[ 544]
} //[ 0]
two+=2; //[ 32]
primecandidate=two*two; //[ 32]
if (primecandidate<=upto) { //[ 32]
critticall1=two+two; //[ 22]
sieve[primecandidate]=index; //[ 22]
one=critticall1<<index; //[ 22]
primecandidate=one+primecandidate; //[ 22]
two+=2; //[ 22]
} //[ 0]
} //[ 0]
$EES
No, tole je eno dobro sito - IMO.
Kdor misli kompilirat, naj okomentira $ukaze
Man muss immer generalisieren - Carl Jacobi
Zgodovina sprememb…
- spremenilo: OwcA ()
Thomas ::
Ja, "upto" nastviš v začetku na toliko, do kolikor hočeš imeti sito narejeno. Če do 1000 (upto=1000;), bo za vsako celico sita (sieva) porabil manj kot 3 inštrukcije. Dovolj ugodno in poceni - IMO.
Man muss immer generalisieren - Carl Jacobi
Thomas ::
Zanimivo je pa to, da tale algoritem rabi manj korakov, da poznači sestavljena števila do 1000 (naredi sito ali sieve), kot jih rabi algoritemček, ki v že narejenem situ prešteje nule (enke). Get out of here!
Man muss immer generalisieren - Carl Jacobi
Thomas ::
Kar pa ne pomeni, da je bil zgornji rezultat že optimalen. Tukaj je en še bolj nehuman, ki zaradi dodatnih vrstic dela še hitreje. Oziroma rabi manj korakov, kar je za dober compiler isto.
// The algorithm has been enhanced For 44.5728%
$DIMENSION sieve[1000]
$MINIMIZE LINES 60
$SOUND ON
$INVAR upto(897)
$RINVAR upto(9,999)
$RETVAR sieve[]
// int sieve[1000]; int prast=0;int x=0;int critticall3=0;int upto=0;int acritticall1=0;int one=0;
$BES
prast=1; //[ 10]
x=2; //[ 10]
critticall3=4; //[ 10]
sieve[prast]=x; //[ 10]
while (critticall3<=upto) { //[ 2064]
sieve[critticall3]=prast; //[ 2054]
critticall3=critticall3+x; //[ 2054]
} //[ 0]
sieve[acritticall1]=x; //[ 10]
x|=1; //[ 10]
critticall3=x*x; //[ 10]
acritticall1=x<<prast; //[ 10]
while (critticall3<=upto) { //[ 42]
sieve[critticall3]=prast; //[ 32]
critticall3=critticall3+acritticall1; //[ 32]
while (critticall3<=upto) { //[ 1084]
sieve[critticall3]=prast; //[ 1052]
critticall3=acritticall1+critticall3; //[ 1052]
} //[ 0]
x+=2; //[ 32]
critticall3=x*x; //[ 32]
if (critticall3<upto) { //[ 32]
acritticall1=x<<prast; //[ 28]
sieve[critticall3]=prast; //[ 28]
critticall3=acritticall1+critticall3; //[ 28]
if (critticall3<upto) { //[ 28]
sieve[critticall3]=prast; //[ 25]
one=acritticall1<<prast; //[ 25]
critticall3=critticall3+one; //[ 25]
while (critticall3<=upto) { //[ 218]
sieve[critticall3]=prast; //[ 193]
critticall3=acritticall1+critticall3; //[ 193]
if (critticall3<upto) { //[ 193]
sieve[critticall3]=prast; //[ 186]
critticall3=critticall3+one; //[ 186]
} //[ 0]
} //[ 0]
x+=2; //[ 25]
critticall3=x*x; //[ 25]
if (critticall3<upto) { //[ 25]
sieve[critticall3]=prast; //[ 22]
acritticall1=x+x; //[ 22]
one=acritticall1+acritticall1; //[ 22]
critticall3=critticall3+one; //[ 22]
x+=2; //[ 22]
} //[ 0]
} //[ 0]
} //[ 0]
} //[ 0]
$EES
Man muss immer generalisieren - Carl Jacobi
Zgodovina sprememb…
- spremenilo: OwcA ()
MrBrdo ::
Eh veste kolk stvari je tukaj pomembnih.. Pri Cju se poznajo razlike med različnimi compilerji, potem izklop debugging opcij in tako naprej.. Najhitreje bi brez vsakega dvoma bilo v assemblerju, najpočasneje pa v Javi. Verjetno bi bilo precej hitro tudi z Borlandovim Delphijem (pascal) in C, vendar bi ga po mojem mnenju (na pamet govorim), Borland nabil za kaksno manjso razliko. Drugace pa ziher assembler (npr MASM na windowsih). In btw rezultati ki jih postajo razlicni ljudje niso primerljivi zaradi mnogih razlogov kot so hitrost procesorja, kater OS je, koliko programov laufa v ozadju itd.
Na moji masini (Athlon 64 3000+ Mobility z 32-bitnim programom, Delphi 6 + KOL):
prvih 100000: 3,24 sekunde
prvih 20000: 0,29 sekunde
lp
Na moji masini (Athlon 64 3000+ Mobility z 32-bitnim programom, Delphi 6 + KOL):
prvih 100000: 3,24 sekunde
prvih 20000: 0,29 sekunde
lp
MrBrdo
Zgodovina sprememb…
- spremenilo: MrBrdo ()
jype ::
Med jeziki ni nobene razlike v hitrosti, saj to je jasno.
Razlika je samo v tem kako prevajalniki za razlicne jezike proizvedejo razlicen machine-code.
icc na primer _v povprecju_ proizvede najhitrejse executable od vseh C prevajalnikov, tako na intel kot AMD procesorjih.
gcc je nekaj srednjega, a najbolj portable in najbolj featureful.
VC je hitrejsi od gcc in obicajno proizvaja hitrejse executable, a vcasih zamoci.
Jeziki niso pomembni, je pa pomembno kako dobro nam omogocajo izraziti idejo. Tukaj Python rula in PyRex (prevajalnik, ki iz Pythona naredi machine code) to potrjuje. Seveda ne vedno, le obicajno.
Razlika je samo v tem kako prevajalniki za razlicne jezike proizvedejo razlicen machine-code.
icc na primer _v povprecju_ proizvede najhitrejse executable od vseh C prevajalnikov, tako na intel kot AMD procesorjih.
gcc je nekaj srednjega, a najbolj portable in najbolj featureful.
VC je hitrejsi od gcc in obicajno proizvaja hitrejse executable, a vcasih zamoci.
Jeziki niso pomembni, je pa pomembno kako dobro nam omogocajo izraziti idejo. Tukaj Python rula in PyRex (prevajalnik, ki iz Pythona naredi machine code) to potrjuje. Seveda ne vedno, le obicajno.
MrBrdo ::
Sori, sam o cem si pa ti mislil da govorimo?
Itak je bolje da imaš čim manj compileanja vmes in je zato najbolje assembler (low level mislim, obstajajo tudi neki "high level jeziki" se mi zdi da HLA ali nekaj podobnega), ko v bistvu že itak pišeš v machine kodi, le da je malo bolj berljiva.. Najhitreje je sigurno če uporabljaš kolikor se da sistemske APIje (na windowsih npr win32api) v kombinaciji z assemblerjem. Python je ql, ampak dvomim da proizvede optimalno executable kodo, saj je jezik orientiran skriptersko in je kot tak manj primeren kot npr c ali pascal. Če mene vprašaš so zelo dober compiler spravili skup pri Borlandu. Sintaksa je gnila ampak programi so pa ponavadi med boljšimi, kar se stabilnosti in hitrosti tiče (npr pri C programih boš prej našel kake buffer overflowe in tako dalje, čeprav je res veliko odvisno od kode same). Ena stvar je recimo tudi to, kar mislim da večina drugih jezikov nima, in sicer da lahko izbereš pri recordih (struct v c++) ali način optimiziran za čim manjšo porabo memoryja (packed) ali način za večjo hitrost (več memoryja). C++ uporablja structe ki so več ali manj isti kot pascalovi packed recordi (torej po tej logiki počasnejši).. Tako da v določenih stvareh Delphi (oprostite tako izražanje, samo želim poudarit prav Delphi kot celoto in ne samo pascal) prekaša C++. Če ciljaš na hitrost lahko recimo uporabiš knjižico KOL, katere funkcije so nadomestek večini VCL ("original") funkcij in so skoraj vse spisane v inline assemblerju. Razlika se pozna in prekaša C++ proggyje compileane pod praktično katerimkoli compilerjem. Sicer pa so delphijevi programi tudi veliko manjši kot C++ programi, problem pa je v tem da microsoft ni hotel shipat z OSjem borlandovih knjižic, posledica tega je da po defaultu (in večinoma se to pusti vklopljeno), delphi pobere (kolikor toliko učinkovito) iz knjižic uporabljene funkcije in jih vključi v executable.
Kar se tiče sintakse imaš prav, saj so vsi jeziki glede tega več ali manj popolnoma enaki, razlikujejo se le znaki ki se jih uporablja, drugače pa je isto (npr begin v pascalu in { v cju).. Ena stvar ki se sigurno pozna pri hitrosti je če je jezik typed ali strongly-typed (C++, C#, pascal) ali untyped (Basic, Python), saj pri untyped jezikih compiler doda določene instructione zato da se pravilno določi tip spremenljivke. Pri delphiju recimo imaš poleg typecastanja (kot v C++) možnost uporabiti še Variant, vendar moraš prav tako sam implementirat preverjanje trenutnega tipa spremenljivke (do neke mere seveda), kar pomeni da je v določenih primerih še vedno bolj učinkovito kot če bi to prepustil compilerju..
LP
Itak je bolje da imaš čim manj compileanja vmes in je zato najbolje assembler (low level mislim, obstajajo tudi neki "high level jeziki" se mi zdi da HLA ali nekaj podobnega), ko v bistvu že itak pišeš v machine kodi, le da je malo bolj berljiva.. Najhitreje je sigurno če uporabljaš kolikor se da sistemske APIje (na windowsih npr win32api) v kombinaciji z assemblerjem. Python je ql, ampak dvomim da proizvede optimalno executable kodo, saj je jezik orientiran skriptersko in je kot tak manj primeren kot npr c ali pascal. Če mene vprašaš so zelo dober compiler spravili skup pri Borlandu. Sintaksa je gnila ampak programi so pa ponavadi med boljšimi, kar se stabilnosti in hitrosti tiče (npr pri C programih boš prej našel kake buffer overflowe in tako dalje, čeprav je res veliko odvisno od kode same). Ena stvar je recimo tudi to, kar mislim da večina drugih jezikov nima, in sicer da lahko izbereš pri recordih (struct v c++) ali način optimiziran za čim manjšo porabo memoryja (packed) ali način za večjo hitrost (več memoryja). C++ uporablja structe ki so več ali manj isti kot pascalovi packed recordi (torej po tej logiki počasnejši).. Tako da v določenih stvareh Delphi (oprostite tako izražanje, samo želim poudarit prav Delphi kot celoto in ne samo pascal) prekaša C++. Če ciljaš na hitrost lahko recimo uporabiš knjižico KOL, katere funkcije so nadomestek večini VCL ("original") funkcij in so skoraj vse spisane v inline assemblerju. Razlika se pozna in prekaša C++ proggyje compileane pod praktično katerimkoli compilerjem. Sicer pa so delphijevi programi tudi veliko manjši kot C++ programi, problem pa je v tem da microsoft ni hotel shipat z OSjem borlandovih knjižic, posledica tega je da po defaultu (in večinoma se to pusti vklopljeno), delphi pobere (kolikor toliko učinkovito) iz knjižic uporabljene funkcije in jih vključi v executable.
Kar se tiče sintakse imaš prav, saj so vsi jeziki glede tega več ali manj popolnoma enaki, razlikujejo se le znaki ki se jih uporablja, drugače pa je isto (npr begin v pascalu in { v cju).. Ena stvar ki se sigurno pozna pri hitrosti je če je jezik typed ali strongly-typed (C++, C#, pascal) ali untyped (Basic, Python), saj pri untyped jezikih compiler doda določene instructione zato da se pravilno določi tip spremenljivke. Pri delphiju recimo imaš poleg typecastanja (kot v C++) možnost uporabiti še Variant, vendar moraš prav tako sam implementirat preverjanje trenutnega tipa spremenljivke (do neke mere seveda), kar pomeni da je v določenih primerih še vedno bolj učinkovito kot če bi to prepustil compilerju..
LP
MrBrdo
snow ::
> Ena stvar je recimo tudi to, kar mislim da večina drugih jezikov nima, in sicer da lahko izbereš pri recordih (struct v c++) ali način optimiziran za čim manjšo porabo memoryja (packed) ali način za večjo hitrost (več memoryja).
Mislim, da se da tole ročno poštimat v C++.
Memory management se igraš z unioni, določuješ lahko tudi koliko bitov poje posamezna spremenljivka, hitrost pa z raznimi aligni. Mislim si vsaj, nisem pa delal tega :)
Lep sestavek drugače.. mogoče kakšen odstavek več :)
Mislim, da se da tole ročno poštimat v C++.
Memory management se igraš z unioni, določuješ lahko tudi koliko bitov poje posamezna spremenljivka, hitrost pa z raznimi aligni. Mislim si vsaj, nisem pa delal tega :)
Lep sestavek drugače.. mogoče kakšen odstavek več :)
Random mutation plus nonrandom cumulative natural selection - Richard Dawkins
Zgodovina sprememb…
- spremenilo: snow ()
MrBrdo ::
Snow ne vem če se da, vem pa da se velikokrat to uporablja ko kakšen C++ program shrani struct v datoteko (essentially memory dump prek pointerja) in je treba vedno uporabit packed record, da lahko iz fajla prebereš direktno v record (da ni treba da sam razporejaš podatke). Možno pa da se da, se pa ne uporablja.. Delphi ima po defaultu "memory-effecient" varianto (če ne dodaš keyworda packed).
lp
lp
MrBrdo
OwcA ::
Itak je bolje da imaš čim manj compileanja vmes in je zato najbolje assembler
Čedalje manj. Dvomim, da je veliko junakov, ki lahko "na pamet" pišejo paralelizacijo ali se igrajo z HTT.
Memory management se igraš z unioni, določuješ lahko tudi koliko bitov poje posamezna spremenljivka, hitrost pa z raznimi aligni.
Da. Predvsem poravnave. Če imaš te dobro nastavljene je velikokrat že kar struct brezizguben vsebnik.
Otroška radovednost - gonilo napredka.
MrBrdo ::
Čedalje manj. Dvomim, da je veliko junakov, ki lahko "na pamet" pišejo paralelizacijo ali se igrajo z HTT.
V mislih sem imel bolj manjše projekte kot je naprimer tale "algoritem".. Tako zadevo bi se dal brez problema spisat v assemblerju. Za kakšne večje projekte je vsekakor izguba časa pisat v assemblerju.
Da. Predvsem poravnave. Če imaš te dobro nastavljene je velikokrat že kar struct brezizguben vsebnik.
A lahko malo razložiš kaj si s tem mislil? Mislim da bo v vsakem primeru struct v memoryju v enakem formatu, torej v memory-efficient, lahko pa se motim.
MrBrdo
snow ::
__declspec(align(16))
se uporabi da se poravna array v structu na 16 bitov, kar potem omogoča hitrejšo izvajanje sse/sse2 kode. sicer smo tukaj že zelo blizu asm, a obstajajo c++ intrinsic fukcije, ki omogočajo enostavnejšo uporabo sse instrukcij.
zdej a zadeva pomaga tudi brez sse ne vem. owca? :)
se uporabi da se poravna array v structu na 16 bitov, kar potem omogoča hitrejšo izvajanje sse/sse2 kode. sicer smo tukaj že zelo blizu asm, a obstajajo c++ intrinsic fukcije, ki omogočajo enostavnejšo uporabo sse instrukcij.
zdej a zadeva pomaga tudi brez sse ne vem. owca? :)
Random mutation plus nonrandom cumulative natural selection - Richard Dawkins
mercury ::
Pomaga vsaj še pri MMX inštrukcijah, za katere podatki morajo tudi biti poravnani (na ne vem koliko bytov). Moje mnenje o assemblerju je, da ga uporabljajte samo pri algoritmih, vključujejo veliko floating point operacij. Pri tem SSE1/2/3 inštrukcije večkratno pohitrijo program. Seveda če imate možnost uporabiti intelov compiler je tudi tu assembler skoraj nesmiselno rabiti. Če pa pišete assembler na nivoju 386/387 je pa sploh brezveze. Sam sem napisal preproste integer algoritme in v 50% primerih me je compiler nabil (večinoma, ker nisem vedel da so shift/rotate inštrukcije zelo počasne).
Zgodovina sprememb…
- spremenil: mercury ()
snow ::
lea does the trick.
rotate/shift je sploh počasen na prvih verzijah P4 :)
rotate/shift je sploh počasen na prvih verzijah P4 :)
Random mutation plus nonrandom cumulative natural selection - Richard Dawkins
Senitel ::
Za SSE potrebuješ 16 bajtno poravnavo (ne 16 bitov) prednost je predvsem v "load" operacijah. SSE je običajno dobro napisat na roke (oziroma z intrinsic funkcijami). Vsaj Visual Studio 2003 recimo generira precej obupno SSE kodo...
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | Digitalna evolucija (strani: 1 2 3 4 … 26 27 28 29 )Oddelek: Znanost in tehnologija | 75473 (25642) | pietro |
| » | Funkcija z logičnimi operaterji.... (strani: 1 2 )Oddelek: Programiranje | 5499 (4845) | CaqKa |
| » | Generatorji praštevilOddelek: Znanost in tehnologija | 3825 (2729) | Phil |
| » | Petaflopsu naproti (strani: 1 2 3 )Oddelek: Novice / Procesorji | 8793 (8793) | Marjan |
| » | kako definirtati prasteviloOddelek: Programiranje | 3784 (3589) | ooux |