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.3 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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 37429BBD5 for ; Thu, 5 Mar 2009 00:20:37 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8BAD2brkmgISwpmWdsb2JhbACUeAEBAQEBCAsKBxGzFgmPbIJXgTEG X-IronPort-AV: E=Sophos;i="4.38,304,1233529200"; d="scan'208";a="25081500" Received: from unknown (HELO ironport01a.scea.com) ([160.33.44.41]) by mail1-smtp-roc.national.inria.fr with ESMTP; 05 Mar 2009 00:20:36 +0100 X-IronPort-AV: E=Sophos;i="4.38,304,1233561600"; d="scan'208";a="7565888" Received: from inbetweener01.scea.com ([160.33.45.195]) by ironport01a.scea.com with ESMTP; 04 Mar 2009 15:20:33 -0800 Received: from postal1-dog.naughtydog.com (intmail.naughtydog.com [10.15.0.14]) by inbetweener01.scea.com (Postfix) with ESMTP id 31ABCF06FE; Wed, 4 Mar 2009 15:20:33 -0800 (PST) Received: from [127.0.0.1] ([150.0.6.116]) by postal1-dog.naughtydog.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 15:19:17 -0800 Message-ID: <49AF0C3D.2030009@naughtydog.com> Date: Wed, 04 Mar 2009 15:18:21 -0800 From: Pal-Kristian Engstad User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Jon Harrop , "caml-list@yquem.inria.fr" Subject: Re: [Caml-list] stl? References: <91a2ba3e0903031340wcdc976cp52522eb35f7ccb73@mail.gmail.com> <8763ipypx1.fsf@aryx.cs.uiuc.edu> <49AEF7EC.2000809@naughtydog.com> <200903042250.36421.jon@ffconsultancy.com> In-Reply-To: <200903042250.36421.jon@ffconsultancy.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 04 Mar 2009 23:19:17.0632 (UTC) FILETIME=[A3E9B800:01C99D1F] X-Spam: no; 0.00; stl:01 high-level:01 high-level:01 low-level:01 allocations:01 doable:01 fine-grained:01 fine-grained:01 threading:01 tpl:01 inlining:01 inlining:01 run-time:01 non-trivial:01 pke:01 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.