Megjelent a D programozási nyelv 1.0-s verziója

Programozás

Több, mint 4 évvel az első közzétett verzió (2002.09.28.; v0.43) után megjelent a D programozási nyelv első stabil kiadása.

A kiadás magában foglalja:

  • a D nyelv specifikációját
  • a dmd fordítót Linux és Windows platformokra
  • a dmd szkript futtatási környezetet Linux és Windows platformokra
  • a Phobos library csomagot

A változások részletes listája itt található.

A dmd programcsomag ingyenesen letölthető innen, de létezik hozzá Gentoo ebuild és Debian csomag is.

A D nyelv egy modern rendszerprogramozási nyelv, amely ötvözi a C sebességét és rugalmasságát, a modern nyelvek (Java, C#, Python, Ruby) szolgáltatásaival és hatékonyságával. Összehasonlítás a C, C++, C#, Java nyelvekkel itt.

A D nyelvet számos editor és integrált fejlesztőkörnyezet támogatja, és elérhető hozzá egy nyílt forrású fordító GDC is, Linux és MacOS X platformokra.

( boobaa | 2007. 01. 04., cs – 09:43 )

Nem volna rossz abba az összehasonlító táblázatba még néhány oszlop, ha már ezekhez is hasonlítja magát ez az "új" nyelv: Python, Ruby, netán freepascal, imagine, akármi...

Az ok az gyakorlatilag mindegy, sajnos itt az eredmenyt kell nezni. A C++ nem kepes felvenni a versenyt (fejlesztesi) hatekonysagban es eszkozokben a modern nyelvekkel, sebessegben pedig az oskovulet C-vel.

Nehany pelda:
* template szintaxis egy gany
* modern adatstrukturak nincsenek beepitve a nyelvbe, csak STL-en vagy mas konyvtarakon keresztul elerhetoek
* const ganyolas
* include hell
* RAII hianya
* a specifikacio olyan bonyolult, hogy irdatlan nehez jo forditot irni, raadasul ahany fordito annyi fele implementacio

+

- nincs rendes szabvanyos ABI, ezert a binaris szinten egyuttmukodo komponens rendszerek (RPC, COM/DCOM, Corba) a C++ valamilyen resszolgaltatasan alapulnak (interfeszek, nincs kivetelkezeles, nincs tobbszoros oroklodes, kell a refcount).
- miert nincs szabvanyositott konyvtar a halozatkezelesre, 3D-re, GUI-ra. Miert a vector es a qsort() a legmagasabb szintu szolgaltatas a standard konyvtarban? Osszehasonlitaskeppen a .NET Framework vagy a Java library rengeteg szolgaltatast nyujt. Ennek a kovetkezmenye az is, hogy egy nagyobb programban hasznalt konyvtarak fele referenciaszamlalos, a masik fele nem. Raadasul eleg sok erofeszites megy el arra, hogy parhuzamosan keszitsenek el nyilt grafikus keszleteket (pl. Qt, GTK+, wxWidgets, ...). Ahelyett, hogy lenne egy jo es mindenki azt hasznalna es javitana.
- reflection jo lenne

"miert nincs szabvanyositott konyvtar a halozatkezelesre..."

Mert megszűnne a választás lehetősége.
Mert a legtöbből még nem született (némelyből nem is születhet) megfelelően általános.

És mert az utolsó szabvány 98-as.

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

"* template szintaxis egy gany
szubjektiv velemeny.."

Szubjektiv velemeny, de egyezik a C++ programozok 99%-anak szubjektiv velemenyevel. Tehat erdemes lenne kicsit megszerelni. Ismert ugye >> es a > > kozotti kulonbseg a template hasznalat soran? Es ez csak a felszin.

"
* modern adatstrukturak ...
stl a nyelvspecifikacio resze; miert lenne jobb, ha nem kene inkludolni mondjuk egy
-et?"

Az STL elavult es keves szolgaltatast nyujt. Hianyzik belole pl. a szerializacio.

"Az STL elavult es keves szolgaltatast nyujt. Hianyzik belole pl. a szerializacio."

Ez pont az integrálás ellen érv. Mert ha a nyelv része és egy feature hiányzik, akkor újra kell specifikálni a nyelvet.

Ha külső lib, akkor meg csak meg kell írni hozzá.
ld Boost::Serialization.

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

A Boost akkor lenne okos dolog, hogyha egy altalanosan hasznalhato konyvtar lenne. De tele van hianyossagokkal es a modulok egy resze abszolut experimental. En a numerikus matek reszhez ertek valamennyire es annak a szolgaltatasai maximum egy szakdolgozat megirasahoz elegek, nem egy tisztesseges program fejlesztesehez. A szalkezelo reszek detto hurkak.

Boost-os szerializacio vajon tudja szerializalni egy third party cuccos objektumait? Talan (nem tudom). Es egy third party zart forrasu lib cuccait? Szinte biztos, hogy nem, mert a nyelv hianyossagai miatt a szerializacio eleg intruziv.

Szemben pl. a C#/.NET-el, ahol ez szinte csettintesre megy (najo egy attributumot hozza kell biggyeszteni, de mukodhetne anelkul is, lasd: db4o). Es a szerializacio a .NET Framework resze. Es senki nem vagta fel az ereit, mert resze.

A C++ allapotarol jo kepet fest, hogy 98-as a szabvany es 2-3 eve jelentek meg a tobbe kevesbe szabvanyos forditoprogramok, a konyvtar meg ugy siralmas, ahogy van.

"En a numerikus matek reszhez ertek valamennyire es annak a szolgaltatasai maximum egy szakdolgozat megirasahoz elegek"

Hja, majd ha találsz egy nyelv/lib párost, ami mindenre egyformán jó, akkor szólj, többünket érdekelne. :)
Mondtam én, hogy a Boost überjó? Nem. Csak mondtam, hogy van benne szerializáció.

Egyébként csak egy keretrendszer van megírva, azt kell igazítani a saját típusaidhoz, és működik az eredeti osztályok változtatása nélkül is. Persze egyszer meg kell írni, nem megy magától.

Végülis korrekt dolog egy néhány éves C#/.NET pároshoz hasonlítani egy több mint 10 éves rendszert, de akkor ott van neked a Managed C++/.NET.
Szérializálhatsz amennyit akarsz.

Nem tetszik a STL? Használj Qt-t. Vagy amit akarsz.

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

Ne terelj! Arra mutattam ra, hogy a Boost:
- Nem altalanos celu
- Nem megbizhato
- Nem mukodik egyutt jol a tobbi elterjedt konyvtarral (OSG, Qt)

Ez persze nem mind a Boost hibaja. A C++ bizonyos hianyai miatt nem is igazan lehet jobban csinalni.

"Végülis korrekt dolog egy néhány éves C#/.NET pároshoz hasonlítani egy több mint 10 éves rendszert, de akkor ott van neked a Managed C++/.NET.
Szérializálhatsz amennyit akarsz."

1. Nehogymar en szegyelljem magam, mert a C++ rank rohadt meg az elozo evszazadbol. Szegyellje magat a szabvanyosito bizottsag, a vendorok es konyvtarfejlesztok...
2. Engem, mint fejlesztot az erdekel, hogy hatekonyan tudjak dolgozni. Es kepes legyek a piacon kaphato konyvtarakat, amik komoly tudast tartalmaznak egyutt hasznalni. Tobbek kozott errol szolna az objektumorientalt fejlesztes. Nem arrol, hogy hasznalhatsz Qt-t de akkor nem mukodik a boost, vagy hasznalhatok Boost-ot, de akkor nem megy jol az OSG. Rohej.
3. Szep dolog, hogy a szerializaciora hegyezed ki a bamba poent, csak az a baj, hogy legalabb ezer ilyen dolgot lehetne meg kitalalni (csak peldak: titkositas, multimedia, perzisztencia, remoting). A mult evtized elejen meg le lehetett nyugozni az embereket, hogy milyen fasza dolog a queue, de ma mar erezhetoen keveske.

"Nem tetszik a STL? Használj Qt-t. Vagy amit akarsz."

Eppen ez a sz*runk bele magatartas miatt rekedt meg a C++ fejlodese. Mert nem vallaltak fel, hogy vannak problemak, amiknek nem trivialis a megoldasa. Bedobtak a gyeplot, es szivunk mi a fejlesztok, ugyanarra a problemara ezerfele rossz- illetve felmegoldast hasznalva.

"Ne terelj! Arra mutattam ra, hogy a Boost:
- Nem altalanos celu
- Nem megbizhato
- Nem mukodik egyutt jol a tobbi elterjedt konyvtarral (OSG, Qt)"

Ha már terelés, hogy jött ide a Boost?
Csak egy példa volt. Egy példa a felvetett példádra.
Tehát aki a "szerializaciora hegyezi ki a bamba poent" az nem én vagyok.

Onnan indultunk, hogy az STL elavult (szerintem nem) és kevés szolgáltatást nyújt.
Ez meg tény, de van helyette más.
Sőt nem is gondolom, hogy jó dolog ha minden az STL része.
Érdekes módon azért senki sem sír, hogy a C szabványnak nem része sem a hálózat sem a thread kezelés.

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

"* template szintaxis egy gany
szubjektiv velemeny.."

legyen :-)

"* modern adatstrukturak ...
stl a nyelvspecifikacio resze; miert lenne jobb, ha nem kene inkludolni mondjuk egy
-et?"

Abban azert gondolom, hogy egyetertunk, hogy az STL meg az elegancia tavol vannak egymastol. Egyszeruen iszonyatosan ronda lesz a kod, amikor hasznalaod. Latszik, hogy nem integralt resze a nyelvnek.

"* const ganyolas
const_cast, mutable, vagy mire gondolsz?"

in/out parameterekre gondolok elsosorban

"Egyszeruen iszonyatosan ronda lesz a kod, amikor hasznalaod."
Szubjektív.
Nekem két dolog nem tetszik mindössze.
1) Az iterátor megadása. Az, hogy fel kell sorolni az összes template paramétert. Persze typedef sokat segít.
(c++0x-ben lesz valami auto kulcsszó erre)

2) Functor megadása. Nem lehet helyben. Illetve csak trükközve (lásd Boost::Lambda).
(szintén c++0x)

"in/out parameterekre gondolok elsosorban"
Biztos én vagyok a perverz, de nekem így jó.
De talán nem lenne hülyeség egy "Move constructor". Valahol olvastam is hasonlót. Nem tudom elvetették-e a következő szabványból.
Addig meg smart_ptr a te barátod...

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

"Az ok az gyakorlatilag mindegy"
Szerintem nem, de ezen nem veszünk össze. A C kompatibilitás olyan feature ami a többi magas szintű nyelvben nincs benne. És azért elég sokszor jól jön.

"template szintaxis egy gany"
Ha arra használod amire kitalálták, nincs vele gond. Metaprogramozásnál persze már vannak csúnya dolgok.

"modern adatstrukturak nincsenek beepitve a nyelvbe"
Nekem nem is hiányznak. És nem is logikus, hiszen az összes szóbajövő adatstruktúrát úgysem lehet a nyelvbe paszírozni. (Hány nyelvben van alapból gráf?)
Az adatstruktúrák egyforma kezelése pedig fontos, enélkül nehéz lenne általános algoritmusokat írni.

"const ganyolas"
Ezt nem értem.

"include hell"
C-ből jött. És nem értem miért Hell.

"RAII hianya"
Wiki:
"Resource Acquisition Is Initialization, often referred to by the acronym RAII, is a popular programming technique in C++ and D."
Miről is beszélünk? Ez inkább a Java-val szemben érv.

"a specifikacio olyan bonyolult, hogy irdatlan nehez jo forditot irni, raadasul ahany fordito annyi fele implementacio"
A specifikáció bonyolultsága a C miatt van.

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

>"Az ok az gyakorlatilag mindegy"
> Szerintem nem, de ezen nem veszünk össze. A C kompatibilitás olyan > feature ami a többi magas szintű nyelvben nincs benne. És azért elég
> sokszor jól jön.

Nem nagyon jut most olyan pelda eszembe, ahol direkt szintaktikai kompatibilitas kellne. A D peldaul kepes C libraryket hasznalni, ez azt hiszem, hogy eleg sok mindenre eleg.

> "template szintaxis egy gany"
> Ha arra használod amire kitalálták, nincs vele gond.
> Metaprogramozásnál persze már vannak csúnya dolgok.

Masik hozzaszolasban leirtam.

> "modern adatstrukturak nincsenek beepitve a nyelvbe"
> Nekem nem is hiányznak. És nem is logikus, hiszen az összes
> szóbajövő adatstruktúrát úgysem lehet a nyelvbe paszírozni. (Hány
> nyelvben van alapból gráf?)
> Az adatstruktúrák egyforma kezelése pedig fontos, enélkül nehéz
> lenne általános algoritmusokat írni.

Nyilvan nem a beepitett grafokat szoktak hianyolni a C++-bol. Hanem mondjuk a dinamikus tomboket, mapeket, stringeket, slicingot, stb. Nem veletlenul vannak ezek az adatstrukturak _beepitve_ a modern nyelvekbe. Egyebkent nem latom, hogy egy beepitett adatstruktura miert ne biztositana egysges kezelest.
(Az STL nem beepitettsge a szintaxison mulik es nem azon, hogy resze-e a specifikacionak vagy nem.)

> "const ganyolas"
> Ezt nem értem.

Masik hozzaszolasban leirtam.

> "include hell"
> C-ből jött. És nem értem miért Hell.

Mert nincs nyelvi szinten tamogatva a linkelesi fuggosegek tulburjanzasanak megakadalyozasa, illetve az includeok egymasba agyazasanak megakadalyozasa.

> "RAII hianya"
> Wiki:
> "Resource Acquisition Is Initialization, often referred to by the acronym > RAII, is a popular programming technique in C++ and D."
> Miről is beszélünk? Ez inkább a Java-val szemben érv.

Bocs, igazad van, ez tenyleg csak a C-re igaz.

> "a specifikacio olyan bonyolult, hogy irdatlan nehez jo forditot irni,
> raadasul ahany fordito annyi fele implementacio"
> A specifikáció bonyolultsága a C miatt van.

Az eredmenyen ez sajnos nem valtoztat.

"Nyilvan nem a beepitett grafokat szoktak hianyolni a C++-bol. Hanem mondjuk a dinamikus tomboket, mapeket, stringeket, slicingot, stb. Nem veletlenul vannak ezek az adatstrukturak _beepitve_ a modern nyelvekbe."

Ez szép és jó, csak akkor már nem tudod egységesen kezelni a beépített dinamikus tömböt, és az utólag hozzáírt gráfot.

Egységes kezelés alatt azt értem, hogy C++-ban ha definiálni tudsz egy adatszerkezetre egy bejárót, onnantól kezdve az algorithms nagy része a rendelkezésedre áll. Erről szól a generikus programozás.
Ha van n adatszerkezeted és m algoritmusod, akkor nem n*m-szer kell dolgoznod, hanem n+m-szer.

Egyébként a gondolatmenet alapján a Java pl szintén nem "modern nyelv".
Se slicing, se _beépített_ adatszerkezetek....

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

Akad a C++ házatáján mit takarítani.

1. Próbáltál már debuggolni template hegyekkel megáldott kódot? A vérizzadás ennek egy finom minősítése.
2. Létezik olyan C++ kód, ami hiba nélkül lefordul Visual Studióval és gcc-vel is?

A C++ egyetlen előnye, hogy létezik - a C-hez viszonyítva, amiben ugye nincs OO rész. Más előnyét nem ismerem.

Én speciell meg fogom nézni a D-t, hátha ... :)

--
Kinek nem inge, ne vegye gatyára

1.
Igen. Gyönyörű :)
Egyébként ez inkább a fordítók, és azok hibaüzeneteinek a tökéletlensége mint a nyelvé. Vagy legyen is-is.

2.
Létezik. Rengeteg.
Főleg, ha nem VC 6.0-val próbálkozol. Mert az egy szar.
De afölött már egész korrekt.
Persze ne is gcc 2.9x-el. 3.4 felett már egész korrekt. :)

Félre ne értsetek szerintem a C++ nem a lehetséges legjobb nyelv.
De az elterjedt nyelvek közül talán a legjobb. (Hogy a Java fanok is örüljenek, legyen az egyik legjobb)
Csak utálom, ha olyanok fikázzák akik sose használták. (De azért látom vannak itt értelmes lények is :) )

A D nyelv nem csak nevében a következő lépés.
Pl mikor a template-et kitalálták senki nem gondolta, hogy olyan perverz dolgokat fognak vele művelni amit manapság. A C++ azért jó, mert ha nem is szépen de meg lehet csinálni. (Hozzátenném, sehol máshol.)

A D-ben ezt tovább gondolták.
Most olvasgatom, nekem tetszik, de ha senki nem áll mögé, sosem fog elterjedni. Az, hogy mögé áll-e valaki az eléggé kérdéses a mai VM-es világban.

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

a .net a vista fejlesztése alatt megbukott mint általános c/c++ utódnyelv. miután rájöttek, hogy stabilitási problémák és hatalmas erőforrásigény miatt a .net alkalmatlan arra, hogy egy mainstream os nagyrészét ebben fejlesszék, az addigi munka nagyrésze a kukába ment 2004 körül, illetve a menthető része singularity néven, egy akadémikus kísérleti játékba. majd újrakezdték az egész munkát a régi sokat szidott c++ban. mára így legalább sikerült működőképes kódot összehozni.
.net majd egyszer valamikor a jövőben. céges alkalmazásokhoz persze már ma is jó, de nem kell túlbecsülni a lehetőségeit.
egyébként vmi ilyesmi lett volna az eredeti vista. imho ez tetszett is, nem úgy mint az, ami végül lett belőle.

>> mint általános c/c++ utódnyelv
a .net sosem volt nyelv

>> rájöttek, hogy stabilitási problémák
például?

>> hatalmas erőforrásigény
komoly elemzők állították, hogy 2003-ra 5-6Ghz-es procik lesznek, erre készültek, gyász

>> a menthető része singularity néven
ez nem igaz

>> egy akadémikus kísérleti játékba
szeretnél te ilyen játékot látni egyszer életedben

komoly elemzők állították, hogy 2003-ra 5-6Ghz-es procik lesznek, erre készültek, gyász

Ahah, ilyenkor röhögök jókat a szakértő urakon, akik az OOO lassúságát és erőforrásigényét hozzák fel egyik példa gyanánt a FOSS abortív mivoltával kapcsolatban.
--
Gentoo motto: It's worth spending eight hours trying to make something load 20ns faster.

nagyságrendileg hasonló értékeket felvonultató másik szoftver

Ez egy szubjektív fogalom az esetek többségében, de ha van valami objektív öszehasonlítás (MSO vs. OOO, Windows desktop vs. Linux desktop), szeretettel várom.
Most jöhetnék worksforme-vel is, de nem teszem. ;-)
--
Gentoo motto: It's worth spending eight hours trying to make something load 20ns faster.

szerintem nincs nagyságrendi különbség a lényeges funkciók között (tehát az mso nincs fényévekkel elmaradva az ooo funkcionalitása mögött) - így értettem, és az ooo-sok saját bevallása szerint gyúrniuk kell (és teszik is) sebességre

egy -túlnyomórészt- managelt kódban lézező o/s-nek viszont nincs párja értékben, amihez hasonlíthatnám
(így az erőforrásigényén sem szánakoznék)

egy -túlnyomórészt- managelt kódban lézező o/s-nek viszont nincs párja értékben, amihez hasonlíthatnám
(így az erőforrásigényén sem szánakoznék)

Majd tesztcéllal felrakok egy Vistát, addig én sem szívesen kommentálnám az ilyesmit, BTW a te olvasatodban mi a managelt kód?
--
Gentoo motto: It's worth spending eight hours trying to make something load 20ns faster.

C# valoban nem rossz de azert lenne meg azon is mit csiszolni:
- relativ namespace bug feature (remalom amikor egy masik gyoker namespace-ben ugyanolyan szintek vannak)
- typedef hianya /* sealed osztalyokat ugye nem lehet leszarmaztatni */
- aprobb nyug: az egesz namespace rendszeret illene ujrarendezni, mert lassan elkorcsosodik
- nem artana mar befejezni a VS2005 beta tesztjet is es egy stabil fejlesztoeszkozt kiadni hozza...

Minél korszakalkotóbb ötlettel állsz elő, annál több hülyén kell átverekedned magadat.

Igazabol nem lett volna rossz, ha kicsit objektivebb a tablazat.
Pl kicsit santit, amikor azt allitja, hogy a Java nem tamogat asszociativ tomboket. Persze, nyelv szinten nem, de a collections framework igen, ami resze az alap API-nak.
Masreszt semmit nem mond a beepitett alap konyvtarrol, a kod hordozhatosagarol, etc, ami mondjuk pl a Java legnagyobb elonye.
Fura, hogy pl tamogatja az inline assembly-t. Ez fun volt meg anno Turbo Pascal-os idokben, de nem vagyok benne biztos, hogy a modern, kernel alapu OS-eknel ennek a hasznalata jo 5let lenne. Arrol nem is beszelve, hogy a kod portabilitasa azonnal elveszik ezzel.

Mindenesetre erdekes, egy csekkolast meger, mert vegre egy olyan nativ nyelv, amibol tudatosan kihagytak a C/C++ ganyait. (Pontosan ezert szeretem pl a Java-t)
BTW mennyire tamogatott/szabvany nyelv ez, nem tudja valaki ? Erdemes vele foglalkozni hosszu tavon ?

( ParadoxH | 2007. 01. 04., cs – 11:20 )

Még el se kezdtem megtanulni rendesen a C-t. Öt év mulva azzal jönnek, hogy nem érek vele semmit? :P

Dehogynem, lasd fentebb. ;-)

Teny, hogy az egesz iparag a C-re van beallva. Egyelore rengeteg processzorhoz (kulonosen mikrokontrollerek) hianyoznak a forditok, stb, de megsi ezen a teruleten erheti el szerintem a D a leggyorsabb sikereket.

A beagyazott rendszereken meg mindig kritikus a sebesseg, de nagyon fontos a gyors es hatekony fejlesztes is.

( syntern | 2007. 01. 04., cs – 15:29 )

Néhány hete kipróbáltam, hogy mit tud. Csak úgy mikorbenchmark szinten, Java vs C++ vs D: az eredmény a D szempontjából lesújtó: jóval lassabb kódot fordított, mint a C++ vagy a Java futás (amelyek egyébként elég közel voltak egymáshoz). Szóval nem győzött meg.

Most akkor van teszt vagy nincs? Erdekelne, hogy mit teszteltel (kod), es milyen eredmenyek jottek ki. (Mit jelent az, hogy _nagyon_ alulmaradt.) Ha kozzetenned akkor be tudnam kuldeni a digitalmars listara, hatha vmi bug vagy hianyzo optimalizacio okozza a sebessegkulonbseget.

Nem muszaj ide, lehet egy forum temaba is vagy egy kulon hirbe. Sot kerhetunk C++ vs Java flame moderlalast is, hatha trey bevallalja. ;-)

Nem vonom ketsegbe sem a szavadat, sem a szakmai tudasodat, de enelkul a hozzaszolasod nem er tul sokat.

Itt a D kód. A Java és a C++ meglepően nehezen reprodukálható :P

(Annyi van vele, hogy Javaban azért külön metódusba kell szervezni, és 10 futás átlagát kell nézni, lásd lentebb) 


int main () {
        int[30000] tomb;
        int i = 0, j = 0;
        for (i = 0; i < 30000; i++) {
                tomb[i] = i*i % 33;
        }
        for (i = 0; i < 30000; i++) {
                for (j = i+1 ; j < 30000; j++) {
                        tomb[(i+j)%30000] = (i + tomb[i] + tomb[j] * 17) % 33;
                }
        }
        return 0;
}

Ami nincs meg, az a konkrét időeredmény, mert már legyalultam arról a gépről a D-t, és semmi kedvem babrálni vele újra. Ha kiméred, érdekel az eredmény...

Ezzel csak az a gond, hogy annyira nem használ semmit a nyelvből, hogy ha nem sorra ugyanazt az asm kódot produkálja, mint a C vagy a C++, akkor ott vmit nagyon el..sztak.
Ami egyébként nem túl hihető, főleg egy gdc esetében.

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

"Itt a D kód. A Java és a C++ meglepően nehezen reprodukálható :P"

Amikor meg csak idaig olvastam, akkor teljesen bevettem. Azon gondolkozdtam, hogy mi lehet olyan kulonleges benne. Aztan, amikor elolvastam a kodot, akkor azon kezdtem gondolkodni, hogy syntern baratunk mit szivott. Aztan meglattam a smileyt. :-)

"Ami nincs meg, az a konkrét időeredmény, mert már legyalultam arról a gépről a D-t, és semmi kedvem babrálni vele újra. Ha kiméred, érdekel az eredmény..."

Meg fogom csinalni, de lehet, hogy csak a hetvegen jutok hozza.

Hat nem tudom, hogy te mit mertel, de vmit nagyon benezhettel.

Itt vannak az en mereseim:

-------------------------------------------------------------------------------------------
Gep adatai:

david@fokolompos /home/data/david/dev/sandbox/benchmark $ uname -a
Linux 2.6.18.2 #1 PREEMPT Sun Nov 19 07:30:12 CET 2006 i686 Intel(R) Celeron(R) CPU 2.40GHz GenuineIntel GNU/Linux

david@fokolompos /home/data/david/dev/sandbox/benchmark $ free -m
total used free shared buffers cached
Mem: 505 478 26 0 35 232
-/+ buffers/cache: 210 294
Swap: 486 0 486

-------------------------------------------------------------------------------------------
Kod:

C: 


int main(void)
{
    const int arraySize = 30000;
    int myArray[arraySize];
    int i;
    int j;
    for (i = 0; i < arraySize; i++)
    {
        myArray[i] = i * i % 33;
    }
    for (i = 0; i < arraySize; i++)
    {
        for (j = i + 1; j < arraySize; j++)
        {
            myArray[(i+j)%arraySize] = (i + myArray[i] + myArray[j] * 17) % 33;
        }
    }
    return 0;
}

C++: 


int main(void)
{
    const int arraySize = 30000;
    int myArray[arraySize];
    for (int i = 0; i < arraySize; i++)
    {
        myArray[i] = i * i % 33;
    }
    for (int i = 0; i < arraySize; i++)
    {
        for (int j = i + 1; j < arraySize; j++)
        {
            myArray[(i+j)%arraySize] = (i + myArray[i] + myArray[j] * 17) % 33;
        }
    }
    return 0;
}

D: 


int main()
{
    const int arraySize = 30000;
    int[arraySize] myArray;
    for (int i = 0; i < arraySize; i++)
    {
        myArray[i] = i * i % 33;
    }
    for (int i = 0; i < arraySize; i++)
    {
        for (int j = i + 1; j < arraySize; j++)
        {
            myArray[(i+j)%arraySize] = (i + myArray[i] + myArray[j] * 17) % 33;
        }
    }
    return 0;
}

-------------------------------------------------------------------------------------------
Makefile: 


all: 
	gcc -mtune=pentium3 -O2 -pipe test_cpp.cpp -o test_cpp
	gcc -mtune=pentium3 -O2 -pipe test_c.c -o test_c
	dmd test_d.d -O

-------------------------------------------------------------------------------------------
Forditok:

dmd:
david@fokolompos /home/data/david/dev/sandbox/benchmark $ dmd -v
Digital Mars D Compiler v0.173
Copyright (c) 1999-2006 by Digital Mars written by Walter Bright

gcc:
david@fokolompos /home/data/david/dev/sandbox/benchmark $ gcc -v
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/specs
Configured with: /var/tmp/portage/gcc-3.4.6-r1/work/gcc-3.4.6/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.4.6 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.6 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.6/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.6/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/include/g++-v3 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --disable-multilib --disable-libgcj --enable-languages=c,c++,f77 --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)

-------------------------------------------------------------------------------------------
Meresi eredmenyek:

david@fokolompos /home/data/david/dev/sandbox/benchmark $ time ./test_c

real 0m18.017s
user 0m17.757s
sys 0m0.216s

david@fokolompos /home/data/david/dev/sandbox/benchmark $ time ./test_cpp

real 0m14.330s
user 0m14.109s
sys 0m0.180s

david@fokolompos /home/data/david/dev/sandbox/benchmark $ time ./test_d

real 0m16.843s
user 0m16.617s
sys 0m0.180s

-------------------------------------------------------------------------------------------
Megjegyzes:

Javat nem teszteltem, mert nem akarok hosszu flamet a Java optimalizalasarol. Nekem most eleg volt a C, C++, D.

-------------------------------------------------------------------------------------------
Konkluzio:

Nem latom a szignifikans kulonbseget.

Nem vonom kétségbe a méréseidet, de fenntartom a saját korábbi eredményeimet. Ami különbség lehet:
- verziók (már nem tudom milyen gcc-vel mértem, de van amelyik irtó pocsék kódot képes fordítani)
- disztribúció (úgy vettem észre, hogy lényeges különbség van ugyanazon gép esetében akkor, ha a háttérlibek is procira vannak optimalizálva, azaz pl. a gentoo disztribes teszt nagyon más eredményt tud adni, mint egy ubuntus)
- proci-cache méret (ha éppen kiesik valamelyik futtatásnál a cache-ből a következő hit)
- csillagállás :)

Termeszetesen csinaltam tobb merest, de a szoras minimalis volt.

Egyebkent nem tulajdonitok kulonosebb jelentoseget a dolognak, hiszen a meres nem reprezentativ szinte semmilyen szempotnbol, csak arra voltam kivancsi, hogy tenyleg kiderul-e vmi optimalizacios problema.

Ami viszont kiderult, hogy a gcc ebben a konkret esetben meglehetosen furcsa dolgot muvelt, mert arra almomban sem gondoltam volna, hogy ennel a kodnal a C lassabb lesz.

A C és C++ kódban máshogy deklarálod az i és j változókat, ezért C esetében memóriába kerülnek és ott inkrementálódgatnak, C++ esetében viszont regiszterben. C99 már engedi ezt a "C++-féle" deklarációt is, -std=c99 opcióval fordítva gyorsul is a C változat valamennyit, de még mindig elmarad a C++ változattól.
Vannak még különbségek a generált asm kódban, de azok megértéséhez én már kevés vagyok.

Ezt ismerem, kb. ott bukik meg, hogy a Java kód akkor tudja kihasználni a -server kapcsolót, ha mondjuk legalább 10-szer lefuttatod a teljes tesztet, és mondjuk átlagolod a futásokat. Az első futásra ugyanis még nem gerjed be az optimalizáló fordító, legfeljebb interpretált módban fut. Ezt jól be is szívtam egyszer, amikor vagy 10-szeres lassulást mértem a Java-n a C++-hoz képest. Aztán kiderült, hogy a fenti módszerrel alig 10-20%...

Arról nem is beszélve, hogy ezek a tesztek a JVM startup time-ot is beleszámolják a futási időbe. Szóval megbízható :)

Ha interetált lenne, ezen mérés akkor szerintem ~4-5 ször lassabb lenne (minimum) a jáva a C-töl, miden esetben.

"Each program was then run 3 times with program output redirected to /dev/null. We show the lowest measured CPU time and the highest memory usage, from the 3 runs."
------
gentóhuszár

http://sourceforge.net/projects/javavscpp/files

Ezt a teljesítménymérést én és egy hallgatóm csináltuk. Meg tudod nézni a kódokat, ott van a gép és az oprendszer specifikáció, valamint az összes olyan elemzés, hogy miért _nem_lassabb_ a Jáva, sőt, miért gyorsabb bizonyos esetekben.

Persze ettől még nyugodtan lehetsz ignoráns, és mondhatod a "Java lassú" mantrát :)

És akkor innen indul, hogy kb nem lehet mérni semmit.
Mert nekem a startup ugyanúgy beletartozik a futásidőbe. Persze komolyabb programnál nyilván elhanyagolható.

Illetve hajamra kenhetem az optimalizáló fordítót, ha nem futtatok valamit 10x, mondjuk egy GUI programban, és nem értem, miért kell bika gép egy eclipse-nek.

Egyszer látnék benchmarkot normálisan összemérhető és nem légbőlkapott programokkal...

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

Az én benchmarkom java vs cpp ügyben lásd feljebb. Mi nem azt mértük, hogy mikor indul a JVM, hanem azt, hogy mennyi ideig fut egy kód az adott nyelven. Elég sokszor ellenőriztük, és nem csak a cikkben leírt konfigurációkon.

Egyébként igazad van: egy GUI program esetén a startup beleszámít, de meg lehet ezt fogni más oldalról is: a startup általában elhanyagolható idő akkor, ha hosszabb ideig fut a program. Java-t tipikusan nem 45 ms alatt lefutó perl script helyett használsz, hanem vagy szerver oldalon egy indítással hónapokig futó alkalmazásban, vagy olyan gui-ban, amit órákon keresztül használsz.

Az Eclipse meg egyszerűen csak szar, használj helyette pl. Netbeans-t :). De van más jól megírt és responsive java gui program is...

Jah, és egy nagyon impresszív benchmark, beszédszintetizátor C kód átírva Java-ra:
http://freetts.sourceforge.net/docs/index.php#performance

Hmmm, ezt szomorúan hallom.
Mondjuk meglepődtem volna, ha nem így van, elvégre egy ennyire új/kevéssé fejlesztett nyelv esetében nem várhatunk túl fejlett optimalizációt a fordítókban.

Meg is lepődtem a D nyelv honlapján közzétett (egyetlen) benchmarkon, ami (természetesen) a D nyelvet hozta ki győztesnek...

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

Miért nem?
A GCC például három rétegű: frontend (forráskód elemzés és belőle RTL felépítése), RTL optimalizáció, és backend (kódgenerálás az adott processzor, Operációs Rendszerh és kimeneti formátumnak megfelelően). Ha a D nyelvnek jól elkészítik a frontendjét és a bootstrap kódot, valamint a beépített feladatok ellátása (pl. GC megvalósítáasa) is megvan, akkor már fordítja is az új nyelvet optimalizáltan. Ráadásul a GCC már régóta tud jópár dolgot: pl. GC a java fordításkor, beágyazott függvények C/C++ nyelv esetén is, stb.

Persze. De ha a programozási nyelvnél nem az alkalmazhatóság okoz nehézséget (mert a D-nél ezzel pl. nincs gond), hanem a teljesítmény, akkor sebességtesztet kell írni :). Pythonhoz pl. nem is írok sebességtesztet :P

Komolyabban szólva: Sok év tapasztalattal és sok programozási nyelv ismeretével egy újabb megtanulása / átlátása már nem egy nagy cucc. Ami eldöntheti, hogy érdemes-e vele foglalkozni, az kb. az, hogy
- Összemérhető-e a gyorsasága a jelenleg elterjedt platformokkal. Ha nem, akkor úgysem terjed el production környezetben.
- Ha összemérhető (legfeljebb 2x-es szorzó), akkor nyújt-e annyi plusszt, ami megnöveli a hatékonyságot annyira, hogy megérje alkalmazni.

Nos, a D számomra elbukta az elsőt, és a másodiknál eléggé alulteljesít a Javahoz képest. Szóval maradok Java programozó :)

( palmaci | 2007. 01. 04., cs – 19:51 )

A BAPC volt a legkiralyabb nyel amivel eddig dolgoztam, imadtam. Gyorsvolt 1xru mint a 100-as szeg. Csak sajna mar nem fejleszi 1 A'rpi nevu emberke.....

( bervi | 2007. 01. 05., p – 09:46 )

nna. írjanak (át) egy rendszert D-ben(be), utána beszélünk. hehe