On Wednesday 04 March 2009 23:18:21 Pal-Kristian Engstad wrote: > Jon Harrop wrote: > > C++'s job market share has fallen 50% in 4 years here in the UK: > > > > http://www.itjobswatch.co.uk/jobs/uk/c++.do > > Sure -- those are probably not jobs that require performance, nor have > resource constraints.
I do not believe that C++ is significantly faster or better at handling resources than higher-level languages. > >> Here are some reasons: > >> > >> * Most high-level languages decide the format of your data for you. > >> This is good for most things, but if a large part of your > >> application needs specific data layouts, then you are out of luck. > > > > That is not true for all high-level languages (e.g. .NET languages convey > > low-level data representations and XNA uses them directly) and it is a > > dominant concern for only a tiny number of applications. > > I did say most. By the way, XNA is a toy. A good toy, but a toy, > nonetheless. Note the irony that games are toys. :-) > >> * Most high-level languages can not support multiple forms of data > >> allocations. Some applications need a range of allocation > >> strategies, ranging from completely automatic (garbage collection) > >> to completely manual. > > > > C++ cannot provide efficient automatic GC. > > That's not true. We run GC on all of our game tasks. It's "manual"-ish, > but doable. If it is "manual-ish" then it is not automatic! > >> * Most high-level environments do not allow for fine-grained control > >> of computing resources, e.g. soft real-time guarantees. > > > > Many high-level languages make it easier to satisfy soft > > real-time "guarantees", e.g. incremental collection vs destructor > > avalanches. > > Call me cynical, but I simply don't buy it. I found that when porting Smoke from C++ to OCaml. The worst case performance (which was the problem) got 5x faster in OCaml because the GC did the incremental work that I never managed to get my STL allocators to do effectively. I realised I was just Greenspunning what modern languages already had and that prompted me to drop C++. > >> * Most high-level languages do not allow for C/C++ intrinsics, for > >> instance leveraging access to the SSE registers. > > > > That is easily resolved if it is not already present (which it is in Mono > > and LLVM already). > > Indeed. But then there are target specific control registers, timers, > etc. etc. Usually, these are not supported well. So C++ has legacy support for them but they change as hardware evolves and there is no reason why VMs cannot also support them. > >> * Most high-level languages do not allow for fine-grained control, > >> for instance allowing different forms of threading mechanisms. > > > > F# offers the .NET thread pool, asynchronous workflows and wait-free > > work-stealing queues from the TPL. What more do you want? :-) > > Well, first of all - something that doesn't suck performance wise. And > it is essential that it works on non-Intel platforms. F# is indeed > promising, but again - I would not use it for performance critical code > - which is about 30-50% of a game's code base. Those are quite tame requirements, IMHO. I'd recommend Cilk. > >> Of course, you can always say that you can use the foreign function > >> interface, but then you lose inlining and speed. > > > > The same is true of C/C++. You can get much better performance from > > assembler but calling assembler from C or C++ not only costs inlining and > > speed but even functionality because you have an ABI to conform to. > > This is not true. Pretty much all C++ compilers have both intrinsic and > inline assembly support. Ok but that is not specific to C++. > >> More importantly, you end up with a project with several different > >> languages. That is generally a very bad idea. > > > > A common language run-time is the right solution, not C/C++. > > That is exactly my point. It needs to be *one* language that can cover > the broad base from non-performance critical AI code to performance > critical culling, animation and physics code. A common intermediate representation shared between different front-end languages would suffice. > But the sad fact is that > there is no competitor to C++. Mind you - I *want* to have something > else - it is just not feasible. I really don't see why. For example, surely OCaml+LLVM beats C++ in every way that you have described. Moreover, something like my HLVM, which is specifically designed for high-performance computing, should make that vastly easier than C++. It even supports features like optional GC because my GC is written in my IR (and I don't want to GC my GC ;-). -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e _______________________________________________ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
