From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 90335BBC4 for ; Thu, 5 Mar 2009 02:25:41 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIHAH+4rknUnwcjZGdsb2JhbACCHZJPGgsDBwcPBsMDhAgG X-IronPort-AV: E=Sophos;i="4.38,304,1233529200"; d="scan'208";a="23878599" Received: from relay.ptn-ipout01.plus.net ([212.159.7.35]) by mail3-smtp-sop.national.inria.fr with ESMTP; 05 Mar 2009 02:25:40 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An4FAH+4rknUnw4R/2dsb2JhbACCHdYdhAgG Received: from pih-relay04.plus.net ([212.159.14.17]) by relay.ptn-ipout01.plus.net with ESMTP; 05 Mar 2009 01:25:40 +0000 Received: from [87.112.234.120] (helo=leper.local) by pih-relay04.plus.net with esmtp (Exim) id 1Lf2LE-0004tM-0z for caml-list@yquem.inria.fr; Thu, 05 Mar 2009 01:25:40 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] stl? Date: Thu, 5 Mar 2009 01:31:03 +0000 User-Agent: KMail/1.9.9 References: <91a2ba3e0903031340wcdc976cp52522eb35f7ccb73@mail.gmail.com> <200903042250.36421.jon@ffconsultancy.com> <49AF0C3D.2030009@naughtydog.com> In-Reply-To: <49AF0C3D.2030009@naughtydog.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903050131.03494.jon@ffconsultancy.com> X-Plusnet-Relay: 9a6b7de53e6dec8a1d2a57732fbc146d X-Spam: no; 0.00; stl:01 higher-level:01 high-level:01 high-level:01 low-level:01 allocations:01 doable:01 fine-grained:01 ocaml:01 ocaml:01 stl:01 fine-grained:01 threading:01 tpl:01 inlining:01 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