"Az Androidra alapozza a jövőt az amerikai T-Mobile"

Linux

"Cole Brodman lelkesedése az Androiddal kapcsolatban azért is meglepő, mert a Microsoft Windows Mobile kapcsán nem hangzottak el ilyen támogató gondolatok, pedig ott is hamarosan jön a 6.5-ös verzió, ami számos új funkcióval és szolgáltatással, új kezelőfelülettel kecsegtet. Így előfordulhat, hogy a világ egyik legnagyobb mobilszolgáltatója hanyagolni fogja a redmondiak megoldásait, s ez a gyártók számára is fontos érv lesz az Android prioritásra emelésében. Kizárólagosságról természetesen nincs szó, hisz Brodman azt is említette, hogy a RIM Blackberry készülékei továbbra is fókuszban maradnak az üzleti területeken."

A teljes cikk itt olvasható.

( Jason v | 2009. 05. 17., v – 14:06 )

Meg tudom érteni.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

( nagy_peter v | 2009. 05. 17., v – 15:30 )

Érthető, hogy erre alapozza, hiszen amit a WM licencen spórol, azzal vagy olcsóbban tudja adni a készüléket, mint a konkurencia, vagy azonos ár mellett magasabb haszonnal. A felhasználók meg elégedettek az új rendszerrel.

( honorshark | 2009. 05. 17., v – 17:31 )

Annyi kerdesem lenne hogy Java alapu az egesz Android (+Linux kernel, etc) ..amennyire en tudom (Wiki/Android.com, stb). Nem tul lassu? Gepen c-hez viszonyitva remesen lassu, rengeteg memoriat eszik. Android miben kulonb?

Symbian pl. nativ C++ ha jol tudom. Nem is meglepo hogy nagyon komoly alkalmazasokat irtak/irnak ra , melyek egy 200mhz-es ARM -on elfutnak. JAVA-bol hiaba probalok futtatni barmi komolyabbat, annak biztos vagy memoria hiany, vagy akadozas/lassu mukodes lesz a vege.

Valaki bennfentes?

Ez mind szep es jo amirol ir.

DE:
- Figyelembe veszi a fejleszto gepet..
>>
Mikor forditok egy C programot, megadhatom hogy milyen processzorra, utasitaskeszletekre optimalizaljon. Miket hasznaljon ki , s miket ne.

- Elsore le kell fordulnia, aztan masodszorra mar gyorsan fut..
>>
Hiaba inditok el egy java alkalmazast, generaltatom gepi kodra, kegyetlen lassu. Asztali gepen. Mobil eszkozon altalaban outofmemory szokott fogadni (igaz "csak" 55mb van benne).

"A másik hátrány, hogy a program futása alatt a JIT által előállított natív kódot tárolni kell a memóriában, emiatt a fizikai memória helyfoglalása lényegesen nagyobb lehet, mint amit egy eleve natív, futattható program esetén tapasztalunk."
>>
A gond hogy nem csak a program, a nativ kod, hanem maga a JAVA is kell hozza. Ami tetemes meretu. De javitsatok ki ha nem igy van. Telefonon nem vagyok benne biztos, bar nekem elohivja , process-kent fut is.

Vegszonak: Nem lattam meg sosem komolyabb alkalmazast ami JAVA-ban irodott. Talan Vuze/Azureus. Bar ott meg a 40% terheles nem tunik tul elfogadhato-nak.

Nem kötekedni akarok, de azt hiszem ez egy elég komoly alkalmazás, és ha jól tudom JAVA-ban lett megírva. Persze biztos, hogy van ugyanerre a célra más nyelvben megírt progi, csak gondoltam mutatok egy ellenpéldát. [egyébként amikor használtam, előszeretettel ette meg az összes memóriát... :) ]

-----------
"Generally, Russian technology assumes dumb machines and smart humans, not the other way around." -- The Russian Tea HOWTO

Jólvan.. Eddig úgy tudtam hogy nem java. Nem is volt ilyen függősége, nem is véltem felfedezni hasonló fájlokat (amik java mivoltra utalnának). Egy része használ java-t, s mivel más írta hogy akkor az egész project JAVA akar lenni... (Abból indultam ki hogy aki hozzászól a szálhoz, az hozzáértő / szaktekintély / fejlesztő, innentől fogva utánajárás nélkül elfogadtam a dolgokat.)

> Nem lattam meg sosem komolyabb alkalmazast ami JAVA-ban irodott.

Ipari szoftware-ek igen nagy szazaleka java-ban irodott. Ezalatt azt kell erteni, hogy ami native kodos progit lattam az mind ilyen 10 eves legacy rendszer volt. Pedig voltam mar egy par mobiltelefon szolgaltatonal. Ezen a teruleten jelenleg nem tudok semmi uj fejlesztesrol ami nem java-ban menne. Remelem ez eleg komoly rendszer neked :D

Altalanossagban nincs JIT compiler telefonon szoval ezt a cikk jelen esetben teljesen irrelevans.
Mondjuk van viszont ehelyett az ARM jazelle java hardveres gyorsitasa, tehat valoszinu ezert annyira megsem lassu a java a telefonon.

Egyebkent az utasitaskezlet dologgal sem ertek igazan egyet itt a cikkben. Manapsag az uj utasitasok szerintem jellemzoen nem olyanok, hogy a fordito magatol okosan tudna oket hasznalni (SSE1/2/3/4, meg ilyenek mint crc32, popcnt), hanem ezeket inkabb assemblybol lehet csak kihasznalni, es akkor meg mar altalaban megirjak tobb cpu modellre ugyanazt a rutint. Szoval a c+asm jo kezekben meggyozodesem szerint biztos gyorsabb mint a java/.NET/stb.

- Use the Source Luke ! -

icc is "elerheto a pistikeknek". egyebkent megnezve ezt a linket(+ a round 1-et es 2-t is, amikre van link) lathato, hogy
ad 1.) a kezzel irt asm kod szignifikansan gyorsabb az icc altal generaltnal; ad 2.) a gcc-svn elegge megkozeliti az icc 10.1.017-et.

amugy rengeteg compiler van rengeteg architekturara (es ezeknek egy jo reszerol valoszinuleg meg sosem hallottal kedves replaced), es ugy velem a gcc messze nem a leghulyebb.

- Use the Source Luke ! -

Biztos igaz amit ír, ezzel annyi szerintem a probléma, hogy nincs az az előre megírt gépi optimalizáció, ami akár minimálisan felül tud múlni emberi logikát, mert ok, hogy a sakkprogramok elverik az emberek 99%-át, de az nem emberi logika, hanem alapos és nagyon gyors "tippelgetés" stb, na jó ettől azért több, de lényegében igaz.... Ez mondjuk csak egyéni tapasztalat. Én a saját problémámra tudok példát hozni. Sokszor írok matematikai metódusokat, (C-ben, asm tuninggal ha meg tudok vele bírkózni, de nem ez a lényeg), hanem, tételezzük fel azt a helyzetetet, hogy egy egyenlet precíz megoldásához az egyik számot nekem elég 2 tizedesig ábrázolnom, a másik meg amennyire csak lehet pontosan. Na én annak igen komoly anyagi juttatást járok ki aki ezt univerzálisan megoldja, hogy a JIT fordító a lefordított képletet elemzi, és arra "rájön", hogy hoppá, ez a runge-kutta közlítésnél már "megsemmisülő differencia", és a lebegőpontos szám ábrázolását megoldja, optimális bit-hosszig. Ezzel a tök egyszerű trükkel kb 40% tempót nyertem. Pedig csak egy egyszerű veszteséges codec-ről van szó Ezt natívan futó kód nélkül nehezen tudom megoldhatónak elképzelni. Iyen feladatok az informatikában tucatjával vannak. Mondjuk azt erősen kétlem, hogy bárki is a mobilján fog filmet tömöríteni, szerintem ennek a nyelvnek is megvan a helye, egy tuti, hogy sokkal gyorsabban lehet elkészülni java-ban mit C-ben vagy pláne asm-ben. Van ahol ilyen szintű optimalizálás már nem kifizetődő, de van ahol nagyon megéri, és a java ezt a lehetőséget megakadájozza (vagy rosszul látom a dolgot). Mindkét nyelvnek megvan a maga helye, és ennyi.

Lényegtelen, néhány fanatikuson kívül senki nem akarja hogy minden feladatra a Java legyen A programozási nyelv...
Mérlegelni kell az előnyöket (gyorsan tanulható, szinte minden problémára van kész library ami jó eséllyel működik is, nagyon kényelmes fejlesztőkörnyezetek - debuging, profiling, stb) és a hátrányokat (komoly optimalizálás nélkül lassabb, memóriaintenzívebb) és dönteni kell hogy egy adott feladatra C/ASM vagy Java.

Persze ettől még létezik toll-méretű eszköz real-time kézírásfelismeréssel, és naná hogy Java-t futtat (Livescribe-nak hívják).

Ejnye no.

Senki nem mondta, hogy a JIT és a Java univerzális, hanem csak azt, hogy az előforduló feladatok kb. 90 százalékát Java nyelven implementálva olcsóbb végtermékeket kapunk, amelyek kb. 90 százalékát a JIT képes az azonos módon megírt natív kód sebességén futtatni, néha a natív kód sebességénél gyorsabban, mint láthattuk.

Ott a csúsztatás a leveledben, hogy leviszed a C programozási nyelv szintjére az algoritmizálást, holott azt a programtervezés szintjén kell elvégezni, aztán Java nyelven is tudod implementálni azt, hogy az egyik számot csak két tizedes jegyig számolod ki... és futási sebességben ismét ugyan ott vagy, mivel a Java program is pont annyira optimalizálható, mint a C program, és ha szükséges, azonos könnyedséggel tudsz JNI-n hívni assembly betéteket.
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

1. Már sokszor le lett írva, hogy van NDK Androidhoz, ha valaki nagyon optimalizálni akar, vagy egy natív feature szükséges az alkalmazásához: ismét előkerestem a linket

2. A mostani hivatalos Android platform SDK forrásnyelve Java, de a futtatókörnyezet nem JVM, hanem Dalvik: Google I/O előadás

3. Én fejlesztettem nem triviális alkalmazásokat J2ME-ben Nokia S60 platformot célozva, és elfogadható volt a sebessége. Persze telefon és telefon között jelentős különbségek vannak: E61 és E70 finoman szólva is csiga egy E71-hez képest.

4. Nem OpenGL szoftver renderert fogsz írni Javaban.
A legtöbb esetben a platform natív komponenseit használod, és a vezérlést írod meg. Nincs értelme Javaban implementálni codeceket, vagy titkosítást, csak ha nagyon nincs más megoldás (pl. a platform nem tudja). Ekkor nyilván sebességet és akkumulátoridőt áldozol fel.

5. Korántsem az Android az egyetlen mobil platform, ahol Java a forrásnyelv. Lásd még Blackberry.

6. A fejlesztési problémák sok helyen inkább a J2ME/CLDC platform hülyeségeinek számlájára írható: 10-15 éves technológiai színvonalat, ráadásul az akkori API tervezési divatot tükrözi. Mindezt még remekül meg lehet fejelni a kritikán aluli JSR implementációkkal: pl. Nokia JSR-75 PIM implementáció

7. Azzal, hogy az Android is az iPhone-hoz hasonlóan a régebbi készülékekre is kihozzák a platform új verzióit, lehetővé válik, hogy elkerüljük a fent említett problémákat, amik J2ME-nél jelentkeznek.

Egyébként pont a Nokia szoftver-nem-frissítési politikája szerintem gátja a Symbian alkalmazásfejlesztésnek, és egy jelentős indok amiért kényelmesebb a trónkövetelő platformokra fejleszteni.

Kedvencem, hogy van az S60 3rd editionnek 3 verziója (alap, FP1, FP2), de persze ha neked egy FP1-es telefonod van, akkor ahhoz nem fog kijönni FP2-es upgrade. Pl. FP2-ben újdonság, hogy megadhatod J2ME-ben, hogy milyen WLAN access pointot használjon a kapcsolódáshoz, és ne kérdezgessen mindig. Akinek nem FP2-es telefonja van, az így járt, vegyen újat. Ugyanez igaz ha C++-ban fejlesztesz.

Ha iPhone vagy Android mellett döntesz, akkor többé-kevésbé biztos lehetsz abban, hogy a készülék élettartama alatt elérheted a platform legfrissebb feature-eit, nyilván a készülék hardverkonfigurációjának megfelelő mértékben.

Üdv,
Gergely

Koszonom a reszletes valaszt / linkeket.

Nekem eddig csak N70, N73, N80 telefonjaim voltak Symbian sorozatbol. Ott erezheto volt a kulonbseg a nativ ill. java-s alkalmazasok tekinteteben. Masik terulet ahol JAVA-ztam az meg szimpla asztali 'felhasznalas' , ott meg oriasi a kulonbseg ha egyszeru asztali programokrol beszelunk (Remek ellenpelda a "data miner" ami lentebb lett emlitve).

Masik telefonokon (SE) erezhetoen gyorsabb volt a java, de azert ott is elmaradt a symbian altal nyujtott sebessegtol a dolog.

S60v3 van most is a jelenlegi telefonomon. Oszinten megvallva nem hinnem gondot okoz hogy egy alkalmazas regi, mert altalaban felesleges/nem-kikapcsolhato funkciokat hoznak csak bele (lasd: LCG jukebox, LCG smartmovie, LCG X-plore, ActiveFile, etc). Altalaban mindig valami olyant hasznalok (eloturom oket netrol) amik tudjak ami nekem kell, s kifujt.

(Remelem most hogy igy terjedni kezd az Android mania, hamarosan nekem is megadatik hogy egy Android hajtotta szerkezetet kiprobalhassak)

Azt persze én sem állítom, hogy a Java kód ugyanolyan sebességgel fut, mint a C++ kód. Annyit állítok, hogy az alkalmazások jelentős részéhez megfelelő sebességet nyújt, miközben a fejlesztési idő rövidebb, jobbak az eszközök hozzá...stb. Mint minden döntésnek, ennek is vannak előnyei / hátrányai.

Az S60-ról szóló kritikám inkább a fejlesztői oldalra vonatkozik: nagyon kellemetlen, amikor azért nem tudsz bizonyos készülékeket támogatni (vagy fordítva, bizonyos feature-t implementálni), mert csak az eggyel újabb változatban van benne a szükséges API hívás. Ez még azt a hagyományos, mondhatnám ódivatú felfogást tükrözi, hogy a mobiltelefon/smartphone termék életciklusa során nem változnak az elérhető funkciók. Látszik, hogy az iPhone és az Android terjedésével ez megváltozik.

Üdv,
Gergely

Vegyünk egy egyszerű algoritmust, ezt implementáljuk C és Java nyelven. A kódok a következőek:
C: 

#include <stdio.h>

unsigned long long int particio2(unsigned long long int n, unsigned long long int k) {
	if(k == 1 || n == 1) return 1;
	if(k>=n) return particio2(n, n-1) + 1;
	return particio2(n, k-1) + particio2(n-k, k);
}

unsigned long long int particio(unsigned long long int n) {
	return particio2(n,n);
}

int main(int argc, char **argv) {
	printf("%llu\n", particio(125));
}

Java: 

public class Particio {

	public static long particio2(long n, long k) {
		if(n == 1 || k == 1) return 1;
		if(k >= n) return particio2(n, n-1) + 1;
		return particio2(n, k-1) + particio2(n-k, k);
	}

	public static long particio(long n) {
		return particio2(n, n);
	}

	public static void main(String[] args) {
		System.out.println(particio(125));
	}

}

Futtatáskor érdekes eredmény jön ki: 

$ gcc -O2 -march=native -fomit-frame-pointer particio.c
$ time ./a.out 
3163127352

real	0m48.535s
user	0m48.431s
sys	0m0.004s
$ javac Particio.java
$ time java Particio
3163127352

real	0m41.490s
user	0m39.166s
sys	0m0.092s

Ha növeljük az értéket, a különbség egyre nagyobb lesz (mivel exponenciális az algoritmus).

A kódok egy 2x2.26 GHz-es P8400-as Core2Duo procin futottak le, performance governorral.

"A fejlesztot azert fizetik, hogy oldja meg a problemat. Ez egy kemeny szakma." - Chain-Q

Ubuntu Jaunty. 

$ gcc --version
gcc (Ubuntu 4.3.3-5ubuntu4) 4.3.3
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ java -version
java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
Java HotSpot(TM) Server VM (build 11.3-b02, mixed mode)

"A fejlesztot azert fizetik, hogy oldja meg a problemat. Ez egy kemeny szakma." - Chain-Q

ez a fajta teszt nálam mást mutat: 


>gcc -O2 -march=native -fomit-frame-pointer particio.c
>timeit -s a.exe
3163127352

Version Number:   Windows NT 6.1
Exit Time:        10:25 pm, Sunday, May 17 2009
Elapsed Time:     0:00:38.110
Process Time:     0:00:38.064


>javac Particio.java
>timeit -s java Particio
3163127352

Version Number:   Windows NT 6.1
Exit Time:        10:26 pm, Sunday, May 17 2009
Elapsed Time:     0:00:56.862
Process Time:     0:00:56.659

(E8400, w7, gcc4.3, j2se1.6.0_13)

szerk: jahogyservervm: 


>timeit -s java -server Particio
3163127352
..
Elapsed Time:     0:00:32.094
Process Time:     0:00:32.125
..

-O3: This is the highest level of optimization possible, and also the riskiest. It will take a longer time to compile your code with this option, and in fact it should not be used system-wide with gcc 4.x. The behavior of gcc has changed significantly since version 3.x. In 3.x, -O3 has been shown to lead to marginally faster execution times over -O2, but this is no longer the case with gcc 4.x. Compiling all your packages with -O3 will result in larger binaries that require more memory, and will significantly increase the odds of compilation failure or unexpected program behavior (including errors). The downsides outweigh the benefits; remember the principle of diminishing returns. Using -O3 is not recommended for gcc 4.x.

Forrás: http://www.gentoo.org/doc/en/gcc-optimization.xml#doc_chap2

Beágyazott rendszerre úgyis -Os-sel forgat az ember, vagy az SZTE-n fejlesztett arm-os energiafogyasztás optimalizációt használja.

"A fejlesztot azert fizetik, hogy oldja meg a problemat. Ez egy kemeny szakma." - Chain-Q

Nem hiszem, hogy perdonto mi a gentoo project velemenye az -O3-rol, mikor mas projektek pedig eppen ajanljak (mplayer meg raadasul pl. -O4-gyel fordit ;) ). Hivatalos, tamogatott gcc opcio - egy sebessegtesztnel meg foleg hulye otlet nem hasznalni.

Amugy en lattam beagyazott programokat gcc-vel forditani (nem csak open-source, de azt is), de -Os-re speciel nem emlekszem, hogy lattam volna hasznalni. Ami persze nem azt jelenti, hogy nem hasznaljak sehol, de altalanos ervenyu szabalykent talan kicsit meredek kijelenteni, hogy "Beágyazott rendszerre úgyis -Os-sel forgat az ember".

- Use the Source Luke ! -

Bizonyos szempontból okosan választott a feladat, mert ismert tény, hogy a jvm gyorsabb rekurzív kódot generál, mint a gcc.
Van még pár ilyen, pl a java memóriakezelése is gyorsabb. És sorolhatnám.
Ettől még egy valós alkalmazás általában nem gyorsabb java alatt.

Más szempontból nézve a példád rossz. Leginkább azt mutatja, hogy bármilyen nyelven lehet lassú programot írni...

Írhattad volna ezt (elnézést a kódolási stílusért :) ): 


#include <stdio.h>
#include <malloc.h>

#define getData(i,j) data[(i-1)*width+j-1]

unsigned long long int particio(unsigned long long int n) 
{
    const size_t width=n;
    unsigned long long int maxN=n,i,j,ret;
    unsigned long long int * data=malloc(sizeof(unsigned long long int)*n*width);

    for (i=1;i<=maxN;++i)
        for (j=1;j<=maxN;++j)
        {
            if (i==1 || j==1)
                getData(i,j)=1;
            else if (j>=i)
            {
                if (i==1)
                    getData(i,j)=2;
                else
                    getData(i,j)=getData(i,i-1)+1;
            }
            else
                getData(i,j)=getData(i,j-1)+getData(i-j,j);
        }

    ret=getData(n,n);

    free(data);
    return ret;
}


int main() 
{
    printf("%llu\n", particio(125));
    return 0;
}

Semmit nem csináltam, csak eltüntettem a rekurziót.
Még ennél is gyorsabb lenne valamivel, ha a belső ciklust normálisan 0-tól indexelném, csak úgy nehezebb lenne összevetni az eredeti algoritmussal.

Na most lehet tesztelni...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Direkt választottam :)

Ez volt algoritmusok tárgyból a példa arra nézve, hogy mennyire fel lehet gyorsítani egy rekurzív algoritmust (első lépésben csak cache-eli az eredményeket, másodikban meg átírtuk dinamikus programozásra). Önmagában itt sem a rekurzíóval van a gond, hanem azzal, hogy minden eredményt rengetegszer kiszámol, teljesen feleslegesen.

"A fejlesztot azert fizetik, hogy oldja meg a problemat. Ez egy kemeny szakma." - Chain-Q

kosz az infot, ismet tanultam valamit.

amugy a gcc (4.3.2-ubuntu) -O2-vel kioptimalizalja az osszes fuggvenyhivast, es csak sima ugras van helyettuk, csak a "particio2(n, k-1)" hivas marad. Az -O3 opcioval pedig azert gyorsabb (a java-nal is gyorsabb), mert beinlineolja kb 8-szor (8 melyen) az egy megmaradt fuggvenyhivast, ezaltal szinte nullara csokkentve a fuggvenyhivasok atalagos idejet. (szerk: mert valoban, ebben a tesztben a legtobb ido a fuggvenyhivassal menne el - elmenteni a regisztereket az elejen, visszatolteni a vegen - a tobbi elenyeszo)

- Use the Source Luke ! -

Az -O3 opcioval pedig azert gyorsabb (a java-nal is gyorsabb)

Erre valami mérési eredményt - ha felmutatnál - annak tudnék örülni... :)
Mert nálam +-3% körül jártak egymás körül, ami szimplán mérési hibának tekinthető egy olyan számítógépen, ahol közben minden más is fut... :)
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

$ time java -server -XX:+AggressiveOpts -XX:MaxNewSize=256M -XX:NewSize=256m -XX:+ScavengeBeforeFullGC -XX:+UseConcMarkSweepGC -XX:+UseThreadPriorities Particio
3163127352

real 0m18.090s
user 0m17.993s
sys 0m0.036s
$ gcc -O3 javabench.c
$ time ./a.out
3163127352

real 0m14.622s
user 0m14.597s
sys 0m0.000s

Megjegyzem a te linkelt meresedben is szarra verte a gcc -O3 a java-t, mert a "user" idoerteket kell nezni (a futas soran nem igazan hiv a kernelbe a peldaprogram, es azt sem kivajnuk merni, hogy kozben mennyi mas process futott meg).

- Use the Source Luke ! -

Csak az user-t kell nézni? Jelentős memóriafoglalás történik, ami akárhonnan nézzük: kernelhívás. Szóval nézz körül, mielőtt nagyon beleéled magad... :)

Szóval melyik programot hasonlítod melyikhez? Több, mint gyanús a 0.000s sys idő egy olyan programnál, amelyik erősen hív malloc és free függvényt... :)
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

ja, nem volt egyertelmu, hogy en a rekurziv hivasos eredeti verziot probaltam illetve arrol beszeltem az inlineolas kapcsan.

amugy igen, elkerulte a figyelmem, hogy van egy malloc az altalad mert verzioban. tehat gondolom az latszik, amit tr3w is mondott, hogy a memoria kezelesben is lehet gyorsabb a java - oke ez is ujdonsag szamomra (szegyen, vagy nem - nem foglalkoz(tam|om) javaval).

- Use the Source Luke ! -

ja, nem volt egyertelmu, hogy en a rekurziv hivasos eredeti verziot probaltam illetve arrol beszeltem az inlineolas kapcsan.

Jahát azt nem memóriára és GC-re kell optimalizálni... ahhoz más paraméterek kellenek a futtatásra... Java nem csak egyféleképpen optimalizálható... :)

hogy a memoria kezelesben is lehet gyorsabb a java

Hm... akkor miben lassabb? :)
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Oke, akkor milyen java parameterekkel veri meg a gcc -O3-at (nyilvan ezt is lehetne amugy tovabb cizellalni) az eredeti rekurziv peldaban?

Hm... akkor miben lassabb? :)

mondjuk lefut egy nativ kodra forditasi lepes a futas kozben ami c-ben mar forditasi idoben lezajlott. meg gondolom az alacsonyszintu reszekre jni-vel behivogatas is lassabb mint c-bol pl. az inline assembly.

- Use the Source Luke ! -

Oke, akkor milyen java parameterekkel veri meg a gcc -O3-at (nyilvan ezt is lehetne amugy tovabb cizellalni) az eredeti rekurziv peldaban?

Meg fogom nézni, ha lesz rá időm... :)

mondjuk lefut egy nativ kodra forditasi lepes a futas kozben ami c-ben mar forditasi idoben lezajlott.

Igen, simán lehet. Ugyanakkor az is előfordulhat, hogy a Java VM a CPU ismeretében jobban tud optimalizálni azonos köztes kódból, aminek az az előnye, hogy nem kell minden egyes architektúra-cpu ombinációra külön optimalizált binárist adni. Másrészt a környezetből el tudja dönteni a VM, hogy memóriára vagy CPU-ra kell inkább optimalizálni, melyik az aktuálisan szűk erőforrás - ez futás közben is változhat.

A JNI hívás nem lassabb, ahogy a primitív típusok kezelése sem. Az volt 10 éve, de már régen kinőtte a Java azt a korszakot.

Ami következtetést le lehet vonni az eddigi példákból az mindössze annyi, hogy az azonos implementáció nem fut lassabban vagy jelentősen lassabban, mint az O3 fordított C kód. 


$ time ./Particio
3163127352

real    0m45.143s
user    0m43.803s
sys     0m0.204s
$ time /opt/jdk1.6.0_06/bin/java -server -XX:+AggressiveOpts -XX:CompileThreshold=1 -XX:ReservedCodeCacheSize=32m -XX:AllocatePrefetchStyle=2 Particio
3163127352

real    0m45.111s
user    0m45.175s
sys     0m0.072s

--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Mint írtam volt - nem lehet olyan nyelvet találni, ami mindenre jó... tipikusan a játékfejlesztés az, ahol kénytelen az ember natív kódot hívni, különben nincs hardveres gyorsítás... :)

Java eddig is lehetővé tette a JNI-n keresztül a natív hívást, amelyet sok esetben ki is lehetett használni. Ettől függetlenül nagyon sok esetben elegendően gyors-gyorsabb a menedzselt kód is, tehát egyre szűkül a natív hívásigény.
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Érdekelne, hogy miképpen éred el natív hívás nélkül a hardveres gyorsítást, segítségképpen a Java3D is natív libekkel érkezik, attól, hogy nem látod, még natív hívást kezdeményez. Ugyanezt teszi a VM is, a 1.6.0u10 verzió óta több 2D funkció mögé került hardveres gyorsítás, amelyhez szintén kell natív hívás.

De érdekel a Te verziód is...
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

> Több, mint gyanús a 0.000s sys idő egy olyan programnál, amelyik erősen hív malloc és free függvényt... :)

Mit szeretnél ezzel mondani? Hogy "jól" van implementálva a malloc? Hogy sok malloc hívás történhet úgy, hogy közben 1 kernel hívás sem történik? Vagy mit? :-)))

Mit szeretnél ezzel mondani? Hogy "jól" van implementálva a malloc? Hogy sok malloc hívás történhet úgy, hogy közben 1 kernel hívás sem történik? Vagy mit? :-)))

Bocsánat, hogy megkérdezem, de érted is, amit kérdezel?

Mint már kiderült, bizony nem volt egy fia malloc hívás se, ezért nem volt sys terhelést, tehát nem arról van szó, hogy jól van implementálva a malloc hívás...
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Nos, Particio2.c: 


#include <stdio.h>
#include <malloc.h>

#define getData(i,j) data[(i-1)*width+j-1]

unsigned long long int particio(unsigned long long int n)
{
    const size_t width=n;
    unsigned long long int maxN=n,i,j,ret;
    unsigned long long int * data=malloc(sizeof(unsigned long long int)*n*width);

    for (i=1;i<=maxN;++i)
    {
        for (j=1;j<=maxN;++j)
        {
            if (i==1 || j==1)
            {
                getData(i,j)=1;
            }
            else if (j>=i)
            {
                if (i==1)
                {
                    getData(i,j)=2;
                }
                else
                {
                    getData(i,j)=getData(i,i-1)+1;
                }
            }
            else
            {
                getData(i,j)=getData(i,j-1)+getData(i-j,j);
            }
        }
    }

    ret=getData(n,n);

    free(data);
    return ret;
}


int main()
{
    int count;
    for (count=0; count<1024; count++) particio(1024);
    printf("%llu\n", particio(1024));
    return 0;
}

Ugyanez Java nyelven implementálva: 


public class Particio2
{
  private long[] data;
  private int n;

  public Particio2(int n)
  {
    data = new long[n*n];
    this.n = n;
  }

  private long getData(int i, int j)
  {
    return data[(i-1)*n+j-1];
  }

  private void setData(int i, int j, long value)
  {
    data[(i-1)*n+j-1] = value;
  }

  public long compute()
  {
    for (int i=1;i<=n;++i)
        for (int j=1;j<=n;++j)
        {
            if (i==1 || j==1)
                setData(i,j,1);
            else if (j>=i)
            {
                if (i==1)
                    setData(i,j,2);
                else
                    setData(i,j,getData(i,i-1)+1);
            }
            else
                setData(i,j,getData(i,j-1)+getData(i-j,j));
        }

    return getData(n,n);
  }

  public static void main(String[] args)
  {
    for (int count=0; count<1024; count++)
    {
      Particio2 p2 = new Particio2(1024);
      p2.compute();
    }

    Particio2 p2 = new Particio2(1024);
    System.out.println(p2.compute());
  }
}

Futtatási eredmények: 


$ gcc -o Particio2 Particio2.c
$ time ./Particio2
4317450311165302055

real    0m41.448s
user    0m34.046s
sys     0m6.968s
$ gcc -march=native -fomit-frame-pointer -o Particio2 Particio2.c
$ time ./Particio2
4317450311165302055

real    0m41.060s
user    0m33.762s
sys     0m6.784s
$ gcc -O2 -march=native -fomit-frame-pointer -o Particio2 Particio2.c
$ time ./Particio2
4317450311165302055

real    0m20.940s
user    0m14.029s
sys     0m6.708s
$ gcc -O3 -march=native -fomit-frame-pointer -o Particio2 Particio2.c
$ time ./Particio2
4317450311165302055

real    0m18.311s
user    0m11.417s
sys     0m6.760s
$ /opt/jdk1.6.0_06/bin/javac Particio2.java
$ time /opt/jdk1.6.0_06/bin/java -client Particio2
4317450311165302055

real    0m29.874s
user    0m24.714s
sys     0m4.432s
$ time /opt/jdk1.6.0_06/bin/java -server Particio2
4317450311165302055

real    0m23.965s
user    0m16.689s
sys     0m7.008s
$ time /opt/jdk1.6.0_06/bin/java -server -XX:+AggressiveOpts -XX:MaxNewSize=256M -XX:NewSize=256m -XX:+ScavengeBeforeFullGC -XX:+UseConcMarkSweepGC -XX:+UseThreadPriorities Particio2
4317450311165302055

real    0m18.798s
user    0m18.289s
sys     0m0.288s

A következtetéseket mindenki vonja le maga... :)
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Az algoritmust nem ellenőriztem, s így - ha hibás az eredmény, akkor a C program is azonosan hibás értéket adott, funkcionálisan azonosan működnek (rosszul), de mindez a benchmark eredményeit nem befolyásolja, tehát a mért értékekkel kapcsolatban bármi észrevételed ha lenne, annak örülnék... :)
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

> a mért értékekkel kapcsolatban bármi észrevételed ha lenne

Az uint64_t eredménytípusból adódó felső korlátnak megfelelő tömbméret statikus lefoglalása (~1,5 megabájt) jobb mért értékeket ad. Pld: 


#include <stdint.h>

uint64_t particio(int n, int k){
  static uint64_t cache[417][417];

  if( n>416 ) return -1;

  if(k >  n ) k=n;
  if(k <= 1 ) k=1;
  if(n <= 1 ) n=1;

  if( !cache[n][k] ){
    if( k == 1 || n==1 ) cache[n][k] = 1;
    else                 cache[n][k] = particio(n, k-1) + particio(n-k, k);
  }

  return cache[n][k];
}

Így mi jön ki a futási időkre?

> Mit akarunk mérni?

A "hanyag" implementáció tehát jobban fut Javá-ban, mint C-ben. És mi a helyzet az "gondos" implementációval?

> Statikus tömbelérést? Mert ez azt méri... :)

Helyesebben: 


uint64_t partitions[417] = {
  1ULL,
  1ULL,
  2ULL,
  3ULL,
  5ULL,
  7ULL,
  ...
  14902156290309948968ULL,
  15834420884488187770ULL,
  16823822787139235544ULL,
  17873792969689876004ULL
};

:-))))

Értem, de ez az első futás után cache-ből ad vissza értékeket, a futása pedig benchmark szempontjából értékelhetetlenül gyors. Ezért kérdezem, hogy mit is akarsz ezzel mérni?

Én mérnök vagyok, nem matematikus, adj nekem egy olyan programot, ami szerinted mérhetően lassabb lesz Java nyelven és legalább fél percig fut egy átlagos PC-n, azzal lehet összehasonlítani a két implementáció sebességét.
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

> hogy mit is akarsz ezzel mérni?

Azt hittem egyértelmű: "jó" C implementáció vs. "jó" Java implementáció. Csak hogy teljesebb legyen a paletta, mert a "naív" C implementácio vs. "naív" Java implementáció már lement.

> a futása pedig benchmark szempontjából értékelhetetlenül gyors

Rakhatsz a bináris köré is ciklust :-)

Értem én, hogy jó az implementáció, de ebben a formában összehasonlító mérésre nem alkalmas. Ahogy az se, hogy 0.001s ideig futó program köré egy bash scriptet írjak, ami többször elindítja, mert tartok tőle, hogy a bash ciklus performanciáját mérném a mérendő performancia helyett.
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Háde' ha arra vagy kíváncsi, hogy hogy néz ki egy "jó" Java implementáció, akkor azt kérdezd meg, ne utalgass rá.

Meglepő módon pont úgy néz ki, mint a C program (némi szükséges módosítással, és persze azzal, hogy nincs unsigned long): 


  private static long cache[][] = new long[417][417];
  public static long particio(int n, int k)
  {
    if( n>416 ) return -1;

    if(k >  n ) k=n;
    if(k <= 1 ) k=1;
    if(n <= 1 ) n=1;

    if( cache[n][k] == 0 ){
      if( k == 1 || n==1 ) cache[n][k] = 1;
      else                 cache[n][k] = particio(n, k-1) + particio(n-k, k);
    }

    return cache[n][k];
  }

--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

> Meglepő módon pont úgy néz ki, mint a C program

Akkor az egy C program, Javá-ban implementálva :-)))

> hogy néz ki egy "jó" Java implementáció, akkor azt kérdezd meg, ne utalgass rá.

Gondoltam, előbukkan magától is, amikor a C-be bekerül a cache. Tévedtem. Mindegy, azóta talált a google nekem példát Java annotáció, memorizálás témakörben; nem kell elhinnem hogy "jó" Java kódot csak C-ből átírva lehet készíteni. :-)

Akkor az egy C program, Javá-ban implementálva :-)))

Nem, ez egy algoritmus, amelyet közel ugyanúgy lehet implementálni C és Java nyelven. Ok és okozat.

Mindegy, azóta talált a google nekem példát Java annotáció, memorizálás témakörben

Annotáció nincs C nyelven, de az annotáció matematikai algoritmusok tekintetében nem jön képbe, teljesen másra használják, más a célja. A memorizálás alatt nem tudom mit értesz.
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

> az annotáció matematikai algoritmusok tekintetében nem jön képbe, teljesen másra használják, más a célja.

Én nem értek hozzá, csak annyit láttam hogy annotációval jelölték, melyik metódus kiszámítása "költséges": aminek a visszaadott értékét "olcsóbb" megjegyezni és szükség esetén elővenni, mint újra kiszámolni. Egy ilyen megoldással a kód Javá-nak nézhetne ki, nem pedig C-nek. :-)))

> A memorizálás alatt nem tudom mit értesz.

http://en.wikipedia.org/wiki/Memoization

Az annotáció - ahogy a neve mutatja - csak egy jelzés, amellyel a programozónak - akár a framework programozójának - kell valamit kezdenie, olyan, mintha a kommentek kiolvashatóak lennének a lefordított programból.

A memoizálás és a memorizálás nem ugyanaz... :)
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Pontosan úgy van, ahogy BaT írta. Lenne megoldás szerver oldalon, de az volt akinek nem tetszett.

Magadnak meg tudod oldani például így:

Felteszed a Stylish extension-t:

https://addons.mozilla.org/hu/firefox/addon/2108

Létrehozol egy új style-t a hup.hu-ra, aminek ez a tartalma: 


@namespace url(http://www.w3.org/1999/xhtml);

@-moz-document domain("hup.hu") {

}

.comment .content {
  max-width: 500px;
}

Ha akarod bekapcsolod, ha akarod nem. Az 500px szélességet akkorára veszed, amekkorára akarod.

Bár az is lehet, hogy ezt beállítom az egész oldalra globálisan. Majd meglátom.

--
trey @ gépház

Köszi a tippet, de...
1. Extension nem kell, elég az userContent.css
2. Abba pedig elég ennyi: 


@-moz-document domain("hup.hu") {
.main-content {
  max-width:724px;
}
}

Nekem így szép lett, 1152x864-ben.

Szerk: Midoriban is működik, persze ott az @-moz-document részt ki kell venni.

--
Debian - The "What?!" starts not!
http://nyizsa.uni.cc

.main-content {
  max-width:724px;
}

Igen, ez talán még jobb megoldás. Nem tudom, hogy ez css-ből állítva a többi browser-ben is jó lenne-e. Le kéne tesztelni.

Szerk:

Kipróbáltam, teljesen jól működik Firefox, Opera, Google Chrome Safari böngészőkkel. Még egy kicsit tesztelem, aztán beállítom.

Szerk 2: Beállítottam. Meglátjuk. Ha nincs semmire negatív hatása, akkor marad végleg.

--
trey @ gépház

OK. Mondjuk én 640px-et állítottam, de végül is tök mindegy. Az IE7/IE8 ezt nem veszi figyelembe (nem is mertem remélni), de végül is az oldal olvasóinak 82%-a jobban járt ezzel a beállítással, a maradék 18% meg nem járt rosszabbul, maradt minden nekik a régiben.

--
trey @ gépház

Ez nem (csak) honorsharknak valasz, hanem az osszes kommentelonek ebben a threadben... Szoval, csak igy innen a Netbeans, Eclipse meg a BlackBerry JDE mogul uzennem, hogy veresre rohogom magam rajtatok. De komolyan. :) Ami itt epul az mar nem is bikeshed, az mar bikehangar bazmeg. :) Elokeszitettem a popcornt meg a kolat, ne hagyjatok abba. :D

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

( blah-blah | 2009. 05. 18., h – 09:45 )

Néhány észrevétel:

  1. Általában Java és a C++ közötti sebességkülönbség nem érzékelhető egy átlagos mobil alkamazásnál mert mindkét nyelv hasonló sebességgel vár a user input-ra :). Számításigényes alkalmazásokat inkább szerver oldalon kell implementálni.
  2. A Java azért kényelmetlen mobil környezetben, mert:
    1. a JVM indítása plusz 3-10 másodpercet ad az alkalmazás indításához. Ez a Symbian/Nokia hibája mert nem integrálták be a Java-t rendesen. Az Androidnál ez nincs így, mert a JVM mindig fut.
    2. a J2ME alkalmazás UI-a más mint a normál alkalmazásoké (S60), emiatt a programozók és a felhasználók is berzenkednek. Az IBM annak idején nyomta az SWT mobil verzióját, az eSWT-t, de a Nokia még mindig nem használja.
    3. a J2ME API jelentősen szűkített része a normál J2SE API-nak, emiatt a programozók vannak rosszul. Az Androidon ez szintén nem probléma.
    4. Meglepő módon a J2ME alkalmazások nem túl jól portolhatóak különböző telefonok között, mivel a különböző telefonok különböző JSR API-kat tesznek elérhetővé.
    5. Windows Mobile-on (általában) nincs J2ME.

Egyszóval az Adroid egy igéretes platform, meglátjuk sikerül e megfelelő piaci részesedést szereznie.

Általában Java és a C++ közötti sebességkülönbség nem érzékelhető egy átlagos mobil alkamazásnál mert mindkét nyelv hasonló sebességgel vár a user input-ra :). Számításigényes alkalmazásokat inkább szerver oldalon kell implementálni.

BWUAHAHAHAHA LOL. :) Ez kesz. :P Te valami szolgaltatonak dolgozol? :) Azok szoktak olyat csinalni, hogy minden netrol jon, es emiatt 2x lassabb mintha a telon futna, de lehet jo sok adatforgalmat szamlazni. :P

Meglepő módon a J2ME alkalmazások nem túl jól portolhatóak különböző telefonok között, mivel a különböző telefonok különböző JSR API-kat tesznek elérhetővé.

Ha en azert irtam kodot, ami kb. 40 kulonbozo telefonra lett kiadva, az baj? :) (Oke, szopas, de ennel sokkal durvabb szopasok is vannak programozas cimszoval.)

a J2ME alkalmazás UI-a más mint a normál alkalmazásoké (S60), emiatt a programozók és a felhasználók is berzenkednek

A J2ME UI egy vicc, konkretan. Jobbanmondva, halistennek komolyan gondoljak, mert viccnek eleg durva lenne. Nem veletlen, hogy mindenki, aki egy picit is komolyabb rendszert epitett a telefonjaira Java-ban, az sajat UI enginet csinalt hozza. BlackBerry is, Android is.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

( okarika | 2009. 05. 18., h – 19:57 )

Nekem van. Egyáltalán nem lassú, sőt. Időnként egy rövid időre megakad. Gondolom a gc ilyenkor dolgozik, de annyira nem mélyültem bele.

Az biztos, hogy egy winmo-hoz képest álom.

Iphone-om nincs, amennyire láttam a user interface almáéknál valamivel látványosabb, funkcionalitásban nem tűnt jobbnak.
Viszont az ismerőseim időnként dührohamot kapnak mert fagy. A g1-em még nem fagyott.

Kb ennyi. nekem tetszik, megszerettem, kacérkodom a programfejlesztéssel. Amennyire láttam, ami gyors kell hogy legyen nagyrészt api-n keresztül hívódik. Kérdés, hogy az elzárt (root owned) részben benne van-e, ami éppen kell. Pl tun/tap sajna a user processzeknek nem elérhető. Ami meglepett, hogy van voip szoftver rá, ami azért számításigényes tud lenni.

Üdv