Quake 2 Motoru Java'ya Port Edildi!

anonim
30 Kasım 2005 , 1 dakika okuma süresi

id Software'in yazdığı ve GPL lisansı ile dağıttığı Quake 2 motoru Java'ya port edildi. Yeni motoru herhangi bir sırf yapmak için yapılmış projeden ayıran şey performansının C ile yazılmış orjinal motorun performansını yakalayıp hatta geçebilmiş olması. Henüz 1.0 versiyonu çıkmamış olmasına rağmen şimdiden C hızında çalışan bir oyun motorunun üretilebilmiş olması Java'nın akıllardaki imajına uymasa da akla ilginç fikirler getirmiyor değil.

Örneğin Java için DirectX veya SDL gibi gelişmiş ve performanslı kütüphanelerin yazılması özgür yazılım platformlarında oyun sayısının az olması sorununa bir çare olabilir. En azından artık Java ile özgür yazılım geliştiren programcılar yeni oyun projelerine başlayabilirler. Bakalım ilerde bu oyun motorunu kullanacak kaç yeni özgür oyun çıkacak.

java

Görüşler

neurorebel
18 yıl önce

Fakat test makinelerinin hepsi oldukça yüksek konfigürasyonlara sahip. Daha düşük konfigürasyonlarda test edilse daha gerçekçi istatistikler elde edilmez mi ? Zira Quake 2'yi Pentium 120'de oynadığımı hatırlıyorum.

FZ
18 yıl önce

O Pentium 120 Mhz makinanın ana hafızasını da yazar mısınız, iyice gerçekçi bir kıyaslama olsun diye ;-)

neurorebel
18 yıl önce

Hımm... Benim kafamı karıştıran şu ben size OpenGL API kullanarak C ile ekranda dönen bi küp çıkartayım sonra da aynı işi Java ile yapıp; "Bakın neredeyse aynı FPS !" dersem..... P120 makinenin hafızası muhtemelen 64 ya da 32'ydi.. Oynadığım Quake 1'de olabilir ama Quake 2'de zaten P166MMX ler falan varken çıkmıştı...

ahmetaa
18 yıl önce

Tam olarak oyle degil. Bu tip oyunlarda ciddi islemci gucu de gerekiyor, yani is kup dondurmeden cok farkli. Oyunun arkasindaki mantik ornegin nesnelerin konumlari, hareket, carpisma denetimi, parcacik hareketleri, dusmanin davranisi, ag islemleri hem cok islevli programlama hem de ciddi islemci yuku getiren islemler. Belki Quake2'de degil ama gunumuz oyunlarinda ciddi derecede AI programlama soz konusu . Bu uygulamanin gosterdigi sey, aslinda modern oyunlarin cogunun oyunlarin C++ degil Java ile de yazilabilecegi.. Bellek konusunda ise, bu gibi uygulamalrda Java'nin bellek kullanimi daha cok olacaktir ama sanal makine parametrelerini oynayarak uygulamanin dusuk iziksel bellek ile calismasini saglamak mumkun (Ornegin -Xms32M -Xmx32M ile 32MB'dan fazla bellek harcamaz sistem. Bu durumda daha sIklikla cop toplama islemi gerceklesir ama en azindan progam islemeye devam eder. Tabi eger 32M calisma icin yeterli olursa)

neurorebel
18 yıl önce

Bir AthlonXP 2400 ve GeForceMX için Quake 2 çalıştırmak küp çalıştırmak kadar kolaydır. Buna istinaden küp örneğini verdim... 3d enginelerle ucundan kıyısından uğraşan biri olarak anlatmak istediğim şey bir yerden sonra artık performans tepe noktasına ulaştığı. Burada doğru dürüst bir kıyaslama yapılabilmesi için yazılımın karmaşıklığının donanımın gücüne paralel olması gerekir. Yani 1.000.000 float'u sıralayan bir C programı ile Java programını karşılaştırmak için bir 486 kullanılması P4 kullanılmasından çok daha düzgün sonuçlar verir. Ya da 1.000.000 değilde 100.000.000 float sıralamaya çalışmak gerekir. Ve bu cevap için teşekkür ederim. Gereksiz laf kalabalığı yapmaktan iyidir. Fakat problem şu ki Quake 2 eski bir oyun. Java ile modern oyunların kalitesinde bir şeyler yapılması ve bunun C ve ASM kullanılarak yapılmış muadilinden hızlı olması pek mümkün değil sanırım.

yilmaz
18 yıl önce

Yanlış hatırlamıyorsam FarCry adlı oyunda da JAVA kullanılmıştı. Oyun 3-5 ay önce çıkmıştı.

yilmaz
18 yıl önce

Bu arada java ile JNI kullanarakda kod yazılabilir. Tabi o zaman multiplatform olmaz ama en az c++ kadar performans verir.

neurorebel
18 yıl önce

JNI kullanarak yazdığınız kodlarda Java Virtual Machine içinde çalışır. Tek fark bu kodlara başka bir "native" uygulamadan erişebilirsiniz. Örneğin hali hazırda Java'da yazılmış bir sınıfı bir C++ programınız içerisinde kullanabilirsiniz. Zaten JNI tamamen Java'da yazılmış uygulamalar geliştirmek için değildir. Aksine Java'da yazılmış parçaları "native" uygulamalar içerisinden çağırabilmek ya da "native" uygulamalarınızı Java'dan erişilebilir hale getirmek içindir. Dolayısı ile JNI ile yazdığınız uygulamaların C++ kadar performans vermesi gibi birşey söz konusu değil...

yilmaz
18 yıl önce

java kodu yazarsın native uygulamanda kullanırsın. jvm de çalışsa bile %10 dan fazla etki yapacağını düşünmüyorum.

neurorebel
18 yıl önce

Peki...

mascix
18 yıl önce

java hep olmalı .net coşmamalı taraftarıyımda suyunu çıkarmanında alemi yokdu :))

anhanguera
18 yıl önce

selam, verilen benchmark linkinda javanin c den hizli oldugunu yazan, veya daha cok hizli olduklarini soyleyen bir yazi veya deger gormedim ben? yanlis yere mi bakiyorum? degerlere gelince, jake2 amd-k62 350 de calismiyormus gibi duruyor. kaldiki q2 yi 200mmx 32 edo ram, ile gayet basarili oynardim ben. zaten bu noktada onemli olan daha cok gpu. q2 bende diamond 2000pro ile gayet de basarili idi, bildiginiz s3 virgeDX canim. jake2 nin yazildigi zaman itibari ile kullandigi gl extensionlarini da merak ediyorum. neden gforce? neden s3 degil? q2 zamaninda ortalik s3 den gecilmezdi. bilmem derdimi anlatabildim mi. tamam java guzel bir dil, herseyi java yapiyor, oop, vs.. ama su katmamak da lazim. javanin, c, hatta c++ kodundan daha hizli calistigina gercekten inanan varsa diyecek birsey bulamiyorum. alper akcan.

yilmaz
18 yıl önce

http://www.kano.net/javabench/data

yilmaz
18 yıl önce

http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
java gibi sistemden izole olan bir dilin diğer native tabanlı dillerden bazen hızlı bazen yavaş çalışması mumkundur yalnız yavaş çalıştığı zaman da arada büyük farklar oluşmuyor.

skoylu
18 yıl önce

Temelde, Javanın veya Lisp'in yada Python'un, C'den daha hızlı çalışması mümkün değildir. Fakat, siz C kodunu optimize yazamazsanız, üst düzey dillerde de abstraction'u single-shot olacak kadar yukarıya çeker ve optimize bir şekilde kütüphanesini yaparsanız, o zaman üst seviye dil daha hızlı çalışacaktır.
Ne dedim ben? Anlayan beri gelsin mi oldu? Şimdi bakalım, bir matrisi diğeriyle çarpıyorsunuz diyelim. C'de for, while, do vs. kullanıp, acayip veri tipleriyle filan bunları yapabilirsiniz. Ama mesela, temelde, float yerine int kullanırsanız işlem daha hızlı olur mesela. bazen, "i++" yazmakla, " i += 1" yazmak bile hızda fark edebilir. Daha bir süre şey.. Ama üst seviyeli bir dile, "matris_carp" gibi bir fonksiyon konursa, bunun içinde benzer şekilde cok iyi optimize edilmiş kod bulunursa, üst seviye dille yazılan işlem daha hızlı olabilir.
Çoğu programcı, C elinde iken sistemin kendine neler sunabildiğinin pek farkında olmaz. Basit bir örnek verelim. Bir parser yazıyorsunuz. Dosyayı açıyor, içeriği bir buffer'e dolduruyor, sonra parse ediyor. İşte size bir sürü yönden performans kaybı yaşatacak bir vaziyet. Böyle yapmaktansa, dosyayı açtıktan sonra mmap ile adreslemek daha iyi netice verecektir.
Tipik olarak, sistemin nimetlerini sonuna kadar kullanacak (=sisteme boğazına kadar batacak, multiplatform olmaktan uzaklaşacak) olarak yazılmış C kodları, her zaman daha hızlı olacaktır. Atlanan husus, java gibi dillerde asıl işi yapan bölümlerinde zaten çok optimize şekilde C/C++ ile filan yazıldığıdır.

yilmaz
18 yıl önce

Adam yazsın optimize kodunu. C ona optimize kod yazmasında engel çıkarıyor ise o da elinden geleni yapar.
Diyelim testte java öne çıktı. O zaman "c kodu optimize yazılmamış diyeceğiz. Bu test saçmalık. aslında java yavaş çalışır" mı diyeceğiz?

skoylu
18 yıl önce

Kodu optimize yazmak denince, genel olarak daha hızlı olduğu bilinen yapılar kullanmak anlaşılır. Çoğu durumda, derleyici bu işi kendi başına becerebilir.
Halbuki, kodu yazarken asıl optimizasyon sisteme göre yapılır. Örneğin, Windows altında yazıyorsanız, WSA Socket arabirimi, BSD Socket arabiriminden bir hayli daha hızlıdır. Linux altında iken, yoğun disk okuma yazma işi yapan bir uygulama yazıyorsanız, fread/read kombinasyonlarını değil, aio_read, aio_* mekanizmalarını kullanmak ciddi performans getirisi sağlar.
Dahası C ile abartıp, scheduling, VM vs. konularına da el atıp bir iyice performans getirilebilir. Oysa benzer benchmarking işlerinde kullanılan uygulamalar, çoğu zaman böyle optimizasyonlar içermez. İki dilden hangisi hızlıdır gibi bir test yaparken, mümkün olan en az sistem çağrısı yapılacak şekilde düşünmek gerekir.
Örneğin, 100000 tane sayıyı toplayan bir kod iyi bir test olur. Ama üst düzey diller bazen çok kurnaz olabilirler. yorumlaması gereken bu iterasyonu anında derleyip, kodun diğer kısımlarını derlemeden, çalıştırabilirler. Hatta bunu yaparken MMX/SIMD gibi şeyleri de ortaya sokabilirler. open, write gibi sistem çağrıları yerien doğrudan ioctl/syscall ile çalışabilirler vs. Ve gerçekten onlar kadar hedef mimariden anlamıyorsanız, onlardan hızlı kod üretmeniz biraz zor olur. Javadan bunlardan biridir.
Ama Java için bu özellik bilinmeli, kod yazarken bunları düşünüp, VM'in yiyip bitireceği kodlar, optimizasyonlar yapılmalıdır. HOş yüksek seviyeli dillerde bu daha kolaydır, hatta çok kolaydır..

darkhunter
18 yıl önce

Yani, yüksek seviyeli diller kulanarak (mesela) WM yazmak, bir takım optimizasyon problemlerinin yorumlanma sırasında kendi içinde çözülmesine neden olabiliyor, öyle mi? Böylece C/C++ ile yazılmış ama optimize edilememiş kodlardan daha hızlı çalışmak mümkün anladığım kadarıyla. Peki, yüksek seviyeli diller ile C'nin "manuel" optimizasyonu arasında ciddi bir çap farkı söz konusu mudur?

Kodu optimize etmenin çeşitli yolları vardır ve bunlar syntax'ın çeşitliliğine paralel seyreder genellikle. Açıkçası yüksek seviyeli dillerin önemli ölçüde optimizasyon yapmakla beraber, Python gibi dillerin "manuel" yada düşük seviyeli programlamaya da zaman zaman dem vurabildiklerini biliyoruz.

Yeni nesil yüksek seviyeli birkaç dil için "optimum" tanımlanan bir makina çevrimi yapılıyor. Ve ben yaklaşık 2 yıldır (son iki yıl içerisinde relase yapmış derleyiciler için), şu dil şundan hızlıdır, ahh bak bu bariz yavaş diyemiyorum. Hatta daha da ileriye gidip şöyle düşündüğümde oluyor (son iki yılda relase yükseltenler için) : Hiçbir dil C'den daha hızlı değildir. C'de hiçbir dilden daha hızlı değildir. Doğrusu bunu söylemek için 89'dan beri bekliyordum :)

skoylu
18 yıl önce

Örnekler biraz yanlış, kafa karıştırıcı oluyor. C ile birşeyler yazılıyor, sonra bir başkası çıkıp başka bir şey yazıyor, aynı işi yapan. Ve biri diğerine nal toplatıyor. Eğer benchmarklara bakarsanız, bir sürü veritabanının aralarında %500 hız farkı ile çalışabildiğini görürsünüz. Ama nerdeyse hepsi C ile yazılmıştır. C'de hızı belirleyen genelde sizsiniz. Üst seviyeli dillerde ise hızı belirleyen derleyici ve vm. Eğer siz o derleyici veya vm kadar optimizasyon yapmayı bilmiyorsanız, C ile yazmış olmanız sizi daha hızlı yapmaz.
Şöyle bir işleme bakalım:
x = y + z; Python için, bunların herbiri bir nesnedir. Önce bu nesnelerin türlerini bulması, __add__() fonksiyonunu çağırması vs. gibi bir sürü iş olacaktır. Javada da durum pek farklı değildir. Ama C için bunlar, bunlardır. Fakat, x, y ve z signed integer ise, toplama sonucuda MAXINT'ten büyük çıkarsa, iki pozitif sayının toplamı alakasız bir negatif sayı olacaktır. Bu durumun oluşması ihtimali varsa önce bunu kontrol etmeli, buna göre mesela, x'i long int yapmalı, şöyle bir hareket yapmalısınız:

x = y;
x += z;

İşte bu tür durumlar, optimizasyonun karşınıza küt diye çıktığı hallerdir. Doğru dürüst programlama yazarken, benzer şekilde acayip püf noktalarına takılırsınız. Bu noktalarda eldeki datanın en hızlı işleneceği yolu derleyici bulamaz. Java gibi diller bu noktada en doğru olacak, belirtilen gibi soruna yol açmayacak (bu sorun bir örnektir, kolay anlaşılması için seçilmiştir) kodları kullanırlar. Ayrıca aynı sebepten, garbage collector vs. gibi bir sürü ek yük oluştururlar.
İşte yüksek seviyeli dilleri yavaş yapan sebep budur. C gibi düşük seviyeli bir dilde, garbage collection vs. gene yapılabilir. Ama bunlar yapılınca performans, daha genel olarak kaynak tüketimi sorunu artar ve avantaj kaybolur.
C kullanırken de, eldeki sonsuz denebilecek data ve bu dataya uygulanabilecek sonsuz sayıdaki işlem kombinasyonunu bir derleyicinin kestirmesi mümkün olmaz. Ama siz datayı kolayca en hızlı olacak şekilde sonsuz seçenekten sonlu seçeneğe, işlem sayısınıda aynı şekilde çok sınırılı sayıya indirebilirsiniz, datanın ne olduğunu siz biliyorsunuz. Bu durumda elinizde sınırlı sayıda kombinasyon olur ve her adımın hangi kaynak tüketimine yol açacağını da biliyorsanız, mümkün olan en olası az kaynak harcaması ile sonuca ulaşmanız kabil hale gelir.

darkhunter
18 yıl önce

Java gibi diller bu noktada en doğru olacak, belirtilen gibi soruna yol açmayacak (bu sorun bir örnektir, kolay anlaşılması için seçilmiştir) kodları kullanırlar. Ayrıca aynı sebepten, garbage collector vs. gibi bir sürü ek yük oluştururlar.İşte yüksek seviyeli dilleri yavaş yapan sebep budur. C gibi düşük seviyeli bir dilde, garbage collection vs. gene yapılabilir. Ama bunlar yapılınca performans, daha genel olarak kaynak tüketimi sorunu artar ve avantaj kaybolur.

Söylediklerinize genel hatlarıyla katılıyorum. Garbage Collector'un işlevini C koduna verdiğinizde Java'nınkinden daha beter bir performans kaybı yaşayacağınız konusunda bir anektotla beraber.

Yüksek seviyeli dillerin yavaşlatan denetimlerini C'ye yazmadığınızda C daha hızlı çalışır, doğrudur. Çoğu durumda yüksek seviyeli diller x y z deki gibi vakitte kaybederler ama kullandıkları denetimleri (GC gibi) C'ye yazmaya kalkıp oradan bir benchmark'a gitmeye çalışırsanız (diğer mekanik faktörleri düşünmeyelim), C geride kalacaktır. Yegane neden, (mesela) Java'daki GC'ye harcanan mühendislik yılıdır muhtemelen.

Python için verdiğiniz örnek aklıma şunu getirdi :
Verdiğiniz örneği Python'a C kodu olarak gömen ve muhtemelen python'un daha hızlanacağı noktalar da python'a kodlayıp gerisini yine python'a C kodu olarak gömen bir kodlama paradigmamız olsa benchmark nasıl vuku bulurdu acaba?

skoylu
18 yıl önce

Aslında böyle paradigmalar falan ardında koşmak daha ziyade teorisyenlerin işidir. Endüstriyel vede partik açıdan bakarsak, uygulamalarda bir veya bir kaç yer vardır, uygulama buraya gelince tıkanır. Malum bunlara bootleneck denir. Genel geçer böyle haller için, zaten sıradan kütüphaneler içinde gerekli yordamlar hazır kıta bulunur. Bunun dışında kalanlar içinse, optimum bir C kodu hazırlar kullanırsınız.

Java gibi dillerin hedeflediği platformlar kadar uygulamalar açısından da bakarsak, Javanın ciddi bootleneck yaratabileceği pek bir şey göremezsiniz. Ama mesela, real-time RAW->MPEG-4 dönüşümü veya DB/'2 gibi bir sunucu yapacaksanız, bu iş Javanın işi değildir. Zaten bu iş Javadan beklenmez.

Sonuçta paradigma üretmektense, profiling vs. işlerini özümser, tıkandığı yerde işi C gibi alt düzey kodlara yıkarsanız, hem daha çabuk, hemde yeterince hızlı uygulamalarınız olur..

ahmetaa
18 yıl önce

Adam iki uygulamayi da ayni platformda isletmis, bence adil bir test bu. aslinda Java 6 beta ile isletse sonuc cok daha dramatik olurdu diye dusunuyorum. Java gibi dillerin C'den daha hizli olmasi mumkundur (bugun bile). Ozellikle Java 6 ile bu konu iyice acikliga kavusacak saniyorum. Bu burada tartisilan bir konuydu ama atladiginiz noktayi basite hatirlatayim. C ve C++ gibi diller derlendikten sonra dogrudan makine uzerinde calisacak kod uretirler. Ancak kodun optimizasyonu islemi derleyici tarafindan yapilir ve kod iyilestirme genellikle son derece yereldir. yani ancak bir iki satirlik donguler, register atamalari vs derleyici tarafindan sezilebilir. Derleyici calisma aninda hangi metodun ya da hangi dongunun daha cok kullanilacagini sezemez. Oysa Javada durum farkli. iyilestirme sadece derleyici taraindan yapilmaz. kod sanal makine uzerinde isletilir. Sanal makine kodun hepsini ya da buyuk cogunlugunu makine koduna donusturur ama isi burada bitmez. metod cagrilarini, register kullanimini gozetlenir, cok kullanilan bir metod ya da dongunun varligi sezilirse bu kod sanal makine tarafindan calisma aninda gelistirilir. Bu sekilde C ya da C++ derleyicilerinin gozleyemedigi icin yapamadigi iyilestirme islemleri gerceklstirilmis olur. Java'nin bu davranisini gormek icin uzun sure claisan bir uygulamayi ya da cok tekrarli bir perofrmans testini java -server parametresi ile calistirarak deneyebilirsiniz. Java 6'da ayni davranis normal modda da gorulebiliyor. Java, gercekten cesili soyutlama, tehlikeli pointer numaralarinin eksikligi ve dizi sinir kontrolu gibi ozellikler nedeni ile normal durumda tabi olarak C'den yavas olacaktir. Ancak ileride bahsettigim konudan dolayi performans olarak C'ye yakin, ya da yerine gore daha hizli olur. Tabi asil konu Java ile C'den cokdaha hizli uygulama yazilimi gelistirebileceginiz ;) C - C++ programcilarinin bellek- pointer hatalarini ayiklamak icin harcadigi surede java ile isi rahatca bitirebilirsniz.. C++ kullanicilarinin bence artik uyanmasi gerekiyor.

yilmaz
18 yıl önce

JIT nedir bilmiyor ki kimse. Eski java da yoktu java ağırdı o zamanlar ordan kalma bir alışkanlık "java yavaştır".
Aslında java 'nın asıl problemi o değil daha ciddi problemleri var. Ama herkes tutturmuş bir "yavaşlık" gidiyor.

bio
18 yıl önce

JIT nedir bilmiyor ki kimse.

Siz de JIT nedir ne degildir ogrenin bu arada, ahmetaa'nin anlattigi sey JIT degil, hotspot compiler.

yilmaz
18 yıl önce

JIT mi HotSpot mu tartışmasına girmeyelim.
ama JIT ın faydalarını gormemek olmaz.


Just-In-Time Compiler


Sun's JREs now come with a just-in-time (JIT) compiler for both Windows and Solaris. The Windows version is provided by Symantec, but an alternative version is also available from Inprise. 


A JIT compiler speeds performance by compiling Java platform-neutral byte-code into a machine-specific native instruction set.

yilmaz
18 yıl önce

Bahsettiğim aynı compile methodunun java da da var olduğu.

skoylu
18 yıl önce

Birincisi, C öğrenmek saatlerin işidir, öteki tarafı sistemi bilmek tanımak, int nedir, register nedir, stack nedir vs. öğrenmekten geçer. İyi bir C programcısı dendiğinde kastedilen aslında sistemin dilinden iyi anlayan birisidir.
Eğer iyi bir C programcısı ile iyi bir Java programcısına aynı işi yapan makul kapsamda bir kod yazdırırsanız, çoğu durumda ikisinin aynı işi bitirmesi hemen hemen aynı zamanı alır. Çünkü, Java'nın sunduğu kadar C'de tonla kütüphane vs. sunar vede görev başına satır sayısı vs. pek değişmez.
Ama küçük programlar yazdırırsanız, 2-3 bin satır filan tutacak kadar olanlar mesela, Java programcısı diğeri daha çeyreğine gelmeden işi bitirmiş olur.
Ama bu adamlara, zaman filan sizin sorununuz, en hızlı kodu istiyorum derseniz, en az bellek harcayan kodu istiyorum derseniz, o zaman işi bilen Java programcısı, ben bu işte yokum der ve geriye çekilir. Çünkü, optimizasyon Java programcısının işi değildir. Bu iş Javaya düşer.
Bu nedenle, hiç bir zaman C ile yazdığınız kadar hızlı veya C ile olacağı kadar küçük ayakizine sahip bir kodu Java ile yazamazsınız.
Kaçıırılan nokta, tercihin en hızlı, en küçük vs. gibi olmadığıdır. En optimuma doğru tercih yapılır. Eğer uygulama yeterli hızı sağlıyorsa, geliştirme bakım maliyetleri daha düşük oluyorsa vs. gibi bir dizi etmen işin içinde yeralır. Bu noktada, olaya sadece dilin kendisi değil, debugger, editor, framework, support vs. gibi bir sürü etmen girer.
Kanım odur ki, güncel durumda Java çoğu işe yetecektir. Eğer istenen sonuna kadar performans ise Java gibi diller bu amaçla tasarlanmış şeyler değil.
İşini bilen C/C++ programcısı, bellek/pointer hatası ayıklamakla uğraşmaz ayrıca. Bu sadece işini bilmeyen kullanıcının sorunudur. C/C++ gibi diller için kullanım policy'leri çok iyi belirlenmiş halde. Ne yazacağınız bilmeden kodun başına oturuyorsanız, işinizi bilen bir C programcısı olamazsınız. Paldır küldür dalıp, Java, Python her neyse, ilerledikçe tıkanıp tıkanıp baştan yazılan yada lanet okutan tonla kod ortalıkta mevcuttur. Yanlış, Javanın paldır küldür programcılıkta kullanılmasıdır, Javada değildir. Doğru dürüst bir uygulama çapında baktığınızda, C veya Java yada LISP yada Python ile yazmak, zaman, emek vs. olarak çok bir şey farketmez. Çünkü uygulama geliştirmede zamanı alan, ne yapacağını bulmaktır. Bunu bulduıktan sonra ya hazır yapan bir kütüphane vardır, alınır, yada oturulup yazılır.

basbugunaskeri
18 yıl önce

hımm eğer iyi bir donanım seceneği sunma olanağınız varsa java tabii ki c den bile üstündür java yakında sırf java uygulaması geliştirmek isteyenler için ozel işlemciler tasarlıyorlar...:)

Görüş belirtmek için giriş yapın...

İlgili Yazılar

Java SUN'ı Yerken

auselen
26 Ağustos 2007, 1 dakika okuma süresi

Jonathan Schwartz'ın (http://blogs.sun.com/jonathan) 23 ağustos 2007 tarihli gönderisine göre SUN'ın NASDAQ etiketi "SUNW"'dan "JAVA"'ya çevrildi.

Java'nın Hücresel Telefon sürümünde güvenlik açığı

Soulblighter
24 Ekim 2004, 1 dakika okuma süresi

Polonya'lı bir güvenlik araçtırmacısı Java'nın hücresel telefonlar için olan sürümünde iki güvenlik açığı tespit etti. Açıklar gizli bilgilere ulaşılmasını ve telefonun kilitlenmesine neden oluyor.

Açığı tespit eden Adam Gowdiak, güvenlik açığına neden olan programın her telefondan çalışmadığını söyledi. Yaptığı testte ise bir Nokia 6310i hücresel telefonuna saldırı düzenledi. Yapılan saldırı testi dört saat sürdü.

Java'nın Başı Türkçe ile Dertte

oaygun
8 Ocak 2008, 1 dakika okuma süresi

Başınıza gelmiştir. Java temelli pek çok yazılımın kurulumunda, önce işletim sisteminin yerel ayarlarını değiştirmek (genellikle ABD, İngilizce), yazılımı kurmak ve sonra tekrar Türkçe'ye almak gerkmektedir. Bunun nedeni de 'i' harfidir. Alfabemizin 11 ve 12. harflerinin nelere kadir olduğunu gösteren bir makale: http://java.sys-con.com/read/46241.htm

Spring Framework

malkocoglu_2
16 Şubat 2005, 1 dakika okuma süresi

Spring Framework bilgi işlem sektöründe büyük ilgi görmeye başladı. Bu altyapıyı kullanan programcılar ve teknik liderler, altyapının ne kadar iyi ve yararlı olduğunu söyledikten sonra hernedense bu sebepleri teknik olarak bir türlü tarif edememektedirler. "Spring, Tivo gibidir" demiştir bir kullanıcı, "sahip olmadan değerini bilemezsin. Tarif edilemez". :) Bu yazımızda, gizem perdesini biraz daha kaldırmak ve Spring'in teknik yararlarını ortaya çıkartmayı amaçladık.

http://www.bilgidata.com/pdfs/spring.pdf

Evans Data: EMEA Bölgesinde Perl/Python/PHP Kullanımı Düştü

anonim
12 Ağustos 2005, 1 dakika okuma süresi

Bir araştırma şirketi olan Evans Data'nın yakın zamanda Avrupa, Ortadoğu ve Africa'da (EMEA) yaklaşık 400 programcı üzerinde yaptığı bir araştırma ilginç bir sonuç buldu: PHP kullanan programcıların sayısında %25'lik bir düşüş yaşandı ve PHP'yi gelecek projeler için incelemeyecek (evaluate) ve kullanmak istemeyecek programcılar aynı dönem için %40 kadar arttı. EMEA bölgesinde Perl kullanımı %20 kadar düştü. Python kullanımı da aynı şekilde bir düşüş yaşadı, bunun oranı ise %25. Python'u ileri projeler için incelemek istemeyen programcılar %17 kadar arttı.