Re: [Caml-list] stl?

[Pal-Kristian Engstad <pal_engstad@naughtydog.com>]

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.
>> 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. I'm not sure that all the products in my industry 
constitutes "a tiny number" of applications. Also, bear in mind that in 
my industry, a single game comprise about 500,000-1,000,000 LOC.
>>     * 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.
>>     * 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.
>>     * 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.
>>     * 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.
>> 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.
>> 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. 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.
>   
>> In short, most high-level languages will remain used for only for toys
>> and applications where speed and resource constraints is of no concern.
>>     
>
> You cannot feasibly parallelize or manage the resources of a non-trivial 
> application in C/C++. The development cost of even attempting to do so is 
> already prohibitively high and the result would be completely unmaintainable.
>   
That depends on how skilled you are as a programmer. I'd venture to say 
that professional game programmers have exactly that skill. Now, I do 
agree that it is costly - but it is by far not "completely 
unmaintainable". It just requires a lot of discipline, care and and a 
set of good tools and libraries.

Thanks,

PKE.

-- 
Pål-Kristian Engstad (engstad@naughtydog.com), 
Lead Graphics & Engine Programmer,
Naughty Dog, Inc., 1601 Cloverfield Blvd, 6000 North,
Santa Monica, CA 90404, USA. Ph.: (310) 633-9112.

"Emacs would be a far better OS if it was shipped with 
 a halfway-decent text editor." -- Slashdot, Dec 13. 2005.