Zou ik van Java moeten overschakelen naar C++?

[Verwijderd]

Beste Tweakers,

Ik probeer zo af en toe een informatica vak (universiteit) te volgen als m'n rooster het toelaat. Vorig jaar heb ik het vak datastructuren in Utrecht gedaan waarbij gebruik werd gemaakt van Java. De tutorial op de sun website is heel uitgebreid en duidelijk. Het was de eerste taal die ik leerde die object georiënteerd was. Ik vind de structuur van java een java programma heel overzichtelijk. Een extra plus is dat de code vrij portable is.

Nu studeer ik mijnbouw in Zweden en deze periode heb ik de tijd om een extra vak over 'Computer Graphics' te nemen. Het idee is dat ik in dit vak veel gebruik zal gaan maken van OpenGL. De docent heeft geen ervaring met de OpenGL bindings in Java. Daarom raadde hij me aan om C++ te leren in combinatie met de QT library. Het schijnt dat die code ook vrij portable is.

Denken jullie dat het leren van C++ meerwaarde heeft? Of kan ik de tijd beter besteden om wat geavanceerdere technieken in java te leren? Ik verwacht later in de modelleer richting terecht te komen (modelleren van stress/deformatie in gesteente), hebben compiled languages zoals fortran en c(++) nog veel snelheidsvoordeel? Ik begreep dat java steeds sneller en dat JIT compilatie ook een positieve bijdrage levert aan de snelheid. Dat zou ook wel een punt ter overweging kunnen zijn.

Ik snap dat deze vraag gedeeltelijk neerkomt op voorkeur en waarschijnlijk dus geen definities antwoord zal geven. Ik ben alleen wel erg benieuwd om te horen wat voor reacties er van ervaren programmeurs komen.

Bram

[Soultaker]

Dit soort vragen zijn altijd lastig om objectief te beantwoorden, omdat het antwoord altijd in grote mate afhangt van wat je zelf van plan bent. Aan de ene kant is het nooit helemaal zinloos om een nieuwe taal te leren om daarmee je horizon te verbreden (en zelf een betere inschatting te kunnen maken welke taal het meest geschikt is om een probleem op te lossen). Aan de andere kant lijken de toepassingen die je voor ogen hebt me niet concreet aanleiding geven om van Java naar een andere taal te switchen.

De performance van Java is over het algemeen prima. Java programma's worden ook gewoon gecompileerd (het is me uit je post niet helemaal duidelijk of je je dat realiseerde) dus meestal zit je met een goedgeschreven Java-programma op z'n minst in dezelfde orde van grootte als een C++ of Fortran programma, zeker op moderne systemen.

Wat betreft OpenGL: de primaire API is gebaseerd op C. De bindings in Java en C++ zijn daardoor ook ongeveer hetzelfde. Als je goed met Java overweg kunt, moet je naar mijn idee dus best met Java kunnen werken, ook al geeft de docent de voorkeur aan C++, tenzij je natuurlijk allerlei practicumopdrachten in C++ moet gaan doen.

[FireAge]

Verwijderd schreef op zaterdag 19 september 2009 @ 22:41:
hebben compiled languages zoals fortran en c(++) nog veel snelheidsvoordeel? Ik begreep dat java steeds sneller en dat JIT compilatie ook een positieve bijdrage levert aan de snelheid. Dat zou ook wel een punt ter overweging kunnen zijn.

Ik kan je in ieder geval vertellen dat in de Computational Physics nog vaak met Fortran gewerkt wordt. Zelfs C++ wordt daar te traag gevonden om van Java nog niet te spreken.

Maar... of dit reëel is weet ik niet. Ik ken ook mensen die hun monte carlo simulaties in Labview, Mathcad of Mathlab doen. Zelf vind ik C++ een fijne taal, maar dat is iets persoonlijks.

[Verwijderd]

Soultaker schreef op zaterdag 19 september 2009 @ 23:21:
Dit soort vragen zijn altijd lastig om objectief te beantwoorden, omdat het antwoord altijd in grote mate afhangt van wat je zelf van plan bent. Aan de ene kant is het nooit helemaal zinloos om een nieuwe taal te leren om daarmee je horizon te verbreden (en zelf een betere inschatting te kunnen maken welke taal het meest geschikt is om een probleem op te lossen). Aan de andere kant lijken de toepassingen die je voor ogen hebt me niet concreet aanleiding geven om van Java naar een andere taal te switchen.

De performance van Java is over het algemeen prima. Java programma's worden ook gewoon gecompileerd (het is me uit je post niet helemaal duidelijk of je je dat realiseerde) dus meestal zit je met een goedgeschreven Java-programma op z'n minst in dezelfde orde van grootte als een C++ of Fortran programma, zeker op moderne systemen.

Wat betreft OpenGL: de primaire API is gebaseerd op C. De bindings in Java en C++ zijn daardoor ook ongeveer hetzelfde. Als je goed met Java overweg kunt, moet je naar mijn idee dus best met Java kunnen werken, ook al geeft de docent de voorkeur aan C++, tenzij je natuurlijk allerlei practicumopdrachten in C++ moet gaan doen.

Op een dergelijk antwoord hoopte ik Ik ben me ervan bewust dat java ook gecompileerd wordt, maar dan alleen tot bytecode en niet tot 'machinetaal'. De bytecode moet nog steeds geinterpreteerd worden wat misschien een snelheidsverlies as gevolg heeft? Hoewel het verschil in snelheid geen killer zal zijn waarschijnlijk.

Ik hoor wel eens dat C++ aan populariteit verliest ten opzichte van java. Als dat zo is dan lijkt me dat er een reden voor is en dat Java misschien praktischer is? Misschien is het handiger om gewoon bij Java te blijven dan.

[DEiE]

Het hangt er ook vanaf wat je precies wil gaan bereiken met dit blok. Als je, zoals je aangeeft, je je voornamelijk met het modelleren bezig gaat houden is het kiezen van de taal meer een bijzaak (helemaal omdat ze beide met opengl overweg kunnen?).
Als je echter een goeie engine wilt gaan leren bouwen, en hier later mee verder wil gaan is het waarschijnlijk de overstap wel waard, omdat een groot deel van alle grote games in c++ worden gebouwd.

edit:

Ik hoor wel eens dat C++ aan populariteit verliest ten opzichte van java. Als dat zo is dan lijkt me dat er een reden voor is en dat Java misschien praktischer is? Misschien is het handiger om gewoon bij Java te blijven dan.

Java is wat makkelijker, omdat het wat meer uit handen neemt dan c++. Ook zitten er veel library's standaard bij java die je niet bij c++ hebt.

[ Voor 30% gewijzigd door DEiE op 19-09-2009 23:30 ]

[Verwijderd]

FireAge schreef op zaterdag 19 september 2009 @ 23:28:
[...]

Ik kan je in ieder geval vertellen dat in de Computational Physics nog vaak met Fortran gewerkt wordt. Zelfs C++ wordt daar te traag gevonden om van Java nog niet te spreken.

Maar... of dit reëel is weet ik niet. Ik ken ook mensen die hun monte carlo simulaties in Labview, Mathcad of Mathlab doen. Zelf vind ik C++ een fijne taal, maar dat is iets persoonlijks.

ik heb zelf voor m'n bachelorscriptie ook een model in fortran geschreven. Ik heb begrepen dat voor wetenschappenlijke toepassingen fortran nog steeds net het snelst is. Alleen kan je verder zo weinig met fortran...

In hoeverre is C++ puur object georienteerd trouwens? Bij Java kan je alleen met objecten werken, je leert zo wel een goede programmeerhouding aan lijkt me.

[user109731]

Verwijderd schreef op zaterdag 19 september 2009 @ 23:28:
[...]
Op een dergelijk antwoord hoopte ik Ik ben me ervan bewust dat java ook gecompileerd wordt, maar dan alleen tot bytecode en niet tot 'machinetaal'. De bytecode moet nog steeds geinterpreteerd worden wat misschien een snelheidsverlies as gevolg heeft? Hoewel het verschil in snelheid geen killer zal zijn waarschijnlijk.

Nee, de JVM heeft een JIT-compiler die at runtime je bytecode compileert naar assembly. En dat doen moderne JVMs heel goed

Bovendien, we hebben het hier over een school opdracht/vak... Geen real-world game ofzo waar het wél zin heeft om low-level in asm/C/C++ te werken.

Ik hoor wel eens dat C++ aan populariteit verliest ten opzichte van java. Als dat zo is dan lijkt me dat er een reden voor is en dat Java misschien praktischer is? Misschien is het handiger om gewoon bij Java te blijven dan.

C++ zou ik je niet aanraden. Het is complexer dan Java (memory management, pointers, header files, etc.), en als je de taal toch niet helemaal goed kent kan debuggen denk ik erg frustrerend worden. Het vak computer graphics opzich kan al moeilijk genoeg worden

Verwijderd schreef op zaterdag 19 september 2009 @ 23:31:
In hoeverre is C++ puur object georienteerd trouwens? Bij Java kan je alleen met objecten werken, je leert zo wel een goede programmeerhouding aan lijkt me.

In C++ wordt je idd veel minder gedwongen OO te programmeren dan in Java. Je kunt sowieso als beginner makkelijker 'slechte' code schrijven dankzij pointers e.d.

[ Voor 25% gewijzigd door user109731 op 19-09-2009 23:45 ]

[Nick The Heazk]

Indien je in de sfeer van het wetenschappelijk rekenen terecht komt, zul je sowieso geconfronteerd worden met talen als Fortran en C++. In dat wereldje wordt Java eigenlijk nauwelijks gebruikt. Dat heeft meerdere oorzaken, waarvan een groot aantal historisch.

Zo zijn er voor Java heel wat minder bibliotheken voor wetenschappelijke berekeningen. In fortran heb je bijvoorbeeld standaardbibliotheken als BLAS, LaPACK, ScaLaPACK en vele anderen. Om dergelijke bibliotheken van hoge kwaliteit te ontwikkelen in een andere taal heeft men vooral veel tijd nodig. Blijkbaar zag men er geen markt in en bijgevolg zijn er geen zulke bibliotheken voor Java. Het is uitgesloten om hier zelf "even" een implementatie voor te schrijven.

Het originele (geen idee of dat nu nog zo is) vlottende-komma model van Java is niet erg goed gekozen.

De prestaties spelen ook een rol. De JVM heeft een vrij zware memory footprint. Je kunt niet zelf het geheugen beheren zoals in C++. Je zit opgescheept met een garbage collector die te pas en te onpas je programma verstoort. Java als taal is gewoon niet ontworpen om snel te zijn. Als je even kijkt naar de ontwerpbeslissingen die men voor Fortran heeft genomen, dan weet je wel waarom.

[Verwijderd]

Nick The Heazk schreef op zaterdag 19 september 2009 @ 23:33:
Indien je in de sfeer van het wetenschappelijk rekenen terecht komt, zul je sowieso geconfronteerd worden met talen als Fortran en C++. In dat wereldje wordt Java eigenlijk nauwelijks gebruikt. Dat heeft meerdere oorzaken, waarvan een groot aantal historisch.

Zo zijn er voor Java heel wat minder bibliotheken voor wetenschappelijke berekeningen. In fortran heb je bijvoorbeeld standaardbibliotheken als BLAS, LaPACK, ScaLaPACK en vele anderen. Om dergelijke bibliotheken van hoge kwaliteit te ontwikkelen in een andere taal heeft men vooral veel tijd nodig. Blijkbaar zag men er geen markt in en bijgevolg zijn er geen zulke bibliotheken voor Java. Het is uitgesloten om hier zelf "even" een implementatie voor te schrijven.

Het originele (geen idee of dat nu nog zo is) vlottende-komma model van Java is niet erg goed gekozen.

De prestaties spelen ook een rol. De JVM heeft een vrij zware memory footprint. Je kunt niet zelf het geheugen beheren zoals in C++. Je zit opgescheept met een garbage collector die te pas en te onpas je programma verstoort. Java als taal is gewoon niet ontworpen om snel te zijn. Als je even kijkt naar de ontwerpbeslissingen die men voor Fortran heeft genomen, dan weet je wel waarom.

Bedankt voor je uitgebreide antwoord,

Voor mn bachelorscriptie heb ik zelf ook gebruik gemaakt van LAPACK in fortran, uiterst handig. Het ontbreken van dergelijke libraries zou wel een groot nadeel zijn ja. Heeft C++ wel dergelijke libraries?

De overhead van de JVM speelt natuurlijk ook mee zoals je zegt. Misschien zorgt het feit dat je aan geheugenmanagement moet doen in C++ er ook wel voor dat je beter begrijpt hoe dingen in elkaar steken. Je laat niet bepaalde taken aan de JVM over terwijl je zelf niet weet hoe het werkt. Is C++ qua snelheid enigszins vergelijkbaar met fortran?

Bram

[Soultaker]

De wetenschappelijke libraries waar jij en Nick het over hebben, zijn meestal C libraries. Vanuit C++ kun je die vrijwel zonder uitzondering probleemloos gebruiken, maar het zijn niet altijd object-geörienteerde libraries.

In hoeverre is C++ puur object georienteerd trouwens? Bij Java kan je alleen met objecten werken, je leert zo wel een goede programmeerhouding aan lijkt me.

C++ is helemaal niet strict waar het paradigma's betreft. Je kunt nauw verhulde Fortan of C code schrijven in C++ als je wil. Je kunt ook netjes een OO methodologie volgen als dat je voorkeur heeft.

Overigens is het "alleen met objecten werken" juist in Java soms een bron van inefficiëntie. Vergelijk de performance van een java.util.Vector<Integer> eens met C++'s std::vector<int> en dan zul je zien dat Vector wel heel netjes is, maar voor álle operaties moet synchroniseren (slecht voor de performance) en voor elk 32-bits getal 16 bytes (of nog meer op een 64-bits systeem) nodig heeft in plaats van 4. Vandaar dat je zult zien dat op performance gerichte libraries in Java (zoals ook de OpenGL API, trouwens) met arrays van primitieve types (int, float) werken in plaats van container classes.

Nick The Heazk heeft een goed punt: wellicht kun je je beslissing ook baseren op wat er veel gebruikt wordt in je vakgebied. Ik ben van mening dat een taal als Fortran echt geen toekomst heeft, maar je geacht wordt er (zeg) nog twintig jaar mee te werken, dan kun je het misschien maar beter leren, ook al voldoet Java vanuit technisch oogpunt ook wel.

[Verwijderd]

Soultaker schreef op zaterdag 19 september 2009 @ 23:55:
De wetenschappelijke libraries waar jij en Nick het over hebben, zijn meestal C libraries. Vanuit C++ kun je die vrijwel zonder uitzondering probleemloos gebruiken, maar het zijn niet altijd object-geörienteerde libraries.


[...]

C++ is helemaal niet strict waar het paradigma's betreft. Je kunt nauw verhulde Fortan of C code schrijven in C++ als je wil. Je kunt ook netjes een OO methodologie volgen als dat je voorkeur heeft.

Overigens is het "alleen met objecten werken" juist in Java soms een bron van inefficiëntie. Vergelijk de performance van een java.util.Vector<Integer> eens met C++'s std::vector<int> en dan zul je zien dat Vector wel heel netjes is, maar voor álle operaties moet synchroniseren (slecht voor de performance) en voor elk 32-bits getal 16 bytes (of nog meer op een 64-bits systeem) nodig heeft in plaats van 4. Vandaar dat je zult zien dat op performance gerichte libraries in Java (zoals ook de OpenGL API, trouwens) met arrays van primitieve types (int, float) werken in plaats van container classes.

Nick The Heazk heeft een goed punt: wellicht kun je je beslissing ook baseren op wat er veel gebruikt wordt in je vakgebied. Ik ben van mening dat een taal als Fortran echt geen toekomst heeft, maar je geacht wordt er (zeg) nog twintig jaar mee te werken, dan kun je het misschien maar beter leren, ook al voldoet Java vanuit technisch oogpunt ook wel.

Denk je dat C++ een wat betere toekomst heeft vergeleken met fortran? Je zei dat de libraries ook voor C geschreven zijn, dus wat dat betreft zou C/C++ voor mij ook prima voldoen. Ik heb het idee dat C wat meer algemene mogelijkheden biedt dan fortran. In C zou je eventueel dingen grafisch weer kunnen geven als je dat handig lijkt op een bepaald punt.

[SH4D3H]

Verwijderd schreef op zondag 20 september 2009 @ 00:04:
[...]Denk je dat C++ een wat betere toekomst heeft vergeleken met fortran?

Er komt 'binnenkort' zelfs een nieuwe versie van C++.

Toch zou ik eerst eens kijken wat nou mag.
Wie weet mag en kun je prima met Java blijven werken, dan kun je je tenminste 100% richten op de stof in plaats van ook nog 'ns bekend worden met een nieuwe taal.

[Leftblank]

Verwijderd schreef op zondag 20 september 2009 @ 00:04:
[...]
Denk je dat C++ een wat betere toekomst heeft vergeleken met fortran?

Je zou zelfs kunnen stellen dat C++ een toekomst heeft itt Fortran, zover ik weet is Fortran met name in academia en op grote mainframes in gebruik, daarbuiten zul je het praktisch nooit aantreffen, ik zou dus zeker voor C++ kiezen indien je Fortran als enige andere optie beschouwd.

[Soultaker]

Verwijderd schreef op zondag 20 september 2009 @ 00:04:
Denk je dat C++ een wat betere toekomst heeft vergeleken met fortran?

Het blijft een beetje koffiedik kijken, natuurlijk, maar ik denk dat zowel C en C++ voorlopig van belang blijven, in ieder geval in sterkere mate dan Fortran. Als we bij het voorbeeld van reken-intensieve applicaties blijven, dan zie je dat bijvoorbeeld libraries als CUDA primair voor C/C++ ontwikkeld worden en er ook interesse is in language bindings voor Java en C#, maar dat Fortran helemaal niet in beeld is.

Ik vraag me sterk af of er überhaupt nog veel nieuwe libraries voor Fortran ontwikkeld worden. (OpenMP is een voorbeeld, maar is niet exclusief voor Fortran.) Dat er weinig nieuws ontwikkeld wordt betekent niet dat Fortran snel zal verdwijnen; een taal als COBOL is ook al twintig jaar volledig uit de tijd maar toch ook nog in gebruik.

[ Voor 10% gewijzigd door Soultaker op 20-09-2009 00:20 ]

[Verwijderd]

bedankt voor al jullie input! Ik ben nu wel van plan om c++ te leren als ik wat tijd heb. Interessant dat er bijna een 'nieuwe versie' uitkomt. Ik zie alleen dat de gcc compiler nog lang niet alle functies ondersteunt. Het zou handig zijn geweest om meteen de nieuwe standaard te leren als je toch met een nieuwe taal begint, toch nog even geduld hebben

goedenacht allemaal!

edit: heeft iemand trouwens goede ervaringen met een bepaalde c++ tutorial? Sun had voor java een enorm uitgebreide tutorial online staan waarin alle opties verwerkt zaten.

[ Voor 18% gewijzigd door Verwijderd op 20-09-2009 00:49 ]

[Soultaker]

Verwijderd schreef op zondag 20 september 2009 @ 00:39:
Interessant dat er bijna een 'nieuwe versie' uitkomt. Ik zie alleen dat de gcc compiler nog lang niet alle functies ondersteunt.

Och, GCC komt een heel eind; sowieso hoef je daar niet echt op te wachten, want hoewel de veranderingen aanzienlijk zijn, gaat de taal in de kern niet zoveel veranderen. Je loopt dus geen risico dat je jezelf een verouderde taal aanleert.

heeft iemand trouwens goede ervaringen met een bepaalde c++ tutorial? Sun had voor java een enorm uitgebreide tutorial online staan waarin alle opties verwerkt zaten.

Thinking in C++ wordt meestal genoemd als een goede, gratis tutorial. Volume 1 bevat een behoorlijk uitgebreide introductie in de taal, hoewel de eerste paar hoofdstukken voor jou waarschijnlijk niet veel nieuws bevatten. Er zijn echter wel een aantal belangrijke verschillen tussen C++ en Java waardoor ik je ook weer niet zou aanraden om hele stukken over te slaan (denk aan dingen als initialisatie van variabelen, en wanneer die nu wel en niet automatisch plaatsvindt).

[FireAge]

Verwijderd schreef op zondag 20 september 2009 @ 00:39:
bedankt voor al jullie input! Ik ben nu wel van plan om c++ te leren als ik wat tijd heb. Interessant dat er bijna een 'nieuwe versie' uitkomt. Ik zie alleen dat de gcc compiler nog lang niet alle functies ondersteunt. Het zou handig zijn geweest om meteen de nieuwe standaard te leren als je toch met een nieuwe taal begint, toch nog even geduld hebben

goedenacht allemaal!

edit: heeft iemand trouwens goede ervaringen met een bepaalde c++ tutorial? Sun had voor java een enorm uitgebreide tutorial online staan waarin alle opties verwerkt zaten.

Imo erg goede start voor C++:
http://www.icce.rug.nl/documents/cplusplus/

Heb zelf les gehad van Frank Brokken en dat was een goede cursus. Ik weet niet of de annotaties te lastig zijn zonder cursus.

Oh, en goeie keus om over te stappen, ik denk dat je er veel plezier van zal hebben.

[coubertin119]

Het is overigens mogelijk om LAPACK te interfacen zodat je in C++ functies hiervan kan oproepen. Erg handig is het niet (multidimensionale arrays hebben een andere layout, je moet alles by-pointer meegeven), maar het werkt dus . Daarnaast heb je dingen als de Intel Math Kernel Library, waar je ook gebruik van kan maken als het snel moet zijn

Zijn uitspraken als "Fortran is nog steeds het snelst" wel gebaseerd op hedendaagse vergelijkingen eigenlijk? Want tijdens mijn werk om 1 bepaalde LAPACK-routine te optimaliseren bleek dat die specifieke datalay-out gewoon slecht was vanuit cacheoogpunt, bijgevolg, een mooie winst tegenover dat ultieme Fortran . En wat Soultaker aangeeft met CUDA is ook belangrijk om in overweging te nemen.


Op de universiteit hier ken ik niemand die actief Fortran gebruikt, terwijl we heelder onderzoeksgroepen gewijd aan numerieke methoden, alles wordt in C++ of Matlab gedaan.

[Verwijderd]

fijn om te zien dat er wat bevestigende antwoorden komen. Ook bedankt voor de links naar de tutorials!

[Nick The Heazk]

Verwijderd schreef op zaterdag 19 september 2009 @ 23:40:
Voor mn bachelorscriptie heb ik zelf ook gebruik gemaakt van LAPACK in fortran, uiterst handig. Het ontbreken van dergelijke libraries zou wel een groot nadeel zijn ja. Heeft C++ wel dergelijke libraries?

Je kunt vanuit C++ interfacen met ondermeer BLAS en LAPACK. Een erg goede bibliotheek is, zoals reeds vermeld, de Intel Math Kernel Library. Deze allesomvattende bibliotheek bevat naast een erg goede documentatie een implementatie van ondermeer BLAS, LAPACK en ScaLAPACK. Er zijn eveneens Fortran95 interfaces voor BLAS en LAPACK, hetgeen je ongeveer 50% van de argumentenlijst uitspaart, met als nadeel dat het iets minder performant is. Hét startpunt bij uitstek indien je wetenschappelijke programma's moet ontwikkelen.

Is C++ qua snelheid enigszins vergelijkbaar met fortran?

Als je naar de ontwerpbeslissingen kijkt die men heeft genomen in Fortran, dan is deze taal echt ontworpen om efficient te zijn. Overerving bestaat niet, arrays kunnen enkel via referentie doorgegeven worden, er zijn by default geen recursieve oproepen mogelijk en tot de Fortran90 standaard was er geen dynamisch geheugen, om maar enkele voorbeelden te geven.

C++ is ook ontworpen met efficiëntie in het achterhoofd, maar C++ is nu eenmaal een general-purpose taal. Ik denk dat C++ pas populair is geworden in de wetenschappelijke gemeenschap toen de zogenaamde expression templates ontdekt werden. Deze techniek kan inderdaad voor een drastische verbetering in de prestaties zorgen bij berekeningen (typisch bij matrix-intensieve bewerkingen). Het nadeel is dan weer dat de implementatie heel wat complexer wordt. Ik denk echter dat de meeste wetenschappelijke programma's wel gebruik maken van een of andere vorm van template programming. Indien je in dit wereldje terecht komt is het dan ook van belang dat je deze techniek goed onder de knie krijgt. Voor je vak computer graphics zul je dat niet nodig hebben.

Leftblank schreef op zondag 20 september 2009 @ 00:18:
Je zou zelfs kunnen stellen dat C++ een toekomst heeft itt Fortran, zover ik weet is Fortran met name in academia en op grote mainframes in gebruik, daarbuiten zul je het praktisch nooit aantreffen, ik zou dus zeker voor C++ kiezen indien je Fortran als enige andere optie beschouwd.

Ik kan je uit ervaring zeggen dat dat niet klopt. Fortran wordt voornamelijk nog voor wetenschappelijke programma's gebruikt. Binnen vele bedrijven die binnen deze branche actief zijn zul je nog Fortran code aantreffen. In het bedrijf waar ik laatst was, is de core software in Fortran geschreven. Deze core component wordt maar in beperkte mate bijgewerkt. Voor hun nieuwere software gebruiken ze overwegend C++ (waarbij men sterk leunt op de template programming technieken). Het is voor het bedrijf gewoon economisch onmogelijk om hun oude Fortran code even om te zetten in een andere programmeertaal. Zo lang er bedrijven zijn wiens belangrijkste software origineel in Fortran werd geschreven (en dat zal zo zijn voor elk bedrijf in deze branche dat voor 1990 al software schreef), zal er Fortran zijn .

Soultaker schreef op zondag 20 september 2009 @ 00:19:
Het blijft een beetje koffiedik kijken, natuurlijk, maar ik denk dat zowel C en C++ voorlopig van belang blijven, in ieder geval in sterkere mate dan Fortran. Als we bij het voorbeeld van reken-intensieve applicaties blijven, dan zie je dat bijvoorbeeld libraries als CUDA primair voor C/C++ ontwikkeld worden en er ook interesse is in language bindings voor Java en C#, maar dat Fortran helemaal niet in beeld is.

Ik vraag me sterk af of er überhaupt nog veel nieuwe libraries voor Fortran ontwikkeld worden. (OpenMP is een voorbeeld, maar is niet exclusief voor Fortran.) Dat er weinig nieuws ontwikkeld wordt betekent niet dat Fortran snel zal verdwijnen; een taal als COBOL is ook al twintig jaar volledig uit de tijd maar toch ook nog in gebruik.

Ik denk ook dat C/C++ meer aan populariteit aan het winnen zijn in de wereld van het wetenschappelijk rekenen. Men krijgt stilaan de indruk dat de C++ compilers op het niveau komen van de Fortran compilers en dus dat de snelheid vergelijkbaar wordt. Dat neemt inderdaad niet weg dat er nog een hele hoop software in Fortran is geschreven. Ik zou het verbazend vinden moest je later nooit een regel Fortran tegenkomen in de bedrijven waar je zult werken.

Mijn inziens is het in deze tijd een goede keuze (voor wetenschappelijk rekenen) om een goede kennis van C++ uit te bouwen, met inbegrip van template programming en expression templates. Een passieve kennis van Fortran is, mijn inziens, een sterk pluspunt; je zult er hoe dan ook mee geconfronteerd worden.

[MSalters]

FORTRAN is in principe een paar jaar geleden ingehaald door C++, dankzij de Blitz++ library. Alleen is inderdaad er uit de tijd daarvoor nog een heleboel legacy FORTRAN, en die is best snel. Uiteindelijk meet je de snelheid van een taal aan de mate waarin je ideale assembly benadert. Moderne FORTRAN en C++ compilers halen op goede numerieke code beiden efficiencies boven de 95%. Als gevolg daarvan zullen de onderlinge verschillen niet boven de 5% liggen.

[NC83]

Ik raad je aan voorzicht te zijn met die Intel Library want die zal hoogst waarschijnlijk enkel geoptimaliseerd zijn voor intel CPU's.

[ACM]

Nick The Heazk schreef op zaterdag 19 september 2009 @ 23:33:
Het originele (geen idee of dat nu nog zo is) vlottende-komma model van Java is niet erg goed gekozen.

Wat een dramatisch slecht geschreven artikel. Het lukte me gewoon niet om verder dan de eerste pagina's te komen met lezen (en daarin kon ik me al niet op de tekst concentreren) en te begrijpen wat nou eigenlijk de problemen met Java's floating point zijn. Vooral niet in hoeverre het slechter is dan die van C++ of Fortran.
Dus als je het zou willen samen vatten zou ik je dankbaar zijn?
En laat dan bij voorkeur statements als deze maar gewoon weg:

Java’s floating-point suffers from serious oversights. The same could be said of several other
programming languages, some of them venerable, but Java lacks their historical excuses.

Want Java is uiteraard mede ontworpen met de gedachte om C en C++-programmeurs snel over te laten stappen, dus het had daardoor automatisch een historische bagage.

De prestaties spelen ook een rol. De JVM heeft een vrij zware memory footprint. Je kunt niet zelf het geheugen beheren zoals in C++. Je zit opgescheept met een garbage collector die te pas en te onpas je programma verstoort. Java als taal is gewoon niet ontworpen om snel te zijn. Als je even kijkt naar de ontwerpbeslissingen die men voor Fortran heeft genomen, dan weet je wel waarom.

Het grootste probleem met Java's memory managent vind ik zelf dat je er niet standaard bij stil zal staan dat je vooraf de maximale hoeveelheid geheugen die de applicatie kan gebruiken kan moeten specificeren. Dat je er geen grip welke op hebt vind ik niet per se een probleem, dat is hooguit in heel specifieke gevallen echt onwerkbaar.
Je portreteert Java hier nu als een slome taal, waar dat in de praktijk al lang bewezen is niet het geval te zijn. Er zijn inderdaad nog steeds situaties waar C++ of Fortran sneller zijn, maar zoals Soultaker in zijn eerste post al aangaf zit het doorgaans echt niet meer buiten dezelfde orde van grootte.
Java's memory allocations in de Sun JVM zijn bijvoorbeeld juist sneller dan normale mallocs omdat er bijna niks voor gedaan hoeft te worden, dat het zo goedkoop is zie je dan eventueel wel terug met wat garbage collection overhead, maar daar kan je ook behoorlijk wat in sturen waardoor e.e.a. desnoods vrijwel volledig in parallele threads gebeurd.

[Nick The Heazk]

ACM schreef op maandag 21 september 2009 @ 08:15:
Wat een dramatisch slecht geschreven artikel. Het lukte me gewoon niet om verder dan de eerste pagina's te komen met lezen (en daarin kon ik me al niet op de tekst concentreren) en te begrijpen wat nou eigenlijk de problemen met Java's floating point zijn. Vooral niet in hoeverre het slechter is dan die van C++ of Fortran.
Dus als je het zou willen samen vatten zou ik je dankbaar zijn?

Dat "artikel" is inderdaad niet zo goed geschreven. Dit artikel geeft een betere uitleg. Het komt er op neer dat Java (ooit?) niet de maximale snelheid benut(te?). Blijkbaar doet (deed?) Java steeds een store-load wanneer een floating-point waarde berekend werd en daarna opnieuw gebruikt moet worden. Ik hoop dat het duidelijk is dat voor numerieke berekeningen dit extra en onnodig geheugenverkeer gewoon niet acceptabel is. In het artikel wordt gewag gemaakt van een vertraging van een factor 2 à 4 voor floating-point bewerkingen. Indien je programma enkel bestaat uit dit soort bewerkingen (zowat alle eindige elementen solvers) dan heb je dus een probleem.

Het grootste probleem met Java's memory managent vind ik zelf dat je er niet standaard bij stil zal staan dat je vooraf de maximale hoeveelheid geheugen die de applicatie kan gebruiken kan moeten specificeren. Dat je er geen grip welke op hebt vind ik niet per se een probleem, dat is hooguit in heel specifieke gevallen echt onwerkbaar.

Dat zal waarschijnlijk door de ganse gemeenschap van het wetenschappelijk rekenen veracht worden. Een garbage collector die in het midden van een hoog geoptimaliseerd matrix-vector product even besluit om wat geheugen op te ruimen is gewoon hopeloos inefficiënt. Je berekening wordt opgeschort, het hele cache wordt vervuild en daarna kan je de berekening terug opstarten waarbij je weer een ganse reeks cachemissers genereert. Neen, bij wetenschappelijk rekenen wil je minstens controle over de garbage collector. Die mag na een iteratieve methode misschien eens het geheugen opschonen, maar niet tijdens een berekening.

Je portreteert Java hier nu als een slome taal, waar dat in de praktijk al lang bewezen is niet het geval te zijn.

Ik portreteer Java als een taal die niet ontworpen is voor wetenschappelijk rekenen. Java heeft standaard bounds-checking op arrays, gebruikt standaard dynamische binding voor publieke methodes, heeft overerving nodig om een uniforme interface aan te bieden, gebruikt dynamisch geheugen, draait op een geheugenverslindende JVM, gebruikt als enige geheugenbeheermechanisme een garbage collector, heeft geen ingebouwd complex type, heeft geen matrix noch vector type, heeft geen operator-overloading, ken(t|de) prestatieproblemen met floating-point bewerkingen, wordt standaard on-the fly gecompileerd en heeft in zijn 15 jarig bestaan nog steeds geen officiële API voor MPI en OpenMP gekregen. Dus ja, voor wetenschappelijk rekenen, waar floating-point bewerkingen en het geheugentoegangspatroon het belangrijkste is, is Java waarschijnlijk een te slome taal.

De ontwerpbeslissingen in Fortran, de standaardtaal voor wetenschappelijke berekeningen, zijn overigens net het tegengestelde van hetgeen ik opsomde: geen bounds-checking, geen overerving voor uniforme interface, had tot Fortran90 geen dynamisch geheugen, geen JVM, geen garbage collector, wel een complex, vector en matrix type, wel operator-overloading, geen prestatieproblemen met floating-point bewerkingen, geen on-the-fly compilatie, een standaard API voor OpenMP en MPI, een uitgebreide verzameling numerieke bibliotheken (BLAS, LAPACK, SCALAPACK) en compilers die specifiek en doorgedreven geoptimaliseerd zijn voor numerieke software (ontrollen van lussen, vectorizeren van lussen, omwisselen van geneste lussen, etc).

[ Voor 10% gewijzigd door Nick The Heazk op 21-09-2009 11:42 ]

[NC83]

ACM schreef op maandag 21 september 2009 @ 08:15:
[...]

Het grootste probleem met Java's memory managent vind ik zelf dat je er niet standaard bij stil zal staan dat je vooraf de maximale hoeveelheid geheugen die de applicatie kan gebruiken kan moeten specificeren. Dat je er geen grip welke op hebt vind ik niet per se een probleem, dat is hooguit in heel specifieke gevallen echt onwerkbaar.
Je portreteert Java hier nu als een slome taal, waar dat in de praktijk al lang bewezen is niet het geval te zijn. Er zijn inderdaad nog steeds situaties waar C++ of Fortran sneller zijn, maar zoals Soultaker in zijn eerste post al aangaf zit het doorgaans echt niet meer buiten dezelfde orde van grootte.
Java's memory allocations in de Sun JVM zijn bijvoorbeeld juist sneller dan normale mallocs omdat er bijna niks voor gedaan hoeft te worden, dat het zo goedkoop is zie je dan eventueel wel terug met wat garbage collection overhead, maar daar kan je ook behoorlijk wat in sturen waardoor e.e.a. desnoods vrijwel volledig in parallele threads gebeurd.

Juist om die reden alloceer je een grote hoeveelheid/ zoveel als je nodig hebt aan geheugen in het begin van je applicatie in C/C++. Overload placement operator new en nieuwe geheugen wordt niet meer als het trg geven van een pointer, vele malen sneller en waarschijnlijk ook sneller als JVM.

[farlane]

ACM schreef op maandag 21 september 2009 @ 08:15:
Je portreteert Java hier nu als een slome taal, waar dat in de praktijk al lang bewezen is niet het geval te zijn. Er zijn inderdaad nog steeds situaties waar C++ of Fortran sneller zijn, maar zoals Soultaker in zijn eerste post al aangaf zit het doorgaans echt niet meer buiten dezelfde orde van grootte.

Ok, ill bite Heb je links naar benchmarks/bewijs?

Java's memory allocations in de Sun JVM zijn bijvoorbeeld juist sneller dan normale mallocs omdat er bijna niks voor gedaan hoeft te worden.

In C++ heb je de mogelijkheid om je eigen new/delete te maken die meer lijkt op de allocator van Java. Indien goed geimplementeerd is er geen reden waarom deze langzamer zou moeten zijn dan de Java allocator.

[edit]
Wat NC83 zegt dus eigenlijk

[Soultaker]

ACM schreef op maandag 21 september 2009 @ 08:15:
Wat een dramatisch slecht geschreven artikel.

Ik had er ook moeite mee, maar ik haal er twee punten uit. Ten eerste dat het meestal zinnig is om met meer precisie te rekenen dan waarmee je invoerparameters aangeleverd worden (dus een functie die 32-bits floats als argumenten gebruikt zou met 64-bits doubles of 80-bits long doubles moeten rekenen).

Zoals de auteur al aanstipt is het resultaat van berekening met (zeg) floats in zowel Fortran, C als Java ook een float, terwijl de auteur dus vindt dat het resultaat beter een zo nauwkeurig mogelijk type had moeten zijn (zeg, 80 bits long double). Het enige verschil tussen Java enerzijds en C/Fortran anderzijds is dat de oorspronkelijk Java-standaard eist dat tussenresultaten in expressies geconverteerd worden naar het type van hun eind resultaat, waardoor extra precisie in principe verloren gaat.

Die eis was gesteld om te garanderen dat (in ieder geval single-threaded) Java-programma's op alle platforms dezelfde resultaten opleveren (ongeacht de precisie van de gebruikte FPU). Maar goed, al sinds Java 1.2 is deze eis afgeschaft waarbij de oude semantics met het strictfp keyword verkregen kunnen worden.

Nick The Heazk schreef op maandag 21 september 2009 @ 10:24:
Blijkbaar doet (deed?) Java steeds een store-load wanneer een floating-point waarde berekend werd en daarna opnieuw gebruikt moet worden. Ik hoop dat het duidelijk is dat voor numerieke berekeningen dit extra en onnodig geheugenverkeer gewoon niet acceptabel is.

Voor zover ik het begrijp gaat het de auteur helemaal niet om performance (hij bekritiseert immers de keuze om floats omwille van de efficiëntie niet automatisch tot double te promoveren) maar alleen om het verlies van extra precisie. Een valide kritiek op Java 1.0 en 1.1, maar volledig uit de tijd. (Sowieso was Java vóór de JIT compiler in 1.4 toch al dermate traag dat de floating-point performance niet zo relevant was.)

Het tweede punt dat hij maakt heeft te maken met de representatie van floating-point getallen. Voor bepaalde algoritmen is het van belang dat er onderscheid gemaakt kan worden tussen positieve en negatieve nul (waartussen wiskundig gezien natuurlijk geen onderscheid gemaakt) wat in Java (voor zover ik begrijp?) niet mogelijk is. Daardoor krijg je rare afwijkingen in randgevallen, bijvoorbeeld als je gaat rekenen met complexe getallen, waar de grafiekjes met missende lijnen een voorbeeld van zijn.

[PiepPiep]

Wat ook belangrijk kan zijn is om te kijken welke libraries je wilt gaan gebruiken.
Zo mag je wxWidgets voor closed source applicaties gebruiken maar moet je bij Qt er flink voor betalen tenzijn je het opensource gebruikt.

[user109731]

PiepPiep schreef op maandag 21 september 2009 @ 12:43:
Zo mag je wxWidgets voor closed source applicaties gebruiken maar moet je bij Qt er flink voor betalen tenzijn je het opensource gebruikt.

Dat is niet meer het geval. Qt is sinds v4.5 LGPL, dus ook gratis voor closed-source software

[ Voor 15% gewijzigd door user109731 op 21-09-2009 12:51 ]

[ACM]

farlane schreef op maandag 21 september 2009 @ 12:34:
Ok, ill bite Heb je links naar benchmarks/bewijs?

Ik voel eerlijk gezegd niet zo de behoefte om tegengesproken ongefundeerde uitspraken heel erg te onderbouwen Maar hier heb je iig wat benchmarks van diverse talen. En daarbij zie je C, C++ zoals wel te verwachten bovenaan, maar Java staat wel ruim voor Fortran.
Nou heb ik verder niet heel uitgebreid naar deze resultaten gekeken of ze zelf herhaald, dus wellicht dat je er gaten in kan schieten.

In C++ heb je de mogelijkheid om je eigen new/delete te maken die meer lijkt op de allocator van Java. Indien goed geimplementeerd is er geen reden waarom deze langzamer zou moeten zijn dan de Java allocator.

Vast wel, maar er werd gesuggereerd dat Java's geheugenmanagement zo slecht zou zijn, het is vooral wat slechter voorspelbaar.

Nick The Heazk schreef op maandag 21 september 2009 @ 10:24:
Het komt er op neer dat Java (ooit?) niet de maximale snelheid benut(te?). Blijkbaar doet (deed?) Java steeds een store-load wanneer een floating-point waarde berekend werd en daarna opnieuw gebruikt moet worden. Ik hoop dat het duidelijk is dat voor numerieke berekeningen dit extra en onnodig geheugenverkeer gewoon niet acceptabel is. In het artikel wordt gewag gemaakt van een vertraging van een factor 2 à 4 voor floating-point bewerkingen. Indien je programma enkel bestaat uit dit soort bewerkingen (zowat alle eindige elementen solvers) dan heb je dus een probleem.

Dus technisch wel correct, maar (toen iig) niet de meest efficiente implementatie. In dat geval lijkt het me idd niet de meest handige omgeving om mee te werken als dat je primaire taak is. Maar het zijn beide geen heel recente artikelen, dat de performance van Java (in algemene zin) in 1998 niet enorm goed was zal ook niet zo gauw ontkend worden hier

Dat zal waarschijnlijk door de ganse gemeenschap van het wetenschappelijk rekenen veracht worden. Een garbage collector die in het midden van een hoog geoptimaliseerd matrix-vector product even besluit om wat geheugen op te ruimen is gewoon hopeloos inefficiënt.

Ik denk dat je het wel wat overdrijft als je het 'hopeloos inefficient' noemt. Het is uiteraard wel veel minder voorspelbaar. Sowieso heb ik de indruk dat je een mate van onhandelbaarheid aan de GC toewijst die er in de praktijk misschien wel helemaal niet is of weg te tunen is.

Ik portreteer Java als een taal die niet ontworpen is voor wetenschappelijk rekenen.

Het is inderdaad ontworpen als generieke taal en de meer recente versies lijken vooral desktop- en serverwerk uitbreidingen te krijgen. Overigens zijn er wel wat projecten om numeriek te werken.

Java heeft standaard bounds-checking op arrays, gebruikt standaard dynamische binding voor publieke methodes, heeft overerving nodig om een uniforme interface aan te bieden, gebruikt dynamisch geheugen, draait op een geheugenverslindende JVM, gebruikt als enige geheugenbeheermechanisme een garbage collector, heeft geen ingebouwd complex type, heeft geen matrix noch vector type, heeft geen operator-overloading, ken(t|de) prestatieproblemen met floating-point bewerkingen, wordt standaard on-the fly gecompileerd en heeft in zijn 15 jarig bestaan nog steeds geen officiële API voor MPI en OpenMP gekregen. Dus ja, voor wetenschappelijk rekenen, waar floating-point bewerkingen en het geheugentoegangspatroon het belangrijkste is, is Java waarschijnlijk een te slome taal.

Je noemt allemaal beperkingen waarvan ik als numerieke-programmeur-leek niet zo goed van begrijp waarom ze problematisch zijn, op de missende bibliotheken na dan. Ik heb meer de indruk dat ze eigenlijk als voordeel van talen die het wel hebben gezien moet worden (zoals complex, matrix en vector types). Vziw hebben C en C++ ook geen numerieke typen?
Het on-the-fly compileren kunnen we heel lang over door blijven discussieren, maar als je applicatie langer dan een minuut of wat draait is dat doorgaans niet zo'n groot nadeel. En als je applicatie-executie niet zo goed statistisch voorspelbaar was kan het zelfs een voordeel zijn Bounds-checking wordt overigens zo veel mogelijk geprobeerd weg te optimaliseren, als de compiler kan bewijzen dat je loop niet buiten de range komt, dan zal ie het voor die loop dan ook weglaten.

[RayNbow]

Nick The Heazk schreef op maandag 21 september 2009 @ 10:24:
[...]

Ik portreteer Java als een taal die niet ontworpen is voor wetenschappelijk rekenen. Java heeft standaard bounds-checking op arrays,

Array bounds check elimination for the Java HotSpot™ client compiler

gebruikt standaard dynamische binding voor publieke methodes

Virtual method calls kan je inlinen (Evaluation and optimization of method calls in Java).

heeft overerving nodig om een uniforme interface aan te bieden

Ik snap niet welk punt je hier probeert te maken.

gebruikt dynamisch geheugen

Is vaak echter wel sneller dan de standaard malloc. Verder zou de JVM met escape analysis bepaalde objecten op de stack kunnen alloceren (Stack allocation and synchronization optimizations for Java using escape analysis).

draait op een geheugenverslindende JVM

Met wat tuning en pruning van features kun je gemakkelijk een JVM variant draaien op een microcontroller (Darjeeling, a Java Compatible Virtual Machine for Microcontrollers).

gebruikt als enige geheugenbeheermechanisme een garbage collector

Is echter voor veel gevallen een acceptabele keuze voor performance vs productivity Quantifying the Performance of Garbage Collection vs. Explicit Memory Management).

heeft geen ingebouwd complex type

Dat hebben meer talen niet.

heeft geen matrix noch vector type

Een matrix of een vector type kun je in Java introduceren door zelf een class te schrijven.

heeft geen operator-overloading

Dat is zeker een gemis in de taal Java zelf, zeker wanneer je veel werkt met eigen classes. Ik weet niet wat de beweegredenen waren van de ontwerpers, maar ik gok dat ze de ad-hoc manier van C++ te verwarrend vonden gezien de feature gemakkelijk te misbruiken is. Als je in een C++ of Python programma bijv. een expressie a+b ziet, dan weet je niet zeker of je hier met een ring te maken hebt.

(In tegenstelling tot Haskell, waarbij een naam bestaande uit speciale symbolen gewoon een geldige naam voor een functie is, namelijk een infixoperator. Echter, je kan niet zo maar bijv. (+) definieren voor je eigen type. De (+) zit in de Num type class en wil je die dus gebruiken, dan moet je je eigen type dus Num-like maken. Dat wil zeggen dat je dus ook o.a. (-) en (*) moet definieren. Het voordeel van deze opzet is, is dat wanneer je (+) ziet in je code, dat je dan weet dat je iig werkt met een type uit de Num class.)

ken(t|de) prestatieproblemen met floating-point bewerkingen

Zie: Soultaker in "Zou ik van Java moeten overschakelen naa..."

wordt standaard on-the fly gecompileerd

Zie: ACM in "Zou ik van Java moeten overschakelen naa..."

heeft in zijn 15 jarig bestaan nog steeds geen officiële API voor MPI en OpenMP gekregen.

Misschien een vraag/aanbod probleem? Als er te weinig interesse is, dan komt zo'n API niet zo maar uit de lucht vallen.

Dus ja, voor wetenschappelijk rekenen, waar floating-point bewerkingen en het geheugentoegangspatroon het belangrijkste is, is Java waarschijnlijk een te slome taal.

Dit is een conclusie getrokken op basis van wat precies? Niet al je aangedragen punten gaan namelijk over performance.

[.oisyn]

Nick The Heazk schreef op maandag 21 september 2009 @ 10:24:
[...]

Dat "artikel" is inderdaad niet zo goed geschreven. Dit artikel geeft een betere uitleg. Het komt er op neer dat Java (ooit?) niet de maximale snelheid benut(te?). Blijkbaar doet (deed?) Java steeds een store-load wanneer een floating-point waarde berekend werd en daarna opnieuw gebruikt moet worden. Ik hoop dat het duidelijk is dat voor numerieke berekeningen dit extra en onnodig geheugenverkeer gewoon niet acceptabel is. In het artikel wordt gewag gemaakt van een vertraging van een factor 2 à 4 voor floating-point bewerkingen. Indien je programma enkel bestaat uit dit soort bewerkingen (zowat alle eindige elementen solvers) dan heb je dus een probleem.

Hmm, ik was op de hoogte van wat issues met floating point, maar niet op het niveau waarop je het nu weergeeft. Ik vond het ook al erg raar dat ik (in 2001) de interne werking van triangle fillers in een in Java geschreven 3D engine (voor als applet op een website) volledig in fixed point moest doen, terwijl Carmack met Quake al had aangetoond dat je de conversie naar int beter pas op een zo laat mogelijk moment kon doen met de huidige stand van floating point zaken op moderne CPU's (lees: vanaf pentium). Ik heb er toen geen verdere aandacht aan besteed, maar dit verklaart een hoop

[Nick The Heazk]

ACM schreef op maandag 21 september 2009 @ 13:01:
Ik denk dat je het wel wat overdrijft als je het 'hopeloos inefficient' noemt. Het is uiteraard wel veel minder voorspelbaar. Sowieso heb ik de indruk dat je een mate van onhandelbaarheid aan de GC toewijst die er in de praktijk misschien wel helemaal niet is of weg te tunen is.

Uiteraard. Maar een GC moet je heus niet komen onderbreken tijdens een berekening die zo hard steunt op de inhoud van je cachegeheugen. Waarschijnlijk kun je de GC wel in- en uitschakelen tijdens de uitvoering van je programma. Dat doet echter geen afbreuk aan het feit dat een GC nu niet het meest cruciale onderdeel is van een wetenschappelijke berekening. Bij dat soort programma's is het geheugenbeheer over het algemeen vrij eenvoudig en beperkt tot het alloceren en dealloceren van een paar matrices of vectoren. Voor algemene software is een GC héél wat nuttiger.

Het is inderdaad ontworpen als generieke taal en de meer recente versies lijken vooral desktop- en serverwerk uitbreidingen te krijgen. Overigens zijn er wel wat projecten om numeriek te werken.

Zeker, maar dat maakt het niet plotseling de taal bij uitstek voor numerieke software .

Je noemt allemaal beperkingen waarvan ik als numerieke-programmeur-leek niet zo goed van begrijp waarom ze problematisch zijn, op de missende bibliotheken na dan. Ik heb meer de indruk dat ze eigenlijk als voordeel van talen die het wel hebben gezien moet worden (zoals complex, matrix en vector types). Vziw hebben C en C++ ook geen numerieke typen?

Zie hieronder. Een ingebouwde complex klasse is overigens een must voor wetenschappelijke berekeningen. Het ontbreken van zo'n type geeft louter aan dat de taal niet voor dat doel ontworpen werd.

RayNbow schreef op maandag 21 september 2009 @ 14:01:
Array bounds check elimination for the Java HotSpot™ client compiler

Leuk voor eenvoudige lussen, maar dat gaat niet werken voor datastructuren voor ijle matrices (dé bouwsteen bij iteratieve methoden voor het oplossen van ijle stelsels vergelijkingen, zoals bijvoorbeeld in eindige-elementen solvers). Dit komt omdat je een indirecte geheugentoegang nodig hebt: array[ other[i] ].

Virtual method calls kan je inlinen (Evaluation and optimization of method calls in Java).

Iets wat natuurlijk ook in compiler technologie zit, dewelke bijvoorbeeld ook aan intra-procedurale optimalisatie kunnen doen. Volgens de auteurs van dat artikel is dat bijvoorbeeld nog niet mogelijk met dynamische compilers.

Ik snap niet welk punt je hier probeert te maken.

Het punt is dat het mechanisme van dynamische binding gebruikt word. In C++ bijvoorbeeld heb je voor het aanbieden van een uniforme interface geen expliciete interface nodig, door gebruik te maken van templates. Bijvoorbeeld

C++:

template<typename T> T add(const T& a, const T& b) const { return a + b; }

zal in C++ compileren, zolang alle instanties de operator+ implementeren. Met generics in Java ben je verplicht om een interface klasse te maken die deze methode bevat. Vervolgens zullen alle instances die methode moeten implementeren. Het nadeel is dat je dan weer met dynamische binding zit opgescheept (en dus met een indirecte toegang, die in een typische implementatie eerst via wat men in C++ een virtual function table moet, tot de methode).

Is vaak echter wel sneller dan de standaard malloc. Verder zou de JVM met escape analysis bepaalde objecten op de stack kunnen alloceren (Stack allocation and synchronization optimizations for Java using escape analysis).

Als je in een C++ applicatie ook eerst al het geheugen op voorhand alloceert en dan met bijvoorbeeld een placement new werkt, dan zal dat minstens even efficiënt zijn.

Met wat tuning en pruning van features kun je gemakkelijk een JVM variant draaien op een microcontroller (Darjeeling, a Java Compatible Virtual Machine for Microcontrollers).

Mooi.

Is echter voor veel gevallen een acceptabele keuze voor performance vs productivity Quantifying the Performance of Garbage Collection vs. Explicit Memory Management).

Ik heb het echter niet over "veel gevallen". Het gaat hier specifiek over software voor wetenschappelijk rekenen. Hetgeen ook zeer duidelijk is aangegeven in alle posts.

Dat hebben meer talen niet.

Relevantie? Ik maak enkel de opmerking dat Java niet ontworpen is voor wetenschappelijke berekeningen. Het ontbreken van een complex data type is een van de vele voorbeelden waarom.

Een matrix of een vector type kun je in Java introduceren door zelf een class te schrijven.

Zelfde opmerking. Een goede matrix en vector klasse wil je wegens numerieke redenen niet altijd zelf implementeren. Indien deze numerieke redenen belangrijk zijn, dan gebruik je simpelweg BLAS en LAPACK. Op een numeriek accurate wijze het inproduct berekenen van twee vectoren, bijvoorbeeld, is niet zo'n eenvoudige aangelegenheid als je zou denken.

Zie: Soultaker in "Zou ik van Java moeten overschakelen naa..."

Met dank aan Soultaker om het zo mooi samen te vatten. Echter, zoals ik mijn allereerste post al opmerkte is dit een van de historische redenen waarom Java door de scientific computing gemeenschap niet werd opgenomen. Net zoals met C++ overigens.

Zie: ACM in "Zou ik van Java moeten overschakelen naa..."

Uiteraard is de uitvoeringstijd van het dynamisch compileren veelal verwaarloosbaar ten opzichte van de algehele uitvoeringstijd van numerieke software. Het geeft echter aan dat Java niet ontworpen is voor numerieke software. Immers, voor dat soort toepassingen heb je helemaal geen nood aan dynamische compilatie.

Misschien een vraag/aanbod probleem? Als er te weinig interesse is, dan komt zo'n API niet zo maar uit de lucht vallen.

Nogmaals: ik beargumenteer dat Java niet ontworpen werd met wetenschappelijk rekenen in het achterhoofd. Dat er voor deze twee belangrijke bibliotheken geen Java API bestaat, onderstreept alleen maar mijn bewering. Ik beweer helemaal niet dat Java een slechte taal zou zijn omdat er geen API is voor OpenMP en MPI.

Dit is een conclusie getrokken op basis van wat precies? Niet al je aangedragen punten gaan namelijk over performance.

Dat is gebaseerd op de verscheidene ontwerpbeslissingen die vanuit het standpunt van numerieke software overbodig zijn en alleen maar nodeloos de prestaties negatief beïnvloeden. Ik denk niet dat je gaat beweren dat er geen kostprijs in prestaties is van dynamische uitvoering, dynamische compilatie, bounds-checking, garbage collector, etc.

De prestaties van de JVM zijn de afgelopen jaren inderdaad verbeterd, tot het niveau waarop de overhead van al deze features relatief verwaarloosbaar is ten opzichte van de totale uitvoeringstijd. Dat neemt echter niet weg dat als je deze features niet nodig hebt (wat binnen de numerieke software gemeenschap blijkbaar de algemene indruk is), dit gewoon overhead is. Als jij een gedistribueerde 3-tier applicatie wilt maken gebruik je toch ook geen Fortran? Die taal is daar niet voor ontworpen. Het is louter dat wat ik beargumenteer: Java is niet ontworpen voor wetenschappelijke berekeningen. Waarom? Zie lijst van features die we niet nodig hebben voor numerieke software.

[ Voor 13% gewijzigd door Nick The Heazk op 21-09-2009 14:57 ]

[.oisyn]

RayNbow schreef op maandag 21 september 2009 @ 14:01:
Is vaak echter wel sneller dan de standaard malloc.

Non-argument. De allocator in C++ kun je aanpassen, en kun je dus prima finetunen aan je eigen eisen, en zelfs type-afhankelijk. In Java kun je echter niets wijzigen, met uitzondering van wat JVM settings, en ben je dus geheel afhankelijk van de generieke keuzes die anderen gemaakt hebben. Mijn eigen allocator is O(1), lockless threadsafe, en valt alleen terug op malloc() zodra het te alloceren blok groter is dan een bepaalde threshold danwel als het al geclaimde geheugen op is.

[ Voor 15% gewijzigd door .oisyn op 21-09-2009 14:52 ]

[Confusion]

Verwijderd schreef op zaterdag 19 september 2009 @ 22:41:
Daarom raadde hij me aan om C++ te leren in combinatie met de QT library.

Er zijn trouwens prima Qt Java bindings: http://qt.nokia.com/downloads

[coubertin119]

Nick The Heazk schreef op maandag 21 september 2009 @ 14:42:
[...]
Relevantie? Ik maak enkel de opmerking dat Java niet ontworpen is voor wetenschappelijke berekeningen. Het ontbreken van een complex data type is een van de vele voorbeelden waarom.
[...]

De aanwezigheid van std::complex is volgens mij bezwaarlijk een pré te noemen van C++ in de idee dat C++ een hoogperformante taal voor numerieke toepassingen is. Door de datalayout van meerdere std::complex in een array geen berekeningen met SSE toelaat (tenzij via nogal wat shuffles) is het voor een optimaliserende compiler een nogal waardeloos type, tenzij hij nogal rigoureus te werk kan gaan.

Nu is dit nauwelijks een (groot) bezwaar te noemen natuurlijk en als die performantie nodig is schrijf je zelf even je library daarvoor (fftw doet dit voor zover ik weet), maar de kanttekening mag altijd gemaakt worden .

[.oisyn]

coubertin119 schreef op maandag 21 september 2009 @ 22:36:
[...]
De aanwezigheid van std::complex is volgens mij bezwaarlijk een pré te noemen van C++ in de idee dat C++ een hoogperformante taal voor numerieke toepassingen is. Door de datalayout van meerdere std::complex in een array geen berekeningen met SSE toelaat (tenzij via nogal wat shuffles) is het voor een optimaliserende compiler een nogal waardeloos type, tenzij hij nogal rigoureus te werk kan gaan.

std::complex<std::valarray<float>>. Maar da's ook weer alleen handig als je lineair aan het rekenen bent. Als je daarentegen verschillende complexe getallen wilt omzetten naar 1 uitkomst (bijv. het product van alle complexe getallen in een array), dan heb je niets meer aan die aanpak en heb je weer liever een std::vector<std::complex<float>>. Het hangt dus nogal van je toepassing af.

[ Voor 24% gewijzigd door .oisyn op 21-09-2009 23:02 ]

[Nick The Heazk]

coubertin119 schreef op maandag 21 september 2009 @ 22:36:
De aanwezigheid van std::complex is volgens mij bezwaarlijk een pré te noemen van C++ in de idee dat C++ een hoogperformante taal voor numerieke toepassingen is. Door de datalayout van meerdere std::complex in een array geen berekeningen met SSE toelaat (tenzij via nogal wat shuffles) is het voor een optimaliserende compiler een nogal waardeloos type, tenzij hij nogal rigoureus te werk kan gaan.

Ik heb dan ook nergens C++ bestempeld als een hoogperformante taal voor numerieke toepassingen Natuurlijk kan men in C++ wel hoogperformante software schrijven.. Enkele maanden geleden heb ik eens een implementatie overgenomen die met SSE intrinsics werkt om het product te berekenen van twee complexe waarden. Die was trager in het berekenen van het inproduct van twee vectoren dan de door de compiler gegenereerde code voor een eigen implementatie van een complex klasse. Indien jij een snellere versie hebt, dan hoor ik daar zeer graag wat meer over DM me maar if you feel like sharing.

Nu is dit nauwelijks een (groot) bezwaar te noemen natuurlijk en als die performantie nodig is schrijf je zelf even je library daarvoor (fftw doet dit voor zover ik weet), maar de kanttekening mag altijd gemaakt worden .

Uiteraard. Er zijn bedrijven waar men het gebruik van de ganse C++ standard library en STL mijdt omdat men ervan overtuigd is dat deze onvoldoende efficiënt zijn .

[ Voor 4% gewijzigd door Nick The Heazk op 21-09-2009 23:02 ]

[Confusion]

Nick The Heazk schreef op zaterdag 19 september 2009 @ 23:33:
Je zit opgescheept met een garbage collector die te pas en te onpas je programma verstoort.

Nick The Heazk schreef op maandag 21 september 2009 @ 10:24:
Een garbage collector die in het midden van een hoog geoptimaliseerd matrix-vector product even besluit om wat geheugen op te ruimen is gewoon hopeloos inefficiënt.

De GC is meestal irrelevant, gezien het beperkte aantal keren, en de beperkte hoeveelheid tijd, dat hij zijn werk doet. Het is meer FUD dan wijsheid.

[momania]

Ook de GC is ondertussen al onderhevig aan verbeteringen, zie: http://developers.sun.com...5419&yr=2008&track=javase

Wat ook veel mensen vergeten is dat een JVM verschillende optimalisatie slagen per CPU type (naast CPU architectuur) kan maken. Dus niet alleen bv x86 optimalisaties, maar ook verschillende optimalisaties eruit weet te halen tussen een Intel x86 en een AMD x86, etc. Met allernieuwste features van CPU's kan je dus wel een beetje achter lopen, maar het scheelt nog altijd wel.

[rapture]

Nick The Heazk schreef op zaterdag 19 september 2009 @ 23:33:
Je zit opgescheept met een garbage collector die te pas en te onpas je programma verstoort.

Nick The Heazk schreef op maandag 21 september 2009 @ 10:24:
Een garbage collector die in het midden van een hoog geoptimaliseerd matrix-vector product even besluit om wat geheugen op te ruimen is gewoon hopeloos inefficiënt.

Het klinkt alsof je de ABS van een wagen op Java probeert te laten draaien. De GC komt langs, de ABS houdt eventjes op met werken en de wagen ligt naast de weg.

Af en toe een korte onderbreking is niet storend voor de meeste software en procentueel is zo'n onderbreking niet op te merken.

[Olaf van der Spek]

Nick The Heazk schreef op maandag 21 september 2009 @ 14:42:
Uiteraard is de uitvoeringstijd van het dynamisch compileren veelal verwaarloosbaar ten opzichte van de algehele uitvoeringstijd van numerieke software. Het geeft echter aan dat Java niet ontworpen is voor numerieke software. Immers, voor dat soort toepassingen heb je helemaal geen nood aan dynamische compilatie.

Dat het geen voordeel is betekent toch niet automatisch dat het een nadeel is?

Nogmaals: ik beargumenteer dat Java niet ontworpen werd met wetenschappelijk rekenen in het achterhoofd. Dat er voor deze twee belangrijke bibliotheken geen Java API bestaat, onderstreept alleen maar mijn bewering. Ik beweer helemaal niet dat Java een slechte taal zou zijn omdat er geen API is voor OpenMP en MPI.

Of Java wel of niet ontworpen is voor wetenschappelijk rekenen lijkt me niet zo relevant. De vraag is of het er wel of niet bruikbaar voor is.