Ik denk dat de java->bytecode compiler in Java dat niet (meer) doet, maar de JVM (eigenlijk ook een compiler, maar dan een dynamische
).
[ Voor 29% gewijzigd door .oisyn op 04-08-2005 17:37 ]
Verwijderd
).
:strip_exif()/u/31626/eend.gif?f=community)
Uiteraard. Bytecode is de binaire verse van sourcecode waarbij erg weinig informatie verloren gaat en niet geoptimaliseerd wordt. De optimize compilerflag werkt daarom ook niet.
De JIT-Compiler., maar de JVM (eigenlijk ook een compiler, maar dan een dynamische
Maar probeerde je me iets duidelijk te maken of had je gewoon ff zin om te reageren
Verwijderd
Beiden:
[...]
Maar probeerde je me iets duidelijk te maken of had je gewoon ff zin om te reageren
Maar het was eigenlijk meer bedoeld om de situatie te verduidelijken voor de C++ mensen. Met 'de compiler' zullen veel mensen in eerste instantie aan javac en consorten denken (de java -> bytecode compiler dus). Wat meer advanced java mensen (jij dus vast ook wel ) weten dat deze (statische) compiler eigenlijk weinig doet en dat je dus de JVM 'jit' compiler bedoelde.
:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)
Nou vind ik het idd interessant om te lezen dat de compiler (javac) idd geen enkele optimalisaties doet. Weet iemand waar ik meer kan lezen over wat voor optimalisaties de VM zelf allemaal doet? 't Zal wel per VM implementatie verschillen maar de standaard Java VM is fine
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
/u/17112/crop5862473fe8c51_cropped.png?f=community)
Hmm, javac misschien niet (hoewel ik dat ook niet zeker weet, volgens mij worden loops en dergelijke welzeker geoptimized), maar als je bijvoorbeeld kijkt naar de Eclipse compiler die optimized wel degelijk. In de zin van ongebruikte vars niet in bytecode opnemen bijvoorbeeld.:
Nou vind ik het idd interessant om te lezen dat de compiler (javac) idd geen enkele optimalisaties doet. Weet iemand waar ik meer kan lezen over wat voor optimalisaties de VM zelf allemaal doet? 't Zal wel per VM implementatie verschillen maar de standaard Java VM is fine
Even een testje gedaan en de Eclipse compiler knikkert in dit geval inderdaad k weg:
Java:
1
2
3
4
5
6
| public void test() { int j = 10; int k = 20; System.out.println(j); } |
Met javap krijg je dan dit:
code:
1
2
3
4
5
6
7
8
9
| public void test(); Code: 0: bipush 10 2: istore_1 3: getstatic #20; //Field java/lang/System.out:Ljava/io/PrintStream; 6: iload_1 7: invokevirtual #26; //Method java/io/PrintStream.println:(I)V 10: return } |
Geen spoor van een bipush 20 dus...
Ik heb ook wat met loops getest, maar die blijven in de bytecode zitten dus die worden dan blijkbaar in de JIT stap geoptimized (of niet
)
[ Voor 35% gewijzigd door grhmpf op 02-08-2005 23:31 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Ik had het dan ook over de VM, goed blijven lezen he
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Dit begint wel off-topic te raken maar ik kom op het einde wel met een keyword.
Java compilers zullen over het algemeen inderdaad weinig optimalisaties doorvoeren in hun bytecode. Het enige wat je er aan kunt tweaken is het weg-optimaliseren van ongebruikte code, niet opnemen van debugging informatie en bijvoorbeeld extra constructies op te nemen om exception handling te versnellen (kan in Eclipse compiler). De java compiler moet code klasse voor klasse compileren en heeft daarom relatief weinig context om high level optimalisaties te kunnen doen.
Het echte interessante optimaliseerwerk gebeurt in de JIT compiler. Zaken als method inlining worden hier dynamisch bepaald op basis van bereikbaarheidspaden die tijdens runtime pas echt opgelost kunnen worden. Er is dan echter wel een schat aan informatie waarmee geoptimaliseerd kan worden, veel meer dan de (traditionele) compileer processen.
Java, .NET en ander JIT compiler constructies hebben hiermee de potentie om de vloer aan te vegen met programmeeromgevingen als C en C++. Verschillende micro-benchmarks laten dat nu al zien. Tel hierbij op de performancevoordelen die een garbage collector en real-time adaptive thread management je kunnen bieden op serieuze computersystemen, en je weet dat de dagen van unmanaged code voor het schrijven van applicaties geteld zijn.
Je kunt de JIT compiler (en de runtime) een handje helpen tijdens het schrijven van Java code. De regel is dat hoe strakker je Java code schrijft hoe beter de mogelijkheden zijn voor de omgeving om te gaan optimaliseren. Hou rekening met variabele scoping, maak klasses, methodes en velden final als het kan, maak inner klasses static als het kan en voorkom het gebruik van synthetic accessors.
Als je nu niet weet waar ik het over heb, niet getreurd! De allerbeste manier om snelle code te schrijven blijft ouderwets gezond verstand gebruiken en dingen op de meest simpele en efficiente manier oplossen. De beste compiler zit namelijk nog steeds achter het toetsenbord.
Java compilers zullen over het algemeen inderdaad weinig optimalisaties doorvoeren in hun bytecode. Het enige wat je er aan kunt tweaken is het weg-optimaliseren van ongebruikte code, niet opnemen van debugging informatie en bijvoorbeeld extra constructies op te nemen om exception handling te versnellen (kan in Eclipse compiler). De java compiler moet code klasse voor klasse compileren en heeft daarom relatief weinig context om high level optimalisaties te kunnen doen.
Het echte interessante optimaliseerwerk gebeurt in de JIT compiler. Zaken als method inlining worden hier dynamisch bepaald op basis van bereikbaarheidspaden die tijdens runtime pas echt opgelost kunnen worden. Er is dan echter wel een schat aan informatie waarmee geoptimaliseerd kan worden, veel meer dan de (traditionele) compileer processen.
Java, .NET en ander JIT compiler constructies hebben hiermee de potentie om de vloer aan te vegen met programmeeromgevingen als C en C++. Verschillende micro-benchmarks laten dat nu al zien. Tel hierbij op de performancevoordelen die een garbage collector en real-time adaptive thread management je kunnen bieden op serieuze computersystemen, en je weet dat de dagen van unmanaged code voor het schrijven van applicaties geteld zijn.
Je kunt de JIT compiler (en de runtime) een handje helpen tijdens het schrijven van Java code. De regel is dat hoe strakker je Java code schrijft hoe beter de mogelijkheden zijn voor de omgeving om te gaan optimaliseren. Hou rekening met variabele scoping, maak klasses, methodes en velden final als het kan, maak inner klasses static als het kan en voorkom het gebruik van synthetic accessors.
Als je nu niet weet waar ik het over heb, niet getreurd! De allerbeste manier om snelle code te schrijven blijft ouderwets gezond verstand gebruiken en dingen op de meest simpele en efficiente manier oplossen. De beste compiler zit namelijk nog steeds achter het toetsenbord.
Ja en nee. Het hebben van runtime informatie kan enorm schelen, maar een taal als Java is te restrictive om het op te nemen tegen C++. Java heeft nog altijd geen pointers en geen value-type objects, constructies die performance drastisch beinvloeden. Daarnaast wordt er gewoon nog teveel gecontrolleerd (array access, typecasting, niet volledige x87 compatible floating point unit, etc.). Je hebt helemaal gelijk als je zegt dat een JIT compiler beter kan optimaliseren dan een traditionele C++ compiler, je hebt echter imho geen gelijk als Java als taal C++ zou kunnen outperformen.
Onzin, waarom zou een garbage collector performance voordelen hebben? Het is een extra analyse stap die gedaan moet worden, en niet gedaan hoeft te worden in C++, altijd meer overhead dus. En vergeet niet dat je in C++ vrijwel alle side-effects van het memory model van de Java VM kunt simuleren zonder alteveel moeite.
Ik zie niet in hoe Java meer invloed kan hebben op dingen die door je OS geregeld worden dan dat je in een native taal kunt bewerkstelligen.
Nou hoop ik hier dat je het niet tegen mij hebt, en anders stel ik voor om even op m'n profile te klikkenAls je nu niet weet waar ik het over heb, niet getreurd! De allerbeste manier om snelle code te schrijven blijft ouderwets gezond verstand gebruiken en dingen op de meest simpele en efficiente manier oplossen. De beste compiler zit namelijk nog steeds achter het toetsenbord.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
:strip_icc():strip_exif()/u/2626/nice_eye.jpg?f=community)
/u/2046/pooh2.png?f=community)
/u/27299/hoofd.png?f=community)
Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein
Omdat je in Java alleen pointers kunt maken naar volledige objecten, niet naar een element in een array of naar een functie of gewoon simpelweg een primitive, en je kunt er geen arithmetic op doen. Misschien was ik wat onduidelijk, met pointers bedoel ik idd C/C++ style pointers, niet Java-style references.
Hoe kan een JIT compiler random access in een array wegoptimaliseren? De check moet gewoon gedaan worden, anders voldoet het niet aan de specs.
Zie de opmerking van MSalters, en het feit dat ik in mijn vorige post al zei dat het memory model van Java best in C++ te simuleren is, en ook vrij bruikbaar is met gebruik van template classes die zich gedragen als pointers.
Waarom is dat een tegenspraak? C++ heeft toch allebei?
Ja ik had wat duidelijker moeten zijn, zie boven
Dit is idd exact wat ik bedoel. Het geheugen is de grote bottleneck, ik zat laatst te profilen op de P4 3.2 GHz hier op m'n werk en stalls van 350 cycles (!!!) bij een cache-miss zijn vrij veelvoorkomend. In die 350 cycles kun je behoorlijk wat doen, en het is dan ook noodzaak om te zorgen dat je de data die je nodig hebt zoveel mogelijk in de L1 cache klaar hebt staan. Dingen als linked lists, trees en arrays van pointers zijn nogal funest als de objecten in de datastructuur gescattered door het geheugen zijn. In onze games zorgen we ervoor dat dit soort structuren hun objecten uit een eigen pool halen, maar het meest belangrijk is nog wel het niet gebruiken van een datastructuur die zogenaamd efficient kan zoeken en inserten/deleten omdat een simpele lineaire search in een array van non-pointers gewoon veel meer cache-friendly is. En insertion/deletion overhead moet je dan maar voor lief nemen. Dit geldt uiteraard tot een bepaalde thresshold van aantal elementen waar het break-even point bereikt wordt, maar die thresshold ligt nog verassend hoog imho.
Ik zie ook zeker wel het nut van java en .Net, maar dat is niet voor performance-critical applicaties zoals games en simulaties, en mensen die beweren dat Java of .Net ooit C++ zal overstijgen in performance geloof ik gewoon niet (de C++ compilers staan immers ook niet stil)
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Natuurlijk kan dat, maar je zegt het zelf al, in sommige gevallen
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Verwijderd
Mischien dat ik nu niet helemaal duidelijk was. Wat ik bedoelde was dat als Java dus EN geen pointers zou hebben EN geen value-objects, dat je dan dus erg weinig overhoudt in Java
Dat was de tegenspraak waar ik op wees.Dat C++ idd allebei heeft (en dat dat een groot voordeel kan zijn) klopt inderdaad, maar stond los van de bedoeling van mijn opmerking.
Wat overigens ook een voordeel is van het feit dat je in C++ value objecten hebt, is dat in een samengesteld object je een -echte- "composition" hebt en niet zoals in Java alleen het wat zwakkere (algemenere) "Aggregation". Los van de performance voordelen, heb je bij een composition een sterke notie van ownership en lifetime. (Als je in C++ de 'whole' vernietigd, gaan alle value 'parts' automatisch mee. In Java zullen de poiner 'parts' niet voor GC gemarkeerd worden als er nog een andere entity is die een pointer naar zo'n part bezit).
[ Voor 47% gewijzigd door Verwijderd op 04-08-2005 12:58 ]
Ah ok, maar zoals gezegd vind ik de object references in Java geen pointers:
Mischien dat ik nu niet helemaal duidelijk was. Wat ik bedoelde was dat als Java dus EN geen pointers zou hebben EN geen value-objects, dat je dan dus erg weinig overhoudt in Java
. Maar idd, zo lijkt het op een tegenspraak.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Ik denk eerder bijna alle gevallen...:
Natuurlijk kan dat, maar je zegt het zelf al, in sommige gevallen
"Beauty is the ultimate defence against complexity." David Gelernter
Ja, precies, wel mooi voorbeeld. Dus als je een foutje maakt in de lifetimes van je objecten crashed misschien je applicatie in bepaalde situaties, en je hebt niet echt een idee waarom, want je kan het slecht debuggen omdat de dereference en de destructie ongerelateerd zijn en ver van elkaar plaats kunnen vinden, in afstand en tijd....:
[...]
Mischien dat ik nu niet helemaal duidelijk was. Wat ik bedoelde was dat als Java dus EN geen pointers zou hebben EN geen value-objects, dat je dan dus erg weinig overhoudt in Java
Dat C++ idd allebei heeft (en dat dat een groot voordeel kan zijn) klopt inderdaad, maar stond los van de bedoeling van mijn opmerking.
Wat overigens ook een voordeel is van het feit dat je in C++ value objecten hebt, is dat in een samengesteld object je een -echte- "composition" hebt en niet zoals in Java alleen het wat zwakkere (algemenere) "Aggregation". Los van de performance voordelen, heb je bij een composition een sterke notie van ownership en lifetime. (Als je in C++ de 'whole' vernietigd, gaan alle value 'parts' automatisch mee. In Java zullen de poiner 'parts' niet voor GC gemarkeerd worden als er nog een andere entity is die een pointer naar zo'n part bezit).
Wat is dan beter denk je zelf?
Conclusie:
Java is makkelijker programmeren
C++ is krachter en heeft meer mogelijkheden
C++ is in veel gevallen sneller
maar niet in alle gevallen
de JIT compiler wordt elk jaar beter
Orde van grote tussen de snelheid van code voor beide platformen verschillen niet zo enorm dat je Java niet kan gebruiken voor 95-99% van alle gevallen.
"Beauty is the ultimate defence against complexity." David Gelernter
Een beginner ja, een ervaren C++ programmeur heeft dit probleem niet. En nee, hoe vriendelijk een taal is voor beginners vind ik als pro geen belangrijk argument
. In C++ ga je namelijk nogal anders om met memory management en lifetimes van objects. In de regel heb je dan ook nooit een losse pointer naar een member van een class, maar gewoon een refcounted pointer naar die class instance zelf. Het betreft gewoon een compleet andere manier van managen, en dus kun je Java en C++ op dat gebied niet met elkaar vergelijken. Ook in Java kun je memleaks hebben, en je merkt ze zelfs minder vaak op omdat je er toch al vanuit gaat dat de GC alle zooi voor jou opruimt. Een dangling reference die je dan nog ergens hebt verlies je al snel uit het oog.Nee, dit geldt slechts voor de beginnende programmeur. Logisch ook, minder features maakt het al snel makkelijker
. Daarnaast vergeten veel mensen de kracht van simpele destructors, nog veel handiger dan een garbage collector (ook handig voor exception safe programming).Wanneer is C++ dan niet sneller, gegeven een goed ontworpen applicatie in zowel C++ als Java? Waar het om gaat is: wanneer is die snelheid belangrijk (dan C++) en wanneer is cross-platform (enterprise) development belangrijk (dan Java) (for the sake of argument doe ik even net of er geen andere talen bestaan
). Als geen van beide punten belangrijk zijn moet je gewoon lekker devven in de taal van je eigen keuze.C++ compilers ook, dus dit is geen argument. Wat je wel krijgt is dat een 10 jaar oude C++ app niet sneller performt dan 10 jaar geleden, terwijl een 10 jaar oude Java app wel sneller performt. Maar ja, dat is natuurlijk een kwestie van op de recompile knop drukken, en applicatie development staat zolang het wordt gebruikt over het algemeen ook niet echt stil.
Ik denk dat niemand hier beweert dat je überhaupt geen Java moet gebruiken, moot point dus.
[ Voor 9% gewijzigd door .oisyn op 04-08-2005 17:00 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein
Ik wil even beginnen met te benadrukken dat de zogenaamde "VM's" of "managed code" de potentie hebben om over het algemeen sneller te zijn dan een "standaard" omgeving. Ik zal zeker niet beweren dat het nu al zo is, en er zullen natuurlijk altijd uitzonderingen zijn waarin een stukje C++ code in een bepaalde situatie sneller is. Met een managed omgeving zul je theoretisch met veel minder moeite een zeer goed presterende applicatie kunnen maken, die ook nog eens zich beter aanpast aan de beschikbare resources. En theorie en praktijk komen steeds dichterbij.
Anderen maakten de opmerking ook al, array access checks worden in de meeste situaties weggeoptimaliseerd, typecasting in Java is erg goedkoop. Java checkt inderdaad meer maar kan sommige dingen ook efficienter checken vanwege de extra context.
Je hebt inderdaad in C++ ook smart-pointers en malloc varianten die memory fragmentatie voorkomen. Daar hoort ook een stuk administratie bij, en heb je al snel een soort mini-gc. Ik weet ook niet of het helemaal zonder moeite werkt, zeker als je third-party code gaat gebruiken die wellicht uitgaat van een ander geheugen management.
Als je de snelle malloc en de garbage collector naast elkaar zet dan is er opnieuw een verschil in context. De garbage collector weet hoe druk de cpu het heeft, hoeveel geheugen er nog vrij is, of er naar een disk gepaged wordt, of er nog ruimte is in de cache, wat het allocatiepatroon het afgelopen half uur was, enz.
De snelle malloc implementatie zou ook met al dit soort dingen rekening kunnen gaan houden, maar dan begint het ook steeds meer "managed" te worden, en zou het verschil in overhead ook veel kleiner worden. Hetzelfde verhaal geldt ook voor bijvoorbeeld multi-core/multi-processor systemen, verschillen in processor architecturen, enz.
Natuurlijk kun je in C++ allemaal dingen maken die dit gaan controleren en er op gaan optimaliseren. Om dit net zo snel te krijgen zul je ook een vorm van JIT compiler moeten maken, anders zouden er te veel checks gemaakt moeten worden tijdens het uitvoeren van de code.
Natuurlijk wel theoretisch, in de praktijk blijft het handig om te testen en om wel er wat van af te weten. Maar je krijgt echt een heleboel cadeau. De ontwikkeling van hardware is zodanig dat code steeds meer moeite zal moeten doen om het ook nuttig te gebruiken, en ook in die context zullen managed omgevingen steeds beter aansluiten en performen.
Ik zie dat jij bezig bent met een games project. Wist je dat heel lang mensen geen games schreven in C++ omdat het "te traag" was? Het schrijven van snelle managed code vereist oefening, ervaring en inzicht. De gebruikersgroep van C++ en Java is ook nog anders. In het C++ kamp zitten meer mensen die veel weten over hoe een computer van binnen werkt en hoe ze dat snel kunnen(willen) krijgen. In het Java kamp zitten meer mensen die het belangrijker vinden om snel een onderhoudbare applicatie in elkaar te draaien, en denken meer in gele vierkantjes met pijltjes dan in bits en bytes. Daarom zie je als resultaat snelle C++ code en trage Java code. In de meeste gevallen is de echte performance bottleneck is de programmeur. Vandaar ook mijn opmerking: het gezonde verstand is de beste compiler.
Java heeft inderdaad geen taal-feature om eigen constructies op de stack te plaatsen. .NET/ C# heeft dit wel. Het niet hebben van een taal-feature wil niet zeggen dat de JIT compiler dit toch niet zou kunnen doen in sommige situaties, er zou kunnen worden besloten na analyse van lifetime en gebruikspatroon dat een object op de stack gealloceerd wordt ipv de heap (Java JIT doet dit nog niet voor zover ik weet). Het gaat mij ook niet om taal X vs taal Y, maar om "voorgecompileerde code" vs "managed code".
Anderen maakten de opmerking ook al, array access checks worden in de meeste situaties weggeoptimaliseerd, typecasting in Java is erg goedkoop. Java checkt inderdaad meer maar kan sommige dingen ook efficienter checken vanwege de extra context.
Een garbage collector voorkomt memory fragmentatie en verhoogt lokaliteit van je geheugen, waardoor je minder kans hebt op cache misses (zoals je zelf al aangeeft kan een cache miss veel schelen).
Je hebt inderdaad in C++ ook smart-pointers en malloc varianten die memory fragmentatie voorkomen. Daar hoort ook een stuk administratie bij, en heb je al snel een soort mini-gc. Ik weet ook niet of het helemaal zonder moeite werkt, zeker als je third-party code gaat gebruiken die wellicht uitgaat van een ander geheugen management.
Als je de snelle malloc en de garbage collector naast elkaar zet dan is er opnieuw een verschil in context. De garbage collector weet hoe druk de cpu het heeft, hoeveel geheugen er nog vrij is, of er naar een disk gepaged wordt, of er nog ruimte is in de cache, wat het allocatiepatroon het afgelopen half uur was, enz.
De snelle malloc implementatie zou ook met al dit soort dingen rekening kunnen gaan houden, maar dan begint het ook steeds meer "managed" te worden, en zou het verschil in overhead ook veel kleiner worden. Hetzelfde verhaal geldt ook voor bijvoorbeeld multi-core/multi-processor systemen, verschillen in processor architecturen, enz.
Natuurlijk kun je in C++ allemaal dingen maken die dit gaan controleren en er op gaan optimaliseren. Om dit net zo snel te krijgen zul je ook een vorm van JIT compiler moeten maken, anders zouden er te veel checks gemaakt moeten worden tijdens het uitvoeren van de code.
Ik kan in Java code schrijven die geoptimaliseerd wordt voor machines en OS-en die nog niet eens bestaan. Als die machines en OS-en wel komen dan hoef je alleen maar een nieuwe versie van Java te pakken en je code wordt automatisch geoptimaliseerd. Ook voor bestaande hardware geldt hetzelfde argument. Ik hoef niet allerlei hardware te kopen, boeken te lezen en me te verdiepen in allerlei soorten optimalisaties. Ik moet alleen weten hoe ik de runtime, JIT compiler en garbage collector kan helpen om code snel uit te voeren.
Natuurlijk wel theoretisch, in de praktijk blijft het handig om te testen en om wel er wat van af te weten. Maar je krijgt echt een heleboel cadeau. De ontwikkeling van hardware is zodanig dat code steeds meer moeite zal moeten doen om het ook nuttig te gebruiken, en ook in die context zullen managed omgevingen steeds beter aansluiten en performen.
Ik zie dat jij bezig bent met een games project. Wist je dat heel lang mensen geen games schreven in C++ omdat het "te traag" was? Het schrijven van snelle managed code vereist oefening, ervaring en inzicht. De gebruikersgroep van C++ en Java is ook nog anders. In het C++ kamp zitten meer mensen die veel weten over hoe een computer van binnen werkt en hoe ze dat snel kunnen(willen) krijgen. In het Java kamp zitten meer mensen die het belangrijker vinden om snel een onderhoudbare applicatie in elkaar te draaien, en denken meer in gele vierkantjes met pijltjes dan in bits en bytes. Daarom zie je als resultaat snelle C++ code en trage Java code. In de meeste gevallen is de echte performance bottleneck is de programmeur. Vandaar ook mijn opmerking: het gezonde verstand is de beste compiler.
:strip_exif()/u/72391/Pinky_and_the_Brain_-_Brain.gif?f=community)
Dit is een zeer interessante thread voor me. Ik begin in september aan m'n thesis en daarvoor moet ik een app schrijven wat een hoop rekenwerk gevoerd zal krijgen. Ik ben onderhand al aan het denken hoe ik dit voor mekaar zal krijgen.
Op dit moment worden die berekeningen in Excel met VBa gedaan en duren ze om en bij een kwartier. (zo heb'k me laten vertellen) Dit natuurlijk om dat de VB-code daar als'k me niet vergis ge-interpreteerd wordt ?
Ik dacht dus op dit moment aan de volgende opstelling: Ik doe alles(gui enz) in C#/.NET en het rekenwerk stuk schrijf ik in een C++ DLL. Nu hebben jullie me natuurlijk aan het twijfelen gebracht (goed gedaan jonges
)
Ik dacht tot voorheen altijd dat java en vriendjes oertraag waren. (motto: alles draait lekker op een 10GHz machine
) Dit is complete bs, maar C++ heeft nog steeds een mooi performance voordeel tov Java/C#/enz(in het geval dat beide optimaal geschreven zijn). M'n broer vertelde me dinsdag dat een C#/.NET app ruwweg 70% snelheid van een C++ app heeft (kort door de bocht natuurlijk). Dit volgens enkele metingen/reviews/...
Hier zijn al enkele mooie stellingen gepasseerd zoals:
"Een extra CPU-tje in een server steken kost minder dan extra manuren dev-tijd" en nog meer zulks.
Waar ik mijn vakantiejob deed dev'en ze ook enkel in 4GL's (VB.NET) omdat dit gemakkelijk is (en dus waarschijnlijk minder dev-tijd/kosten)
Ik denk dus dat ik m'n eerste opstelling(schrijf eerst alles in C#/.Net, en als het te traag is port je bepaalde stukken naar C++) maar volg... En ik zal dit topic natuurlijk proberen te volgen
@misfire hier net boven ("de beste compiler is het gezond verstand")
dat is denk ik met alles zo. wie meer "weet" over de implementatie/mogelijkheden/... kan die altijd beter benutten/uitbuiten (en kan natuurlijk ook altijd harder tegen de muur lopen als hij een detail vergeet )
Op dit moment worden die berekeningen in Excel met VBa gedaan en duren ze om en bij een kwartier. (zo heb'k me laten vertellen) Dit natuurlijk om dat de VB-code daar als'k me niet vergis ge-interpreteerd wordt ?
Ik dacht dus op dit moment aan de volgende opstelling: Ik doe alles(gui enz) in C#/.NET en het rekenwerk stuk schrijf ik in een C++ DLL. Nu hebben jullie me natuurlijk aan het twijfelen gebracht (goed gedaan jonges
)Ik dacht tot voorheen altijd dat java en vriendjes oertraag waren. (motto: alles draait lekker op een 10GHz machine
) Dit is complete bs, maar C++ heeft nog steeds een mooi performance voordeel tov Java/C#/enz(in het geval dat beide optimaal geschreven zijn). M'n broer vertelde me dinsdag dat een C#/.NET app ruwweg 70% snelheid van een C++ app heeft (kort door de bocht natuurlijk). Dit volgens enkele metingen/reviews/...Hier zijn al enkele mooie stellingen gepasseerd zoals:
"Een extra CPU-tje in een server steken kost minder dan extra manuren dev-tijd" en nog meer zulks.
Waar ik mijn vakantiejob deed dev'en ze ook enkel in 4GL's (VB.NET) omdat dit gemakkelijk is (en dus waarschijnlijk minder dev-tijd/kosten)
Ik denk dus dat ik m'n eerste opstelling(schrijf eerst alles in C#/.Net, en als het te traag is port je bepaalde stukken naar C++) maar volg... En ik zal dit topic natuurlijk proberen te volgen
@misfire hier net boven ("de beste compiler is het gezond verstand")
dat is denk ik met alles zo. wie meer "weet" over de implementatie/mogelijkheden/... kan die altijd beter benutten/uitbuiten (en kan natuurlijk ook altijd harder tegen de muur lopen als hij een detail vergeet
)
[ Voor 10% gewijzigd door H!GHGuY op 04-08-2005 22:01 ]
ASSUME makes an ASS out of U and ME
Een garbage collector voorkomt geen memory fragmentatie. Je beschrijft het gedrag van een memory manager die objecten kan verplaatsen. Dat zat al in Windows 1.0 voor de 8086 (geen grapje!). Alles wat je daar met GlobalAlloc alloceerde kon verschoven worden.
malloc varianten zijn niet zo relevant; C++ gebruikt in principe new/delete. Inderdaad heb je te maken met een behoorlijk complexe memory manager. Dat is niet erg. In die dingen wordt serieus geld gepompt. Microsoft wil niet alleen dat de developers tevreden zijn, maar gebruikt ook memory managers in Windows, Office, SQL Server etc. Dat zijn allemaal applicaties die in benchmarks worden gebruikt. Dat krijg je allemaal gratis.
Pardon? Je denkt dat een VM garbage collector beter kan werken dan de typische OS allocator? Goede kans dat de VM niet eens weet hoeveel CPUs er zijn (OK, op x86/Windows is dat meestal wel het geval
) Een OS allocator kan zelfs integreren met het paging algoritme, zoals in Windows NT.Nee. Een goede allocator reageert op de verzoeken om geheugen. In C++ wordt dat expliciet terug gegeven. De memory manager hoeft daarom geen inzicht te hebben in het gebruik; de operator delete calls geven genoeg informatie.
Dat was .oisyn, maar goed. Ik heb zelfs het verhaal gehoord dat AT&T het niet gebruikte in hun telefooncentrales, terwijl Bjarne toch echt bij Bell Labs werkte? Ook dat was vanwege de snelheid. Dat was in de tijd dat C++ compilers nog niet zo goed waren als vandaag de dag. Een moderne C++ compiler produceert ongeveer even snelle code als een C compiler, en soms sneller (vanwege typesafety en de allocators).
Voor diegenen die inhoudelijk aan wat van mijn claims twijfelen: ik heb met meerdere developers van MSVC++ gesproken over precies dit onderwerp, o.a. Bill Plauger. Da's een erkend expert, en zijn idee is dat allocators nog veel beter kunnen dan nu.
Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein
Dat zijn inderdaad realistische cijfers. Het enige probleem is dat de cijfers bij rekenwerk wat extremer zijn. Zeker bij hoge nauwkeurigheden (80 bits) is Java extreem traag, maar ook bij 64 bits FP is C++ significant sneller. Matrix wiskunde is helemaal onvergelijkbaar. Daar is C++ concurrerend met FORTRAN, zeker icm de Intel9 vector compiler. Aan de andere kant: 15 minuten VBA code? Zelfs met java moet dat onder de 5 minuten kunnen. Hoeveel eronder is de moeite nog?:
Ik begin in september aan m'n thesis en daarvoor moet ik een app schrijven wat een hoop rekenwerk gevoerd zal krijgen. Ik ben onderhand al aan het denken hoe ik dit voor mekaar zal krijgen.
Op dit moment worden die berekeningen in Excel met VBa gedaan en duren ze om en bij een kwartier. (zo heb'k me laten vertellen) Dit natuurlijk om dat de VB-code daar als'k me niet vergis ge-interpreteerd wordt ?
Ik dacht dus op dit moment aan de volgende opstelling: Ik doe alles(gui enz) in C#/.NET en het rekenwerk stuk schrijf ik in een C++ DLL. Nu hebben jullie me natuurlijk aan het twijfelen gebracht
Ik dacht tot voorheen altijd dat java en vriendjes oertraag waren. (motto: alles draait lekker op een 10GHz machine
Hoe vaak gaat het draaien?
Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein
Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein
Ik reageer slechts even met dingen die nog niet gezegd zijn:.. Die biedt gewoon the best of both worlds..) op een specifiek platform. En ja, upgraden is vaak goedkoper dan developen, maar helaas gaat dat in de gamesindustrie niet op: je wil een zo groot mogelijke doelgroep bereiken, daarnaast kun je consoles en handhelds niet eens upgraden.
Je originele opmerking was:
En verderop in je tweede post (waar ik nu op reageer) zeg je nog:
Toch heb je het steeds over JIT vs. C/C++. Waarom zou C/C++ niet in een managed omgeving kunnen draaien? Het is natuurlijk niet impliciet dat een C++ app altijd direct naar native code hoeft te compilen. Ik reageerde dan ook puur op Java vs. C++: Java heeft imho te weinig features om ooit de vloer aan te kunnen vegen met C++, of dat nou native of JITed is. En dát was de essentie van mijn post, niet VM vs. native, ook al is de tendens dat Java in een VM draait en C++ naar native machinecode gecompileerd wordt
.Idd, en daarom vind ik C# ook veel interessanter dan Java, ook door de feature van het toelaten van "unsafe" code. Maar goed, C++/cli komt eraan en dus zal mijn interesse voor C# nooit ver komen
. Die biedt gewoon the best of both worlds.Mja, maar dat vind ik voorlopig nog maar een theoretische gedachtenkronkel. Daarnaast gaat het lang niet alleen over objecten aanmaken op de stack, maar gewoon objecten in-place alloceren in de container: de stack als het een locale variabele of locale array (!!!) betreft, of in het class instance geheugen als het een member van een class betreft. En een value-type zoals een 3d vector of een matrix komt nu specifiek in mij op, die ik in m'n software renderer destijds continu moest new'en. Het punt is dat je door Java's reflection model nooit kunt garanderen dat er geen referentie wordt gemaakt naar die member van de class, en de enige manier om ervoor te zorgen dat dat niet uitmaakt is zorgen dat dat object immutable is, zoals bijvoorbeeld een String (waardoor de VM kan besluiten te copy'en). Dit heeft echter gigantische nadelen op performance als een JIT compiler de optimalisatie van het in-place alloceren niet doet. Natuurlijk kan het allemaal theoretisch, maar ik zie het niet snel gebeuren, if at all.
Nou vraag ik me af over hoe lang geleden je het nou precies hebt. C++ kun (of kon althans) je zien als een superset van C++, en derhalve kon je ook C-style code compileren in C++ zonder verschil in snelheid. C++ biedt alleen meer, en idd, zoals MSalters al meldde, vroeger waren de C++ compilers nog niet zo goed in optimaliseren. Nou praat je echter over een hele tijd terug, de reden dat gamedevelopers C++ schuwen is over het algemeen nooit feitelijk snelheid geweest, maar meer het "langzame" imago dat C++ nog had van vroeger en het feit dat gamedevelopers over het algemeen verstokte programmeurs zijn die niet snel iets nieuws zullen ontarmen of iets nieuws aan willen leren
.Dat geldt voor alle code. De meeste 'traagheid' is gerelateerd aan het gebruiken van de verkeerde algoritmes of datastructuren voor een bepaald probleem, als je dat goed onder de knie hebt ben je al een heel eind, ongeacht de taal. Als je daarna nog meer wilt zul je je moeten gaan verdiepen in een specifieke taal (C++ comes to mind
) op een specifiek platform. En ja, upgraden is vaak goedkoper dan developen, maar helaas gaat dat in de gamesindustrie niet op: je wil een zo groot mogelijke doelgroep bereiken, daarnaast kun je consoles en handhelds niet eens upgraden.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
/u/71437/crop6867a75b81f09_cropped.png?f=community)
Nogmaals voor mij is het geen discussie Java vs C/C++. Ik haalde C/C++ slechts aan als voorbeeld van een omgeving waarin voorgecompileerde code direct wordt uitgevoerd, vs omgevingen die dynamisch code optimaliseren voor de omgeving (mbv JIT compilers en GC's). Ik had het in mijn eerste reactie ook naast C/C++ over "traditionele compileer processen", "unmanaged code", waarom het verschil aanwezig is in momenten waarop geoptimaliseerd wordt, en waarom dit niet nadelig hoeft te zijn en zelfs imho de toekomst heeft.
Ik zal het er maar op houden dat mijn eerste reactie met iets te veel optimalisaties gelezen werd en er slechts "taal C/C++ is traag" uitkwam oid. Nog meer tegeltjeswijsheid: premature optimisation is the root of all evil.
@MSAlters: Bell labs is een leuk voorbeeld trouwens: wist je dat BEA zeer sterk aan het oprukken is met real time Java voor telefooncentrales, en dit zelfs als hun nieuwe strategische markt op de afgelopen JavaOne presenteerde? maar we moeten effectief 99.99% kunnen draaien (is overigens veel meer een operationeel probleem dan een technisch probleem). <64kb, heb je eens op je mobiel gekeken waar die domme mobile games in geschreven worden van 40kb?. De getallen die je noemt zijn zaken waar Java zich prima in kan vinden. Dat je het later weer over duurtijd en deployed units hebt: ook hier laten managed omgevingen juist voordelen zien. Ik zou echt niet weten hoe deze getallen argumenten zijn voor een voorgecompileerde applicatie.
De math performance van Java is trouwens echt niet zo dramatisch, de meeste micro-benches geven aan dat er nu al redelijk dicht bij C++ wordt gescoord, en kijk maar eens naar het pioniers werk van BEA met JRockit en real time enterprise Java. Wel frappant hoe je kunt inschatten hoe een totaal onbekend stuk code in VBA te langzaam is en Java 5 minuten moet kosten. Wie weet kan dit stukje code zelfs in VBA al worden herschreven naar iets wat 100 ms duurt, mits het bovengenoemde gezonde verstand wordt gebruikt.
@.oisyn: En Hobbit: Python en Ruby zijn ook JIT omgevingen, in deze discussie zou je dus ze kunnen scharen onder dezelfde groep als Java/.NET.
Het schrijven van snelle managed code vereist oefening, ervaring en inzicht: maar wel op punten andere detailkennis dan bijvoorbeeld voorgecompileerde omgevingen. In managed omgevingen zijn allocaties niet altijd evil, en sommige details zijn veel sneller of juist veel trager dan in een unmanaged omgeving. Voor de rest bedoelen we hetzelfde: gezond verstand is de beste performance boost. Als je niet weet wat je doet wordt het altijd traag, of je nu assembler of VBA gebruikt.
Ik zal het er maar op houden dat mijn eerste reactie met iets te veel optimalisaties gelezen werd en er slechts "taal C/C++ is traag" uitkwam oid.
Nog meer tegeltjeswijsheid: premature optimisation is the root of all evil. @MSAlters:
Natuurlijk kan een andere memory manager ook dingen verplaatsen en op die memory fragmentatie oplossen. Het voordeel dat een garbage collector heeft is dat het meerdere technieken kan gebruiken om te voorkomen dat memory fragmentatie optreedt. Het principe van generationele gc's bijvoorbeeld maakt gebruik van de kennis die de gc over lifetime van objecten om aparte gebieden te maken voor long-lived en short-lived objecten. Hetzelfde geldt voor localiteit van geheugen. Een gc heeft meer context.
Nogmaals ik zet hier even twee concepten tegenover elkaar, "goede kans zus en zo" is slechts een argument voor de dagelijkse praktijk. In dit geval zal ik je gerust stellen: Java en .NET weten heus wel hoeveel CPU's er zijn, ook op andere platforms dan Wintel. Wie zegt overigens niet dat de JIT compiler/GC uiteindelijk gewoon de OS allocator zou kunnen gebruiken voor een deel van haar taken? Ik zeg alleen dat de JIT meer kan doen met die extra context informatie over zowel omgeving als (nog te executeren) code.Pardon? Je denkt dat een VM garbage collector beter kan werken dan de typische OS allocator? Goede kans dat de VM niet eens weet hoeveel CPUs er zijn (OK, op x86/Windows is dat meestal wel het geval
Mijn opmerking was niet bedoeld om te bewijzen dat C++ traag is, maar om aan te geven dat ervaring en volwassenheid van het platform bepalend kan zijn voor de uiteindelijke perceptie van de performance ervan. Je kunt nu al in sommige gevallen zeggen dat de Java JIT compiler ongeveer even snelle code als een C++ compiler produceert, en soms sneller. Er zijn ook benchmarks op internet te vinden die dit laten zien (alhoewel die net zo goed biased zijn als claims van het C++ compiler team lol). Dat beeld zal in de komende jaren steeds verder verschuiven in het voordeel van managed omgevingen, door de inherente voordelen die ik opnoemde. Dat je ook nog eens robuuster, sneller, makkelijker en flexibeler code kunt schrijven is natuurlijk bijzaak in deze performance discussie.
Bell labs is een leuk voorbeeld trouwens: wist je dat BEA zeer sterk aan het oprukken is met real time Java voor telefooncentrales, en dit zelfs als hun nieuwe strategische markt op de afgelopen JavaOne presenteerde?Ik werk nu bij een zorgverzekeraar met Java, datasets van een paar 100 gigabytes, duizenden online gebruikers. Voor een beschikbaarheid meer dan >24uur per dag gaan we niet,
maar we moeten effectief 99.99% kunnen draaien (is overigens veel meer een operationeel probleem dan een technisch probleem). <64kb, heb je eens op je mobiel gekeken waar die domme mobile games in geschreven worden van 40kb?. De getallen die je noemt zijn zaken waar Java zich prima in kan vinden. Dat je het later weer over duurtijd en deployed units hebt: ook hier laten managed omgevingen juist voordelen zien. Ik zou echt niet weten hoe deze getallen argumenten zijn voor een voorgecompileerde applicatie.De math performance van Java is trouwens echt niet zo dramatisch, de meeste micro-benches geven aan dat er nu al redelijk dicht bij C++ wordt gescoord, en kijk maar eens naar het pioniers werk van BEA met JRockit en real time enterprise Java. Wel frappant hoe je kunt inschatten hoe een totaal onbekend stuk code in VBA te langzaam is en Java 5 minuten moet kosten. Wie weet kan dit stukje code zelfs in VBA al worden herschreven naar iets wat 100 ms duurt, mits het bovengenoemde gezonde verstand wordt gebruikt.
@.oisyn:
Ik gebruik Java, .NET en C/C++ dus als praktijkvoorbeelden. Zoals ik bovenin al aanhaalde gebruikte ik in mijn eerste post over performance al meer dan één zin om dit toe te lichten, waardoor helaas de onvolledige quote enigszins uit het verband wordt gerukt. Natuurlijk kan C++ ook in een VM draaien, en heeft dan net zo goed de potentie om nog veel sneller te zijn dan voorgecompileerde C++.Toch heb je het steeds over JIT vs. C/C++. Waarom zou C/C++ niet in een managed omgeving kunnen draaien? Het is natuurlijk niet impliciet dat een C++ app altijd direct naar native code hoeft te compilen. Ik reageerde dan ook puur op Java vs. C++: Java heeft imho te weinig features om ooit de vloer aan te kunnen vegen met C++, of dat nou native of JITed is. En dát was de essentie van mijn post, niet VM vs. native, ook al is de tendens dat Java in een VM draait en C++ naar native machinecode gecompileerd wordt
En Hobbit: Python en Ruby zijn ook JIT omgevingen, in deze discussie zou je dus ze kunnen scharen onder dezelfde groep als Java/.NET.Dat is dus het mooie van een JIT compiler, die weet welke code er uitgevoerd gaat worden, en kan dus anders optimaliseren zodra reflection wordt toegepast. Zie bijvoorbeeld de voodoo magic die toegepast wordt voor het gebruik van lokale variabelen in anonieme klasses/delegates. Objecten die normaal op de stack zouden worden gemaakt worden dan ineens op de heap gezet.
Dat is precies wat ik bedoel: het imago van JIT omgevingen loopt achter op de huidige realiteit. Niet openstaan voor de toekomstige shift en potentie van dit verschil in uitvoeren van code zou ik zeker onverstandig vinden. Ik zal zeker niet zeggen dat Java nu C++ op alle fronten owned en C++ is zeker nu nog de betere keus voor het ontwikkelen van games. Er is zeker een toekomstbeeld waarin dit wel het geval zal zijn (net zoals C++ nu op sommige punten sneller kan zijn dan C, zoals MSAlters aangeeft).Nou praat je echter over een hele tijd terug, de reden dat gamedevelopers C++ schuwen is over het algemeen nooit feitelijk snelheid geweest, maar meer het "langzame" imago dat C++ nog had van vroeger en het feit dat gamedevelopers over het algemeen verstokte programmeurs zijn die niet snel iets nieuws zullen ontarmen of iets nieuws aan willen leren
Het schrijven van snelle managed code vereist oefening, ervaring en inzicht: maar wel op punten andere detailkennis dan bijvoorbeeld voorgecompileerde omgevingen. In managed omgevingen zijn allocaties niet altijd evil, en sommige details zijn veel sneller of juist veel trager dan in een unmanaged omgeving. Voor de rest bedoelen we hetzelfde: gezond verstand is de beste performance boost. Als je niet weet wat je doet wordt het altijd traag, of je nu assembler of VBA gebruikt.
I don't blame him for that tbh:
De math performance van Java is trouwens echt niet zo dramatisch, de meeste micro-benches geven aan dat er nu al redelijk dicht bij C++ wordt gescoord, en kijk maar eens naar het pioniers werk van BEA met JRockit en real time enterprise Java. Wel frappant hoe je kunt inschatten hoe een totaal onbekend stuk code in VBA te langzaam is en Java 5 minuten moet kosten. Wie weet kan dit stukje code zelfs in VBA al worden herschreven naar iets wat 100 ms duurt, mits het bovengenoemde gezonde verstand wordt gebruikt.
Ik denk dat de kerel die het geschreven heeft (mijn interne stagebegeleider) et stuk in VBA wel niet in zo'n mate zal verwaarloosd hebben, dat et 150 maal sneller kan
als'k me niet vergis is VBA volledig geinterpreteerd ? dus als je die factor al wegneemt kun je denk ik wel minstens een verdubbeling in snelheid halen... nuja. Als het stuk geschreven is (door mij dan) en de resultaten zijn relevant, dan kan'k ze nog altijd hier posten
ASSUME makes an ASS out of U and ME
/u/92525/me.png?f=community)
It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.
ik weet het niet, te complex en te foutgevoelig zouden immers ook voor andere gebieden gelden. In zijn totaal gezien wordt C++ nog steeds meer gebruikt dan Java. Verder, wat is foutgevoeliger? Wat is complex?
Simpel voorbeeld: in C++ kan ik mijn functies default parameters meegeven. Waarom kan dit niet in Java? Waarom moet ik in Java voor elke default parameter een aparte functie schrijven die telkens de functie met 1 default parameter minder aanroept tot ze op het laatst allemaal bij elkaar komen. Is dat niet complex? Is dat niet foutgevoelig?
Ten tijde dat de web apps in opkomst kwamen moest ik in Java *altijd* als ik iets uit een collection wilde halen casten. Dat is toch niet normaal? Waarom moest dat eigenlijk??? Is dat dan niet complex en foutgevoelig? Zeker als ik ingewikeldere types had, moest ik telkens de plekken opzoeken in mijn code waar ik wat in de collection stopte om het type te achterhalen. Als dat zelf ook weer een collection was, moest ik die ook weer opzoeken. Nu hebben ze dat recent gefixed in Java, maar het spreekt niet echt voor Sun om die bug 8 jaar in Java te laten zitten.
En nu hebben ze het gefixed, maar zijn ze weer vergeten typedefs in te voeren. Handig dat je telkens dingen mag schrijven als
Java:
1
2
3
4
5
6
| HashMap< String, HashMap< String, ArrayList<Integer>>> createMap() { HashMap< String, HashMap< String, ArrayList<Integer>>> myMap = new HashMap< String, HashMap< String, ArrayList<Integer>>>; // do something with map return myMap; } |
In C++ maak je hier gewoon een makkelijke typedef voor en gebruik je die.
Hoezo complexiteit?
Maar goed, andere dingen in Java zijn wel makkelijker. Enums en variable argumenten zijn echt beter gedaan in Java. In C++ zijn enums niet typesafe en kunnen veel problemen geven. Mijn persoonlijke favoriet in Java is dat classes automatisch in een namespace komen. In C++ moet je met ouderwetse headers werken die letterlijk in je source file gepaste worden. Daarbij moet je nog handmatig constructies zetten om te voorkomen dat je header meerdere keren ge-include wordt.
Mischien dat er hier een expert is die nog een voordeel kan zien in de header werkwijze, maar als iemand die jarenlang in C++ geprogrammeerd heeft kan ik uit ervaring zeggen dat headers redelijk zuigen.
Dat is ook een enorm groot voordeel ja, maar dat is niet direct aan de taal (of het concept van de taal) zelf te danken. Tenzij het dus inderdaad zo is dat C++ door enkel en alleen het address space model inderdaad niet geschikt is voor web applicaties.
Trouwens, nog een potentieel performance voordeel van C++ wat ik nog niet het gezien in deze thread is de keuze van de programmeur om een method wel of niet virtual te maken. In Java heb je die keuze niet, een functie is altijd virtual (late binding).
[ Voor 8% gewijzigd door flowerp op 06-08-2005 17:22 ]
It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.
C++ is zeker complexer dan java (je hebt tenslotte veel meer bewegingsruimte.
Doordat het complexer is, en doordat c++ geen gc heeft en doordat je moet pointers kan pielen, is c++ gewoon veel foutgevoeliger dan een taal waabij het niet kan. Vergelijk het met een versnellingsbak vs een automaat. Iemand die met een automaat rijd kan zijn versnellingsbak niet kapot maken, maar je moet van een automaat niet verwachten dat hij een auto met een versnellingsbak eruit zal rijden.
Complex is alles waar een simpeler alternatief voor is
Mee eens.. Maar dit is een uitzondering. C++ heeft zoveel mogelijkheden die Java niet heeft.. zoveel keuzes te maken... en bij keuzes horen fouten
Geen keuze geen fouten Het is geen bug. C++ heeft templates nodig omdat het geen object based class hierarchie heeft. Java heeft dit wel en daarom is generics (templates) noodzaak voor c++ en niet voor Java.
Maar ik ben het met je eens dat geparametriseerde types je code minder foutgevoelig maken. Maar c++ heeft dus zo veel andere mogelijkheden die Java niet heeft.
Precies. vrij foutgevoelig, maar als je hier werkt volgens een vast patroon dan is de pijn nog te overzien.
Als er geen sprake is van subclassing dan heb je geen late binding en verder is de JIT vrij intelligent. Verkijk je daar echt niet op.
[edit]
[flame mode]
*Gooit nog ff olie op het vuur*
The Java is Faster than C++ and C++ Sucks Unbiased Benchmark
[ Voor 6% gewijzigd door Alarmnummer op 06-08-2005 18:28 ]
Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein
It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.
Precies. Maar in Grand Turismo rij ik ook met een automaat
niet zoveel gezeur en minder stress..Yep. Maar je hebt dus met c++ meer kans een foute beslissingen te nemen en daardoor is het gewoon lastiger om goeie c++ developers te krijgen dan java developers. Voor vee bedrijven is het niet belangrijk dat je met je auto het snelste aankomt, als je maar binnen een acceptabele tijd binnenkomt en de kosten mbt het autorijden niet te hoog zijn. En verder kan iemand in zijn wagen nog zo goed schakelen, tegenover een veel betere auto met automaat heeft hij toch minder kans. En in de enterprise wereld geld vaak dat het goedkoper is om extra hardware bij te plaatsen dan die uren kwijt te zijn aan software ontwikkeling. Ik schrik zelf wel eens van de bedragen.. wow 5.000 euro... wacht eens even.. dat is ca 60 uur werk en dat is echt niet veel tijd. Moet je nagaan wat voor hardware je erbij kan zetten voor 5000 euro.
[ Voor 4% gewijzigd door Alarmnummer op 07-08-2005 13:19 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Tsja, dat hoor ik andere weer vaak over jou zeggen mbt java
Opzich heb je wel gelijk peter, maar over wat onduidelijk is valt natuurlijk te twisten. Als we ons alleen even beperken tot de gevaarlijke constructies in C++ dan komt dat eigenlijk maar op 2 dingen neer:
* bald pointers
* primitive array access
Waarbij opgemerk moet worden dat operator [] op een primitive array eigenlijk een afkorting is voor een pointer + offset berekening. Het gebruik van zowel primitive arrays als het gebruik van bald pointers wordt zowieso steeds meer ontmoedigd in C++ voor de 'normale' programmeur. Hiervoor in de plaats komen library containers (bv vector) en smart pointers.
Als we nu eens naar wat andere opvallende dingen kijken die verschillen (verschilde) tussen C++ en Java dan zien we oa:
enums
variable argumenten
(echte) templates
typedefs
default parameters
operator overloading
multiple inheritance
nested scoping ( {int a; { int a; } }
Value types
echte destructors
Zijn deze per definitie unsafe of onduidelijke? Zonder deze constructies maak je een taal inderdaad simpelder. Je kunt code van anderen eerder lezen want er is minder te leren.
Aan de andere kant, maakt het code opzich makkelijker? Ik denk het niet. Het niet overnemen van enums uit C++ had alleen maar tot gevolg dat iedereen rijen static final ints ging maken. Dit werkte alleen maar verwarring op. Sun heeft wel erg lang gewacht met deze aan Java toe te voegen. Je zou bijna zeggen dat ze ze express niet toevoegde om zich maar tegen C++ af te zetten terwijl daar niet echt een reden voor was. (ok, zo kinderachtig zal het wel niet zijn geweest, maar toch...)
Het zelfde geldt voor variable argumenten. Telkens een array aanmaken, vullen en meegeven werkte ook niet super. Het casting verhaal is al genoemd mbt generics.
Waarom heeft Java de typedefs niet overgenomen? Ook die maken het werken met generics veel makkelijker, terwijl het niet unsafe is.
En wat te denken van operator overloading? Werkt voor collections ( [] syntax) en Numbers veel makkelijker: je code ziet er zoveel duidelijker uit en is ook niet unsafe. Sure, het kan misbruikt worden, maar static members in Java (om maar wat te noemen) kunnen ook misbruikt worden.
Multiple inheritance is een krachtig mechanisme, wat inderdaad heel voorzichtig toegepast moet worden. Toch zie ik ook niet veel kwaad en unsafeness hierin (mits met mate en doordacht toegepast natuurlijk).
Nested scoping kan idd verwarring opleveren. Ik weet niet of het nu goed of slecht is dat java dit niet heeft.
Value types zelf zijn ook niet perse unsafe. C# heeft ze ook. De destructie ervan bij het eindigen van de stack kan een probleem zijn als er nog iemand een pointer erna heeft, maar een managed omgeving kan dan een IllegalPointerAccessException oid gooien, net zoals code nu een NPE gooit. Zeker in een managed omgeving hoeven value types dus niet unsafe te zijn. Eigenlijk valt dit nogal samen met destructors. Ook die kunnen ongeldige pointers opleveren, maar een managed omgeving kan dat opvangen zonder dat er undefined behaviour hoeft op te treden.
Als twee-talige programmeur (ik werk zowel veel in C++ als Java) zie ik dat beide talen voordelen hebben. Als Java de betere C++ wil zijn, waarom neemt het dan niet gewoon meer van de goede dingen over die helemaal geen kwaad kunnen?
It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.
Afgezien van het feit dat ik redelijk thuis ben in Java, java is gewoon een stuk eenvoudiger. Ik heb voordat ik met java begon ook het een en ander gedaan met c/c++/pascal/delphi maar bij Java was het allemaal erg simpel en er zitten gewoon minder valkuilen in de weg.:
Tsja, dat hoor ik andere weer vaak over jou zeggen mbt java
Wel meer dan dat, saskia
-soms een erg cryptische syntax. void* maakt mij geen blij man..
-nare import/header structuur
-pointer problematiek, bv formele argumenten: Gaat het Persoon worden.. of Persoon*.. of Persoon** of &Persoon
-cryptische api`s.
-duidelijke exception afhandeling in Java. In c++ is er veel mogelijk en maakt het veel lastiger te begrijpen
-operator overloading (hiermee kan je rare constructies vormen)
-geen gc (garbage collection is voor standaard toepassing nu eenmaal handig). Dat je in c++ ook op een goeie manier kan werken, twijfel ik niet aan. Maar het is niet de enigste manier om te werken.
-gebrekkige documentatie (c++ heeft niet iets vergelijkbaars zoals Javadoc)
De constructies an sich zijn niet unsafe. Maar er zijn zoveel opties. Als er minder opties zijn, kan je minder fout doen en kan je mensen sneller op 1 lijn krijgen. Ik zit ook wel eens tegen java aan te schoppen en wil ook sommige features die je terug vind in c++. Maar voor de meeste systemen die geschreven worden hoef je geen god te zijn. Gewone bedrijven maken ook gewone systemen en als ik directeur was dan had ik ook liever dat mensen met een taal werken waarin je mensen sneller op 1 lijn krijgt.
Ja und? Koopt een bedrijf toch niets voor. Wauw.. wij hebben dit en dit uitgevonden.. ja leuk.. maar we zijn wel 2 maand te laat met opleveren. Verder is de taal java vrij 'eenvoudig' maar als je alle j2ee problamtiek erbij betrekt dan trek je weer een enorme beerput met ellende open. Ik ben blij dat ik op taal nivo dan weinig problemen tegenkom bij allerlei j2ee producten. Alles wijst zich op dat nivo vanzelf.
Er zijn idd dingen die al lang in java hadden gemoeten. Maar dat wil niet zeggen dat er daarom alle missende c++ features dan maar goed zijn. C++ is een hele krachtige taal waarbij je tot in de kleinste hoekjes alles kunt configureren, maar dit op een verstandige manier toepassen vergt inzicht en veel programmeurs die hebben dat gewoon niet. Vanuit productie oogput is Java (als Java net zo goed gebruikt kan worden dan c++) een betere taal. Dito geld voor .NET. In Java en .NET kan je met normaal geschool personeel snel software uit de grond stampen.
Persoonlijk vind ik de taal niet zo bijster interessant. Ik vind alle talen ongeveer even kut en achterhaald, maar het gaat om de zaken die erbij zitten. Communities, fora, ide`s, api`s etc. Ik heb bij Java dan vaker het gevoel bij mensen te komen die denken zoals ik. .NET vind ik heel erg onduidelijk en onbegrijpelijk (ik bedoel niet de api`s en taal). En c++.. tja. ik wil ook een boterham verdienen
Ik kan in Groningen (daar woon ik) zo een aantal bedrijven opnoemen waar ze java developers nodig zijn. Ik weet geen enkel bedrijf in Groningen die c++ developers nodig heeft.
[ Voor 15% gewijzigd door Alarmnummer op 07-08-2005 19:15 ]
Terwijl het niet veel anders is dan Object.
eens
Je bedoelt Persoon&, en hier zijn vrij duidelijke afspraken over te maken.
Je doelt vast op de standaard C library, ik vind de C++ lib niet zo cryptisch eigenlijk... En de rest (neem de linux API bijvoorbeeld) is natuurlijk niet de schuld van C++.
Doxygen
Ik ook, en liefst while I'm having fun doing itEn c++.. tja. ik wil ook een boterham verdienen
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
In principe misschien wel. Maar al deze nuances maken het het complexer. Als er geen keuze is, dan is het minder complex.
Tja. Iedere developer zal zijn eigen stijl ontwikkelen en bij Java heb je mensen sneller op 1 lijn omdat er minder stijl vormen zijn. Java heeft genoeg variatie om het grootste gedeelte van de software mee te ontwikkelen (het kan dus meestal genoeg) en dat is imho een van de redenen dat het verstandiger is om Java/c# te gebruiken (voor veel projecten) dan c++.
Wiens schuld het is maakt niet uit. Het gaat erom of het in de praktijk werkbaar is. Javadoc is in Java erg strak geregeld (dito als bij .NET).
Dus ik kan van 99 van de 100 c++ projecten zo een javadoc-achtige documentatie op de site terug vinden? Bij java kan je bijna altijd dit terug vinden.Doxygen
Ik ook, maar de taal die boeit me dus niet zo, het gaat mij om de inhoud van de opdrachten en de tools waarmee ik kan werken.Ik ook, en liefst while I'm having fun doing it
[ Voor 3% gewijzigd door Alarmnummer op 08-08-2005 14:51 ]
Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein
Uhm, mijn punt was eigenlijk dat een runtime-optimalisatieproces meer context heeft dan een compile-time-optimalisatieproces, en daarom potentieel sneller is.
De discussie die hierna gestart wordt over de taal C++ laat ik even aan mij voorbij gaan, omdat dit op zichzelf niet zo veel met performance te maken heeft.Dat is inderdaad een reflex die je snel ziet in de Java enterprise wereld: knal er maar meer hardware tegenaan, want dat is goedkoper. Ik ben echter zelf van mening dat een beetje profilen en code-optimalisaties best 20.000 euro mogen kosten als je hiermee 5.000 euro hardware uitspaart (extra hardware zal in de praktijk echter al wel snel in de de 10 duizenden of meer lopen afhankelijk van hoe groot de server is). Er wordt namelijk vaak vergeten dat 80% van de kosten voor een enterprise applicatie worden gemaakt in beheer, en niet in ontwikkeling (het feit dat dit vaak vergeten wordt zal wel een reden zijn voor dit hoge percentage).
Servers moeten beheerd worden, en dat kost geld. Bovendien wordt de topologie van je applicatie complexer, wéér een extra node in het cluster met netwerklijntjes, configuratiestores, hoe ga je om met hardware failures (misschien ook extra uitvalcapaciteit nodig), heb je nog genoeg ruimte in het serverhok, enz. Zomaar een extra server klinkt makkelijk op papier maar bijna nooit zo triviaal.
Mijn persoonlijke ervaring is dat profiling en optimaliseren van code enorme performance winsten oplevert in een relatief korte tijd. Als je die winst hebt dan kun je hiervan profiteren in de volle levensduur van je applicatie en uiteindelijk er veel meer geld mee verdienen. En dan ga je er nog vanuit dat extra hardware je probleem oplost: veel performance problemen zijn een oorzaak van een schaalbaarheidsprobleem en dan heb je zowieso niet veel aan een extra server.
Dat kan zijn. Maar de menselijke compiler die c++ developers zijn kunnen nu gewoon op low level nivo het uiterste uit de machine persen. Toen ik nog veel met mijn Prolog compiler bezig was, heb ik met de hand ook nog een hele zooi low level optimalisaties doorgevoerd die de vm gewoon niet uitvoert. Uiteindelijk is het ook een paar honderd keer zo snel gaan draaien (alhoewel de low level optimalisaties niet de grootste rol hebben gespeeld):
[...]
Uhm, mijn punt was eigenlijk dat een runtime-optimalisatieproces meer context heeft dan een compile-time-optimalisatieproces, en daarom potentieel sneller is.
Dat ligt er dus aan. Wij schrijven software dat voornamelijk draait op 1 enkele server (of meerdere service waarbij iedere server 1 of meer taken vervuld). Dus het is vrij eenvoudig om die server te upgraden/vervangen. Op dit moment hebben we nog niet veel performance problemen gehad, alhoewel ik nu wel even met een Lucene optimize probleem zit. Maar een paar bankjes geheugen erin rammen zou veel gepiel aan mijn kant besparen.
TJa.. als je nu 1 langzame of 1 snelle bak beheert.. dat maakt in principe niet uit. Het is een beetje afhankelijk van het soort hardware imho. Als je een of ander cluster moet upgraden.. kan ik me er iets bij voorstellen. Maar als het alleen reepjes geheugen bij plaatsen of eventueel een snellere bak plaatsen is, dan zie ik het probleem niet.
Als jij nu voor een paar honder euro een upgrade moet doen, of je gaat voor een paar duizend euro optimaliseren, dan zie ik daar op lange termijn geen verschil in. Het wil trouwens niet zeggen dat ik totaal niet op performance let, maar soms heb je van die problemen die gewoon beter opgelost kunnen worden door wat geheugen erin te prikken dan ingewikkelde constructies te bedenken. Eigelijk is het bedenken van ingewikkelde constructies (die vaak ontstaan door optimalisatie) nog een extra reden om hardware te upgraden. Jij weet intussen ook wel dat door optimalisatie code meestal er niet beter op wordt.
Je bent niet altijd een extra server nodig. Soms is 1 snellere service de oplossing.
[ Voor 14% gewijzigd door Alarmnummer op 09-08-2005 15:09 ]
Pagina: 1