Re: [Algorithms] Complexity of new hardware

[Darren G. <dg...@ke...>]

At 02:44 PM 4/16/2009, Gregory Junker wrote:

> > We need improvement in the languages we use, compilers, and
> > IDE/Editors; It's absurd that I am using tools/languages that have
> > been only incrementally improved in the last 10 or so years, and have
> > evolved naught with considerations from the problems we face in game
> > development.
>
>NaughtyDog tried -- you have to admit that Lisp *in theory* should be
>perfectly suited to game development: it's core design intent is list
>processing (indeed, it's the name), which arguably games *are*, and it's
>functional, which ought to be perfect for increasingly data-parallel game
>technology designs. If the syntax is just "too weird" -- that can be
>changed, while leaving the core language design intact (again, GOAL).
>
>http://www.gamasutra.com/features/20020710/white_02.htm
>
>Of course, for the past ten years we've been developing for (until recently)
>single-threaded Von Neumann architectures, so I'm not surprised the tools
>haven't changed -- they still target the same basic hardware. Until we break
>away from that processing model you're not likely to see many changes in the
>tools we use. Larrabee (driven largely by GPU design) is a step in that
>direction, but it's still (by business necessity) rooted in the x86 legacy
>that has been around for over 30 years now.

Remember-- two market categories, which might as well be called 
custom and public.  Custom is simple, if you have the means go 
nuts.  But public changes need to be considered for marketing, 
migration, ethical and user transparency impact as well.  Because of 
the huge established base for x86 PC's, I would never bemoan Intel 
favouring a bridge technology for public consumption.  That has the 
appearance of a productive decision.  Going off on a slight tangent, 
an example of an "odd" decision would be Intel shelving support for 
numerous integrated graphics chipsets still out in the wild.  That is 
surely costly for developers and customers.


>They define the difficulties in moving to something different in that
>Gamasutra article: you can't hire anyone who knows (new language X), you
>can't find middleware or tools written in it (because we've used the same
>tools and hardware for the past 30 years). Even using common higher-level
>languages such as Python, C#, Ruby, etc., those are still based on the same
>processing paradigm we use in C++...so why change when the tools, arguably
>(unless you are developing for the Wii), are actually fairly usable, and the
>middleware and libraries are so readily available?
>
>Short answer: we use C++ and its tools because it is still the best
>compromise, using multiple criteria, among all of the possible solutions.
>Granted, C++0x may change that, but luckily it's still a draft...

I don't think that there is a high-level language that is unaware of 
its linearity since this is usually considered a strength of 
simplicity for a design dialect.  In fact the current trend is that a 
language with deep first-class reflection and standard library 
integration is almost guaranteed to become a platform for researching 
new application tools and a few paradigm candidates, some of which 
are for concurrent design.  MS CLR is an obvious example of 
this.  You can quantify the boom in their own research productivity 
by the number of unique results developed with c# especially since 
.net 2.  Pure C++ development by comparison has always been fractured 
and dragging its heels as developers keep muddling around the same 
design problems over and over again.  Python has seen great research 
adoption as well, although the numbers are somewhat steadier and 
fuzzier because of the large diffuse audience.

Good point about the dangers of working in an ivory tower.  It is 
beneficial to approach research respectfully with measures of 
reservation and imagination, so that if or when a good application is 
recognized it is ready to go.  You really can't expect all research 
material to be answerable to the pragmatic concerns of a wide 
audience all the time.  On the other hand, the languages you mention 
are very pragmatic, addressing very broad concerns.


Cheers,
Darren