Re: [Caml-list] stl?

[Jon Harrop <jon@ffconsultancy.com>]

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