Forum » Programiranje » [fork] Apache C module vs. Java
[fork] Apache C module vs. Java
Brane2 ::
Se je kdo tu že drugače lotil zadeve ?
Mel sem v mislih pisanje modula za apache v Cju...
Mel sem v mislih pisanje modula za apache v Cju...
On the journey of life, I chose the psycho path.
jype ::
Zakaj bi pa kdo želel kaj takega?
Če nujno potrebuješ hitrost, potem je Java the way to go. Bistveno lažji debugging, bistveno bolj udobna podpora threadingu in bistveno več razmeroma dobro napisane obstoječe krame (SQL connection pooling driverji, XML parserji, templating knjižnice in tako dalje).
Če pa imaš rad eksotične rešitve, potem je pa lisp the way to go. Močan in hiter za popenit, pa noben ga ne zna prebrat, kar zagotavlja boljši vendor lock-in kot monopol :)
Če nujno potrebuješ hitrost, potem je Java the way to go. Bistveno lažji debugging, bistveno bolj udobna podpora threadingu in bistveno več razmeroma dobro napisane obstoječe krame (SQL connection pooling driverji, XML parserji, templating knjižnice in tako dalje).
Če pa imaš rad eksotične rešitve, potem je pa lisp the way to go. Močan in hiter za popenit, pa noben ga ne zna prebrat, kar zagotavlja boljši vendor lock-in kot monopol :)
Brane2 ::
Če bi bil Apache pisan v Lispu, potem bi bilo to nekak zanimivo, pa ni.
C modul se mi zdi vsaj tako na prvi uč zanimivi, ker bi bila ta rešitev kompaktna in hitra. Za normalne razmere verjetno celo tako hitra, da se ne bi sekiral okrog threadinga.
Odpadla bi celotan komunikacija apache--interpreter itd, ki je potrebna pri klasični rešitvi s PHPjem ali čim podobnim. Znalo bi se celoz zgoditi, da bi bila določena dinamična vsebina genrerirana hitreje od statične.
Našell sem nekaj o pisanju modulov, se bom malo pozabaval s tem.
C modul se mi zdi vsaj tako na prvi uč zanimivi, ker bi bila ta rešitev kompaktna in hitra. Za normalne razmere verjetno celo tako hitra, da se ne bi sekiral okrog threadinga.
Odpadla bi celotan komunikacija apache--interpreter itd, ki je potrebna pri klasični rešitvi s PHPjem ali čim podobnim. Znalo bi se celoz zgoditi, da bi bila določena dinamična vsebina genrerirana hitreje od statične.
Našell sem nekaj o pisanju modulov, se bom malo pozabaval s tem.
On the journey of life, I chose the psycho path.
jype ::
Brane2> Znalo bi se celoz zgoditi, da bi bila določena dinamična vsebina genrerirana hitreje od statične.
O tem ne more biti dvoma. Če ti ni treba po podatke na disk, boš tako prej.
Vprašanje pa je, čemu apache? Čemu C?
Obstajajo boljši in močnejši sistemi. Lighttpd in nginx, vsebino precej manj rizično generira že omenjena Java...
Kompaktnost C kode ne odtehta tega, da ti C koda UBIJE celoten httpd, če je karkoli narobe.
O tem ne more biti dvoma. Če ti ni treba po podatke na disk, boš tako prej.
Vprašanje pa je, čemu apache? Čemu C?
Obstajajo boljši in močnejši sistemi. Lighttpd in nginx, vsebino precej manj rizično generira že omenjena Java...
Kompaktnost C kode ne odtehta tega, da ti C koda UBIJE celoten httpd, če je karkoli narobe.
Brane2 ::
Vprašanje pa je, čemu apache? Čemu C? Obstajajo boljši in močnejši sistemi. Lighttpd in nginx, vsebino precej manj rizično generira že omenjena Java...
Res je. Vendar je v tem primeru ozko grlo dokumentacija.
Za Apacheja sem našel nekaj, čez lighttpd se ravnos sedaj prebijam.
Obstajajo boljši in močnejši sistemi. Lighttpd in nginx, vsebino precej manj rizično generira že omenjena Java...
če misliš močnejši kot lažji za razvoj kode, potem gotovo. Če misliš močnejši v smislu hitrejši, bolj primerni visokim bremenom, potem ne verjamem.
Java potrebuje interpreter bytecodea in tako ni kaj dosti boljša od recimo pythona.
Kompaktnost C kode ne odtehta tega, da ti C koda UBIJE celoten httpd, če je karkoli narobe.
Zato ti pa ni treba naredit vsega tam, mogoče le "low level/high bandwidth" dele...
Apachejeva struktrua je naravnost optimalna za kaj takega, saj je v bistvu sam kup patcheov - modulov ( "A-patche")....
On the journey of life, I chose the psycho path.
jype ::
Brane2> Java potrebuje interpreter bytecodea in tako ni kaj dosti boljša od recimo pythona.
Hja... Java _NI_ interpretiran jezik.
Java je enako hitra kot C, za vse praktične pomene besede "enako hitra". Le da je manj nerodna za uporabo, še posebej v okoljih, kjer so vhodni podatki lahko dobesedno "svašta".
Hja... Java _NI_ interpretiran jezik.
Java je enako hitra kot C, za vse praktične pomene besede "enako hitra". Le da je manj nerodna za uporabo, še posebej v okoljih, kjer so vhodni podatki lahko dobesedno "svašta".
Brane2 ::
In kaj je potem bytecode interpreter zanjo ?
Ja, kao source file skompajlaš in potem dobiš kao binary.
Ki ga poženeš na bytecode interpreterju.
Ta bytecode je v bistvu strojna koda za simulirani 8-bitni java procesor.
Vse skupaj je ene tolk hitro kot bi bil COmmodore64 emulator, če bi mu dodal maljardo native knjižnic za vse od networkinga do Opengla in vse vmes.
Ja, kao source file skompajlaš in potem dobiš kao binary.
Ki ga poženeš na bytecode interpreterju.
Ta bytecode je v bistvu strojna koda za simulirani 8-bitni java procesor.
Vse skupaj je ene tolk hitro kot bi bil COmmodore64 emulator, če bi mu dodal maljardo native knjižnic za vse od networkinga do Opengla in vse vmes.
On the journey of life, I chose the psycho path.
kopernik ::
Ni res, določene implementacije javanskih strežnikov so v zadnjih letih dovolj hitre, da zmorejo hkrati prebaviti več http konekcij kot apache. Seveda vsi vemo, da benchmarki pogosto niso bogvekaj merodajni, zato bolje da takoj nehamo. Naj bo dovolj, če povem, da par tisoč hkratnih konekcij ni več tak grozen problem za strežnik, napisan v Javi.
Ampak, vprašanje če sploh kdo na tem forumu uspe prodati spletno aplikacijo, ki mora zadostiti tisočim hkratnim userjem, zato tale debata o hitrosti po moje niti ni toliko pomembna. Pomembnejše je to, kaj človek konkretno potrebuje in mnogokrat se ugotovi, da je spletni strežnik zadnja stvar, ki bi bila ozko grlo.
Ampak, vprašanje če sploh kdo na tem forumu uspe prodati spletno aplikacijo, ki mora zadostiti tisočim hkratnim userjem, zato tale debata o hitrosti po moje niti ni toliko pomembna. Pomembnejše je to, kaj človek konkretno potrebuje in mnogokrat se ugotovi, da je spletni strežnik zadnja stvar, ki bi bila ozko grlo.
jype ::
Nehamo lahko o hitrosti apache vs. Java spletni strežnik (ki je seveda hitrejši na sodobnem hardveru, ker sodoben hardver pač ni več 8086 pri takem in takem taktu).
Brane2> Ja, kao source file skompajlaš in potem dobiš kao binary.
A daj no. Skompajlaš čisto pravi source in dobiš čisto pravi binary. Ni bytecode nič bolj in nič manj kot x86 machine code, samo da je to pač JVM machine code.
JVM pa pač ni interpreter, temveč VM - razlika je za programerja, ki se ukvarja z razvojem aplikacij, kjer je zmogljivost kritična, zelo očitna.
Seveda je za slovenski trg tudi Python dovolj dober.
Brane2> Ja, kao source file skompajlaš in potem dobiš kao binary.
A daj no. Skompajlaš čisto pravi source in dobiš čisto pravi binary. Ni bytecode nič bolj in nič manj kot x86 machine code, samo da je to pač JVM machine code.
JVM pa pač ni interpreter, temveč VM - razlika je za programerja, ki se ukvarja z razvojem aplikacij, kjer je zmogljivost kritična, zelo očitna.
Seveda je za slovenski trg tudi Python dovolj dober.
Brane2 ::
JVM pa pač ni interpreter, temveč VM - razlika je za programerja, ki se ukvarja z razvojem aplikacij, kjer je zmogljivost kritična, zelo očitna.
V bistvu neke velike razlike ni. Zadeva je nekaj podobnega recimo kakem Qemuju. Ta ti tudi odsimulira lahko tak ali drugačen stroj skupaj s procesorjem.
Ne moreš pa za to zadevo reči,d a lahko laufa približno tako hitro kot bi native.
Ja, s premnogimi knjižnicami lahko skušaš povečati del časa, ki ga CPU prebije v native režimu, a čim padeš izven tega, si v "ZX Spectrum emulatorju"
.Če bi bila Java primerljivo hitra Cju, potem bi nekdo že naredil kak Linux kernel v njej.
Pa je frka že pri takih zadevah, kjer CPU emulira lastno kodo nek del časa, del pa prebije native. Recimo pri vmwareu in celo dosemuju na AMD64.
Celo navaden DOS se lahko opazno vleče na mojem 3GHz 6000+ z brdom keša in hitrim RAMom.
On the journey of life, I chose the psycho path.
Brane2 ::
A daj no. Skompajlaš čisto pravi source in dobiš čisto pravi binary.
Ki ga potem "izvajaš" na imaginarnem Java CPUju...
On the journey of life, I chose the psycho path.
jype ::
Brane2> Ki ga potem "izvajaš" na imaginarnem Java CPUju...
Ja.
Pa poskusiva:
test.c
#include <stdio.h>
int main(void) {
int i, j;
for (i=0; i<2000000000; i++) {if (i%2==0) j=i+1;}
printf("%d\n", j);
}
test.java
public class test {
public static void main(String[] args) {
int i=0, j=0;
for (i=0;i<2000000000;i++) {if (i%2==0) j=i+1;}
System.out.println(String.valueOf(j));
}
}
gcc (switche lahko uporabiš poljubne, če meniš, da obvladaš optimizacijo, jaz sem poizkusil samo -O2 in -O6) -o test test.c
time ./test
real 0m6.383s
user 0m6.376s
sys 0m0.004s
javac test.java
time java test
real 0m3.094s
user 0m3.048s
sys 0m0.016s
Z Javo dobim (kubuntu 7.10 x86_64, sun java 1.6.0_04, idle q6600 mašina) konsistentno boljši rezultat.
Update: z gcc -funroll-loops dobim
real 0m4.847s
user 0m4.836s
sys 0m0.000s
Še vedno počasneje od Jave, a napredek je očiten :)
Ja.
Pa poskusiva:
test.c
#include <stdio.h>
int main(void) {
int i, j;
for (i=0; i<2000000000; i++) {if (i%2==0) j=i+1;}
printf("%d\n", j);
}
test.java
public class test {
public static void main(String[] args) {
int i=0, j=0;
for (i=0;i<2000000000;i++) {if (i%2==0) j=i+1;}
System.out.println(String.valueOf(j));
}
}
gcc (switche lahko uporabiš poljubne, če meniš, da obvladaš optimizacijo, jaz sem poizkusil samo -O2 in -O6) -o test test.c
time ./test
real 0m6.383s
user 0m6.376s
sys 0m0.004s
javac test.java
time java test
real 0m3.094s
user 0m3.048s
sys 0m0.016s
Z Javo dobim (kubuntu 7.10 x86_64, sun java 1.6.0_04, idle q6600 mašina) konsistentno boljši rezultat.
Update: z gcc -funroll-loops dobim
real 0m4.847s
user 0m4.836s
sys 0m0.000s
Še vedno počasneje od Jave, a napredek je očiten :)
Brane2 ::
Seveda 99,999% časa preživiš v library rutini, ki valjda laufa native in ne v java/C kodi.
To samo kaže na to, da je pač ta call v Java implementaciji bolj upadenan, to je vse.
AH, zajeb- disregard.
To samo kaže na to, da je pač ta call v Java implementaciji bolj upadenan, to je vse.
AH, zajeb- disregard.
On the journey of life, I chose the psycho path.
jype ::
Brane2> To samo kaže na to, da je pač ta call v Java implementaciji bolj upadenan, to je vse.
To kaže, da Jave nič ne obvezuje, da je počasnejša od primerljivega C programa.
Gre seveda za tradeoff med programerjevim časom in učinkovitostjo. Jaz trdim, da je razmerje močno v prid Javi za današnje real-world aplikacije. Včasih je celo v prid Pythonu, čeravno je bistveno počasnejši:
test.py
#!/usr/bin/env python
for i in xrange(2000000000):
if i % 2 == 0:
j = i + 1
print j
time python test.py
1999999999
real 7m52.043s
user 7m50.945s
sys 0m0.568s
Noro, kolk mam hitr hardver :)
To kaže, da Jave nič ne obvezuje, da je počasnejša od primerljivega C programa.
Gre seveda za tradeoff med programerjevim časom in učinkovitostjo. Jaz trdim, da je razmerje močno v prid Javi za današnje real-world aplikacije. Včasih je celo v prid Pythonu, čeravno je bistveno počasnejši:
test.py
#!/usr/bin/env python
for i in xrange(2000000000):
if i % 2 == 0:
j = i + 1
print j
time python test.py
1999999999
real 7m52.043s
user 7m50.945s
sys 0m0.568s
Noro, kolk mam hitr hardver :)
Brane2 ::
V tistem tvojem trivialnem primerčku Java sicer res nabriše gcc, ampak očitno je to zaradi kriminalno slabih optimizacij v gccju.
Že pri relativno majhnih spremembah je gcc pri meni 2x hitrejši, pa verejtno to lahko spravim še bistveno višje.
NO, zanimivo se bo pozabavat s tem ko bo čas.
Je pa vsaj v tem primeru Java presenetljivo hitra kljub vsemu.
Že pri relativno majhnih spremembah je gcc pri meni 2x hitrejši, pa verejtno to lahko spravim še bistveno višje.
NO, zanimivo se bo pozabavat s tem ko bo čas.
Je pa vsaj v tem primeru Java presenetljivo hitra kljub vsemu.
On the journey of life, I chose the psycho path.
Brane2 ::
Noro, kolk mam hitr hardver :)
Najbrž bi bil še hitrejši, če bi tudi python prej spustil skozi "compiler", tako kot si javo ?
On the journey of life, I chose the psycho path.
Loki ::
probaj c program narediti se s ms ali intel compilerjem, pa prilimaj rezultate.
I left my wallet in El Segundo
jype ::
Brane2> Najbrž bi bil še hitrejši, če bi tudi python prej spustil skozi "compiler", tako kot si javo ?
"Saj sem ga". Python vedno najprej naredi bytecode, zapiše .pyc datoteko in potem reč uporabi. Ampak ni nič hitrejša, razen tega da je ni treba parsat.
Loki> probaj c program narediti se s ms ali intel compilerjem, pa prilimaj rezultate.
Žal teh prevajalnikov nimam pri roki. Naj nekdo stori kdo drug - kodo lahko smatrate kot public domain :)
"Saj sem ga". Python vedno najprej naredi bytecode, zapiše .pyc datoteko in potem reč uporabi. Ampak ni nič hitrejša, razen tega da je ni treba parsat.
Loki> probaj c program narediti se s ms ali intel compilerjem, pa prilimaj rezultate.
Žal teh prevajalnikov nimam pri roki. Naj nekdo stori kdo drug - kodo lahko smatrate kot public domain :)
Brane2 ::
Hvala za info.
Tole mi je odprlo oči.
Nisem si mislil da je gcc tako beden za te zadeve. Ajde, da fali kje kak loop naredit približno optimalno, to je jasno, ampak da je tako slab, da mu je java konkurenca, to si nisem mislu.
Strojna koda, ki jo da od sebe je tako bloatana, da se to vidi že na prvi pogled nanjo.
Sem pobrskal po netu, pa so mnogi presenečeni ob tem, pa mnogi od njihovih testov sploh niso tako enostavni.
Glede java http strežnikov, kaj je v tej masi ponudbe pametnega ?
Sem si pocahnil tri kadidate za bližji ogled- AsyncWeb ( brzina, multrithreaded, nonblocking ), Jetty (simpl, baje relativno hiter), jigsaw ( pedigre- je W3Cjev), Caucho resin ( simpl, noro ime )
Kak drug predlog ?
Tole mi je odprlo oči.
Nisem si mislil da je gcc tako beden za te zadeve. Ajde, da fali kje kak loop naredit približno optimalno, to je jasno, ampak da je tako slab, da mu je java konkurenca, to si nisem mislu.
Strojna koda, ki jo da od sebe je tako bloatana, da se to vidi že na prvi pogled nanjo.
Sem pobrskal po netu, pa so mnogi presenečeni ob tem, pa mnogi od njihovih testov sploh niso tako enostavni.
Glede java http strežnikov, kaj je v tej masi ponudbe pametnega ?
Sem si pocahnil tri kadidate za bližji ogled- AsyncWeb ( brzina, multrithreaded, nonblocking ), Jetty (simpl, baje relativno hiter), jigsaw ( pedigre- je W3Cjev), Caucho resin ( simpl, noro ime
)Kak drug predlog ?
On the journey of life, I chose the psycho path.
Red_Mamba ::
Apache TomCat?
[st.slika https://img.shields.io/badge/Slo-Tech-green.svg test]
Linkedin >> http://goo.gl/839Aua
Mamba's Crypto & ICO's: https://t.me/joinchat/AAAAAExTkO4P4UDy0fIZdg
Linkedin >> http://goo.gl/839Aua
Mamba's Crypto & ICO's: https://t.me/joinchat/AAAAAExTkO4P4UDy0fIZdg
Brane2 ::
Mogoče res. Na prvi uč ni videti kaj prav posebno specializiran, razen verjetno tega, da je mahnjen na ustreznost standardom in da ima zaradi vidnosti ( apache.org) verjetno za seboj kar nekaj razvijalcev.
Zanimivo je, da ni najti ptimerjave Tomcat vs Asyncweb.
No, kakorkoli že, prvi kriterij je razumljivost zadeve in ne njene performanse, ker če je verjeti materialom na netu je vsaka od njih več ko zadosti hitra za moje potrebe.
Se bomo pozabavali...
Zanimivo je, da ni najti ptimerjave Tomcat vs Asyncweb.
No, kakorkoli že, prvi kriterij je razumljivost zadeve in ne njene performanse, ker če je verjeti materialom na netu je vsaka od njih več ko zadosti hitra za moje potrebe.
Se bomo pozabavali...
On the journey of life, I chose the psycho path.
Sergio ::
Brane2: S Tomcatom6 ti APR konektor prinese nonblocking IO vse do kamor mu standard pusti, kar pomeni da so določene stvari zaradi precej omejujoče JSP specifikacije še vedno blocking. Dobra stvar je pa ta, da je Tomcat compliant z JSP specsi :).
Asyncweb mi pa izgleda na prvi pogled precej bogi. Dokumentacija je švoh, pa nikjer nisem še zasledil da bi stvar imela kakšen resen deployment.
Če hočeš iti vmes, uporabi Jetty. Na tvojem mestu bi pa ostal na Tomcatu :).
Asyncweb mi pa izgleda na prvi pogled precej bogi. Dokumentacija je švoh, pa nikjer nisem še zasledil da bi stvar imela kakšen resen deployment.
Če hočeš iti vmes, uporabi Jetty. Na tvojem mestu bi pa ostal na Tomcatu :).
Tako grem jaz, tako gre vsak, kdor čuti cilj v daljavi:
če usoda ustavi mu korak,
on se ji zoperstavi.
če usoda ustavi mu korak,
on se ji zoperstavi.
kopernik ::
Jaz bi kar Jetty priporočal. Majhen in svinjsko hiter, obenem pa se tudi dobro obnaša pod stresom. A misliš razvijati javanske web aplikacije ?
Brane2 ::
Neki tacga sem mel v mislih, ja.
Bom prebral zadeve, probal in poročam...
Bom prebral zadeve, probal in poročam...
On the journey of life, I chose the psycho path.
kopernik ::
Za razvoj bi priporočal netbeans IDE v kombinaciji z maven-om (ki je po funkcionalnosti nekakšen kombo build orodja in linux packet managerja). Mislim, da imajo zadnje verzije netbeansa dobro poštimano maven integracijo.
Opozoril bi te še na izredno razdrobljenost javanskega web "razvojnega cozmosa". Obstaja na desetine (pa tukaj niso vsi našteti :-)) open-source frameworkov, ki ti vsak na svoj način lajšajo razvoj web aplikacij. Kaj izbrati ? Odvisno od potreb :-) Mislim pa, da ne moreš dosti zgrešiti, če izbereš enedga izmed naslednjih : spring MVC, webwork, tapestry, google web toolkit, rife ali stripes. Če ti ustreza all-in-one pristop, podoben ruby-on-rails, si poglej še trails (nekakšen klon RoR-a in NakedObjects-ov).
Opozoril bi te še na izredno razdrobljenost javanskega web "razvojnega cozmosa". Obstaja na desetine (pa tukaj niso vsi našteti :-)) open-source frameworkov, ki ti vsak na svoj način lajšajo razvoj web aplikacij. Kaj izbrati ? Odvisno od potreb :-) Mislim pa, da ne moreš dosti zgrešiti, če izbereš enedga izmed naslednjih : spring MVC, webwork, tapestry, google web toolkit, rife ali stripes. Če ti ustreza all-in-one pristop, podoben ruby-on-rails, si poglej še trails (nekakšen klon RoR-a in NakedObjects-ov).
Sergio ::
kopernik: Nak, build your own, ker bos le tako maksimiziral performance. :)
Za IDE pa osebno priporocam Eclipse.
Za IDE pa osebno priporocam Eclipse.
Tako grem jaz, tako gre vsak, kdor čuti cilj v daljavi:
če usoda ustavi mu korak,
on se ji zoperstavi.
če usoda ustavi mu korak,
on se ji zoperstavi.
jype ::
Se pridružujem priporočilu in zagotavljam, da je delo z Javo brez integriranega okolja neznosno. To ni Python in ni C, da bi lahko človek učinkovito pisal kodo v vimu :)
Seveda se dobi vim plugin za eclipse kot tudi za večino ostalih IDEjev.
Seveda se dobi vim plugin za eclipse kot tudi za večino ostalih IDEjev.
Brane2 ::
Vendarle pa ni vse tako rožnato.
Tale tvoj primerčekl v javi resda scompilan potrebuje le kakih 400 byteov, vendar ko ga štartaš, skupaj s pripadajočim java VMom zavzame norih5.6MiB
C koda pa te "stane" samo 6 KiB, torej 1000x manj.
Tudi recimo kak Netbeans ima nor meory footpint - 400 MB za štartan program- brez kakega odprtega projekta !
Pa odpira se celo večnost in vleče ko melasa.
Po drugi strani se mi recimo Code::blocks odpre v par sekundah in zavzame 25MiB idle...
Tale tvoj primerčekl v javi resda scompilan potrebuje le kakih 400 byteov, vendar ko ga štartaš, skupaj s pripadajočim java VMom zavzame norih5.6MiB
C koda pa te "stane" samo 6 KiB, torej 1000x manj.
Tudi recimo kak Netbeans ima nor meory footpint - 400 MB za štartan program- brez kakega odprtega projekta !
Pa odpira se celo večnost in vleče ko melasa.
Po drugi strani se mi recimo Code::blocks odpre v par sekundah in zavzame 25MiB idle...
On the journey of life, I chose the psycho path.
kopernik ::
Ne vem, meni dela dost hitro. Eclipse in intellij pa tudi (pač še eni dve drugi IDE okolji). Poraba rama pa ni majhna, to je res. Tako pri Eclipsu kot pri Netbeansu imam cca. 250 mega, oboje z odprtim manjšim projektom, sme ravnokar preveril. Pri velikih projektih pa gre še več rama, jasno. Ampak to me ne moti, ker imam na svoji razvojni mašini 2 giga, s čimer lahko pokrijem IDE in par pognanih strežnikov za testiranje.
Ja, to je nekako logično. Po mojih izkušnjah in tudi ob spremljanju mnogih aplikacij v produkciji, je sicer bolj važna hitrost in robustnost kot poraba rama golega VM. Če aplikacija (napisana v poljubnem jeziku) zaradi npr. streženja 1000 hkratnim uporabnikom porabi cca. 1 giga rama, pač pri Javi prišteješ še teh par mega za VM, pri C-ju pa ne.
Tale tvoj primerčekl v javi resda scompilan potrebuje le kakih 400 byteov, vendar ko ga štartaš, skupaj s pripadajočim java VMom zavzame norih5.6MiB
Ja, to je nekako logično. Po mojih izkušnjah in tudi ob spremljanju mnogih aplikacij v produkciji, je sicer bolj važna hitrost in robustnost kot poraba rama golega VM. Če aplikacija (napisana v poljubnem jeziku) zaradi npr. streženja 1000 hkratnim uporabnikom porabi cca. 1 giga rama, pač pri Javi prišteješ še teh par mega za VM, pri C-ju pa ne.
Brane2 ::
Kot sem jaz probaval zadeve, sem za vsako instanco programa porabil novih 5.6 MB za novo kopijo VM-a.
Ne vem, mogoče se da zadeve urediti tudi drugače.
Vem,da C program lahko napišeš tako, da pri forkanju stvar dela COW ( Copy On Write ) in zavzame extra prostor samo za dele programa, ki se med kopijami razlikujejo...
Poleg tega najeda nestabilnost platform in njihova odvisnost od temeljev- VM engineov.
Najprej sem porabil pol dneva, da sem usposobil Netbeanse, nato sem emergeal še novi Eclipse in od takrat mi eclipse ne dela več. Probal sem ga na sto načinov- tako emergeanega kot ročno inštaliranega, z vsemi mogočimi verzijami VM-a, a ne gre. Tole z Javo očitno ni čisto tako kot na Sunovih reklamnih prospektih.
Ne vem, mogoče se da zadeve urediti tudi drugače.
Vem,da C program lahko napišeš tako, da pri forkanju stvar dela COW ( Copy On Write ) in zavzame extra prostor samo za dele programa, ki se med kopijami razlikujejo...
Poleg tega najeda nestabilnost platform in njihova odvisnost od temeljev- VM engineov.
Najprej sem porabil pol dneva, da sem usposobil Netbeanse, nato sem emergeal še novi Eclipse in od takrat mi eclipse ne dela več. Probal sem ga na sto načinov- tako emergeanega kot ročno inštaliranega, z vsemi mogočimi verzijami VM-a, a ne gre. Tole z Javo očitno ni čisto tako kot na Sunovih reklamnih prospektih.
On the journey of life, I chose the psycho path.
kopernik ::
Ja, ampak saj ne zaženeš n instanc programa. Če govorimo o strežnikih, imaš eno instanco, ki pa ima več niti za paralelno procesiranje mnogih requestov. Če sploh prav razumem, kaj hočeš povedati.
Pri eclipsu pa moraš paziti, če imaš slučajno 64bit linux, ker se je IBM odločil, da default javina gui knjižnica (swing) ni dovolj dobra in so naredili svojo (swt), ki izkorišča native widgete operacijskega sistema. Zato moraš downloadati eclipse s podporo za 64 bit, sicer aplikacije niti zagnati ne moreš. Ni SUN nič kriv ... če pa imaš 32 bit linux, potem me čudi, da ne dela, ker gre za navaden zip ali tar arhiv, brez kakšne posebne instalacije.
In valjda, če poizkušaš nekaj novega, ne bo steklo gladko iz prve. Tudi jaz se še kar spotikam ob emacsu in Lispu ... ne vem, mogoče je bolje, da vse skupaj pustiš pri miru in ostaneš na C-ju, ker kot sem že rekel, močno dvomim, da bo web server ozko grlo, zato uporabi tisto, kjer se dobro počutiš (C, perl, python, php, itd.).
Pri eclipsu pa moraš paziti, če imaš slučajno 64bit linux, ker se je IBM odločil, da default javina gui knjižnica (swing) ni dovolj dobra in so naredili svojo (swt), ki izkorišča native widgete operacijskega sistema. Zato moraš downloadati eclipse s podporo za 64 bit, sicer aplikacije niti zagnati ne moreš. Ni SUN nič kriv ... če pa imaš 32 bit linux, potem me čudi, da ne dela, ker gre za navaden zip ali tar arhiv, brez kakšne posebne instalacije.
In valjda, če poizkušaš nekaj novega, ne bo steklo gladko iz prve. Tudi jaz se še kar spotikam ob emacsu in Lispu ... ne vem, mogoče je bolje, da vse skupaj pustiš pri miru in ostaneš na C-ju, ker kot sem že rekel, močno dvomim, da bo web server ozko grlo, zato uporabi tisto, kjer se dobro počutiš (C, perl, python, php, itd.).
Brane2 ::
Saj nisem rekel, da bi moralo iti gladko ali da mi je kdo dožan odškodnino denimo.
Samo opažam zadeve.
Kar se tiče nasveta o Eclipseu: hvala- to dela.
Je*emti, zakaj opozorilo o tem ni z velikimi črkami na download strani ?
Zanimivo je, da je ta stvar bazirana na Javi in bi človek rekel, da ni vezana na določen stroj, pa kljub temu poženeš v bistvu klasični executable.
Malo neintuitivno.
Sem pa pregooglal cel net v iskanju rešitve in probal maljon stvari, tole mi pa ni padlo na pamet.
Tudi download stran je totalno kretenska.
Če ob imenu paketa klikneš na ustreno izbiro ("Windows/Linux/Mac OSX"), dobiš na Linuxu 32-bitno verzijo ( sklepajoč po imenu targzipa), če pa klikneš direktno na ime paketa, dobiš x86_64 verzijo.
Samo opažam zadeve.
Kar se tiče nasveta o Eclipseu: hvala- to dela.
Je*emti, zakaj opozorilo o tem ni z velikimi črkami na download strani ?
Zanimivo je, da je ta stvar bazirana na Javi in bi človek rekel, da ni vezana na določen stroj, pa kljub temu poženeš v bistvu klasični executable.
Malo neintuitivno.
Sem pa pregooglal cel net v iskanju rešitve in probal maljon stvari, tole mi pa ni padlo na pamet.
Tudi download stran je totalno kretenska.
Če ob imenu paketa klikneš na ustreno izbiro ("Windows/Linux/Mac OSX"), dobiš na Linuxu 32-bitno verzijo ( sklepajoč po imenu targzipa), če pa klikneš direktno na ime paketa, dobiš x86_64 verzijo.
On the journey of life, I chose the psycho path.
Zgodovina sprememb…
- spremenil: Brane2 ()
Brane2 ::
Pa še nekaj.
Stvar naj bi bila bazirana na javi. Kljub temu pa imaš že v njenem root direkktoriju classic executable in celo dinamično knjižnico.
Tako na uč bi človek rekel, da lahko pričakuje da je provider zapakiral vse v samostojen paket.
Mislim, če so že executablei in knjižnice not, potem je logično da so vsi, a ne ?
Pa očitno ni.
Stvar naj bi bila bazirana na javi. Kljub temu pa imaš že v njenem root direkktoriju classic executable in celo dinamično knjižnico.
Tako na uč bi človek rekel, da lahko pričakuje da je provider zapakiral vse v samostojen paket.
Mislim, če so že executablei in knjižnice not, potem je logično da so vsi, a ne ?
Pa očitno ni.
On the journey of life, I chose the psycho path.
Zgodovina sprememb…
- spremenil: Brane2 ()
kopernik ::
Eclipse je pač posebna aplikacija, narejena na poseben način. Saj mnogi kritizirajo tak pristop, ampak IBM (gonilna sila za projektom eclipse.org) pač dela po svoje. Tudi ime projekta je po svoje zbadanje Suna :-) Sončni mrk, recimo ...
Ampak, ker je 95% userjev na win desktopih, ta svojeglavost IBMa niti ne pride do izraza, saj je Eclipse tudi nasplošno hudo optimiziran ravno za win mašine. Na linuxu imam boljše izkušnje z Intellij okoljem (pure java, tako kot netbeans), manj bugov in hitrejše delovanje, res pa je, da ni open source.
Ampak, ker je 95% userjev na win desktopih, ta svojeglavost IBMa niti ne pride do izraza, saj je Eclipse tudi nasplošno hudo optimiziran ravno za win mašine. Na linuxu imam boljše izkušnje z Intellij okoljem (pure java, tako kot netbeans), manj bugov in hitrejše delovanje, res pa je, da ni open source.
CCfly ::
ccfly@galadriel ~/Projects/play $ time ./test
1999999999
real 0m4.830s
user 0m4.819s
sys 0m0.004s
ccfly@galadriel ~/Projects/play $ time java test
1999999999
real 0m4.872s
user 0m4.800s
sys 0m0.034s
edit:
C++ iostream je v povprečju še za pol sekunde hitrejši, vendar gre za premajhne razlike, za dobro oceno.
Pri zaporednih zagonih, se javanski program v povprečju izvaja približno sekundo dlje.
---
Target: x86_64-pc-linux-gnu
gcc version 4.1.2 (Gentoo 4.1.2 p1.0.1) ... -O2
Java™ 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
Java HotSpot™ 64-Bit Server VM (build 1.5.0_12-b04, mixed mode)
1999999999
real 0m4.830s
user 0m4.819s
sys 0m0.004s
ccfly@galadriel ~/Projects/play $ time java test
1999999999
real 0m4.872s
user 0m4.800s
sys 0m0.034s
edit:
C++ iostream je v povprečju še za pol sekunde hitrejši, vendar gre za premajhne razlike, za dobro oceno.
Pri zaporednih zagonih, se javanski program v povprečju izvaja približno sekundo dlje.
---
Target: x86_64-pc-linux-gnu
gcc version 4.1.2 (Gentoo 4.1.2 p1.0.1) ... -O2
Java™ 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
Java HotSpot™ 64-Bit Server VM (build 1.5.0_12-b04, mixed mode)
"My goodness, we forgot generics!" -- Danny Kalev
Zgodovina sprememb…
- spremenilo: CCfly ()
CCfly ::
Kar se tiče izvirnega vprašanja, pa bi moral Gandalfar vsaj povedati, kaj želi narediti.
"My goodness, we forgot generics!" -- Danny Kalev
jype ::
CCfly> Java™ 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
Tale Java je pa "stara".
Dodaj eno nulo pri vakem loopu in poskusi še enkrat, da zmanjšaš efekt startupa JVMja, magar.
Tale Java je pa "stara".
Dodaj eno nulo pri vakem loopu in poskusi še enkrat, da zmanjšaš efekt startupa JVMja, magar.
Brane2 ::
Sem po dolgem času spet padel v to temo in se spomnil primerčka.
Kot se izkaže, gre za precej močno izražen corner case, kjer na majhnem primeru izkoriščaš nerodnost gccja, ki kar ne ve, kako bi se lotil zanke.
Če pa ročno malenkost popraviš stvari in razdeliš loop na dva, pa gcc pride na svoje:
#include /stdio.h/
int main(void) {
int i, j;
for ( i=1; i < 2000000000; i = i + 2 ) { j = 0 ; };
for ( i=0; i < 2000000000; i = i + 2 ) { j = i + 1 ; };
printf("%d\n", j);
};
vs
public class test {
public static void main(String[] args) {
int i=0, j=0;
for ( i=1; i < 2000000000; i = i + 2 ) { j = 0 ; };
for ( i=0; i < 2000000000; i = i + 2 ) { j = i + 1 ; };
System.out.println(String.valueOf(j));
}
}
ti da naslednje rezultate:
gcc brez kakršnihkoli optimizacij:
gcc z najosnovnejšimi optimizacijami:
gcc -O1 -pipe -o tt test.c
brane2@localhost ~/TEMP $ time ./tt
1999999999
real 0m0.001s
user 0m0.000s
sys 0m0.000s
Se pravi, tu je gcc 200+ krat hitrejši od jave.
Hecno je tudi to, da lahhko forloop milijonkrat podaljšam, pa se bo pri -O2 izvajal še vedno samo 2 milisekundi...
Kot se izkaže, gre za precej močno izražen corner case, kjer na majhnem primeru izkoriščaš nerodnost gccja, ki kar ne ve, kako bi se lotil zanke.
Če pa ročno malenkost popraviš stvari in razdeliš loop na dva, pa gcc pride na svoje:
#include /stdio.h/
int main(void) {
int i, j;
for ( i=1; i < 2000000000; i = i + 2 ) { j = 0 ; };
for ( i=0; i < 2000000000; i = i + 2 ) { j = i + 1 ; };
printf("%d\n", j);
};
vs
public class test {
public static void main(String[] args) {
int i=0, j=0;
for ( i=1; i < 2000000000; i = i + 2 ) { j = 0 ; };
for ( i=0; i < 2000000000; i = i + 2 ) { j = i + 1 ; };
System.out.println(String.valueOf(j));
}
}
ti da naslednje rezultate:
time java test
1999999999
real 0m0.212s
user 0m0.148s
sys 0m0.028s
gcc brez kakršnihkoli optimizacij:
gcc -O0 -pipe -o tt test.c
brane2@localhost ~/TEMP $ time ./tt
1999999999
real 0m5.314s
user 0m5.136s
sys 0m0.008s
gcc z najosnovnejšimi optimizacijami:
gcc -O1 -pipe -o tt test.c
brane2@localhost ~/TEMP $ time ./tt
1999999999
real 0m0.001s
user 0m0.000s
sys 0m0.000s
Se pravi, tu je gcc 200+ krat hitrejši od jave.
Hecno je tudi to, da lahhko forloop milijonkrat podaljšam, pa se bo pri -O2 izvajal še vedno samo 2 milisekundi...
On the journey of life, I chose the psycho path.
fiction ::
for ( i=1; i < 2000000000; i = i + 2 ) { j = 0 ; };
for ( i=0; i < 2000000000; i = i + 2 ) { j = i + 1 ; };
Ce bi bil jaz optimizator prevajalnika, bi obe zanki vrgel ven in rekel:
j = 2000000000; i = 2000000001 ali nekaj takega. Pri cemer je najbrz za prvo lazje reci, da je ne rabis.
Brane2 ::
Saj.
Cel case je kazal jaco kot enakovredno Cju na podlagi tega, da je javac dojel nekaj, kar je gcc spregledal in tako je java postala enako hitra kot C.
Samo malo potweakan primer je vlogi obrnil in sedaj je gcc bistveno bolje pokrajšal stvar in pokazal parstokrat boljši rezultat.
Cel case je kazal jaco kot enakovredno Cju na podlagi tega, da je javac dojel nekaj, kar je gcc spregledal in tako je java postala enako hitra kot C.
Samo malo potweakan primer je vlogi obrnil in sedaj je gcc bistveno bolje pokrajšal stvar in pokazal parstokrat boljši rezultat.
On the journey of life, I chose the psycho path.
kopernik ::
A PyPy si mogoče že kaj gledal ? Če si zverziran v Pythonu in te skrbi hitrost, je PyPy ena možnost.
Brane2 ::
V bistvu se hecam s C in začenjam nekaj malega z asm dodatki...
On the journey of life, I chose the psycho path.
Brane2 ::
Evo izhoda, ki ga da gcc ob prevodu z "gcc -O3 -pipe -march=native -S -o tt.asm test.c" :
Zadeva samo pripravi par registrov za izpis končnega rezultata in fertik.
Kewl. Stvar očitno ima svoje svetle trenutke.
.file "test.c"
.section .rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "%ld\n"
.text
.p2align 4,,15
.globl main
.type main, @function
main:
.LFB13:
movabsq $1999999999999999, %rsi
movl $.LC0, %edi
xorl %eax, %eax
jmp printf
.LFE13:
.size main, .-main
.section .eh_frame,"a",@progbits
.Lframe1:
.long .LECIE1-.LSCIE1
.LSCIE1:
.long 0x0
.byte 0x1
.string "zR"
.uleb128 0x1
.sleb128 -8
.byte 0x10
.uleb128 0x1
.byte 0x3
.byte 0xc
.uleb128 0x7
.uleb128 0x8
.byte 0x90
.uleb128 0x1
.align 8
.LECIE1:
.LSFDE1:
.long .LEFDE1-.LASFDE1
.LASFDE1:
.long .LASFDE1-.Lframe1
.long .LFB13
.long .LFE13-.LFB13
.uleb128 0x0
.align 8
.LEFDE1:
.ident "GCC: (GNU) 4.2.4 (Gentoo 4.2.4 p1.0)"
.section .note.GNU-stack,"",@progbits
Zadeva samo pripravi par registrov za izpis končnega rezultata in fertik.
Kewl. Stvar očitno ima svoje svetle trenutke.
On the journey of life, I chose the psycho path.
Zgodovina sprememb…
- spremenil: Brane2 ()
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | Yum počasen (disk IO)Oddelek: Operacijski sistemi | 642 (576) | MrStein |
| » | Ker USB kljucekOddelek: Kaj kupiti | 3246 (2438) | Golden eye |
| » | Uspešna faktorizacija RSA-200 in RSA-640Oddelek: Novice / Znanost in tehnologija | 4220 (3385) | CaqKa |
| » | Najhitrejši programski jezik? (strani: 1 2 )Oddelek: Programiranje | 7734 (5554) | Senitel |
| » | int to string v c++Oddelek: Programiranje | 2338 (2066) | OwcA |