gdalgorithms-list

Re: [Algorithms] Complexity of new hardware

[Will V. <wi...@se...>]

On Mon, 20 Apr 2009 12:07:36 +1200, Adrian Bentley <ad...@gm...>  
wrote:
> _definitely_ helps.  For some, though, even running simple
> serialization code may not be fast enough.

Also good for accelerating serialiation - maintaining "POD"-ness for types  
and propogating this up the tree, so you can trim off the serialisation of  
whole branches and replace with straight reads when loading from a binary  
format.

That said, an advantage of generic reflection is that you can use the same  
data to e.g. do serialisation, or to load in blocks of memory and fixup  
pointers. In theory at least, in practice the load/save methodology tends  
to contaminate the reflection to some extent.

Will

Re: [Algorithms] Complexity of new hardware

[Jarkko L. <al...@gm...>]

IMO, a fundamental problem with this is that it's difficult to guarantee
that all the data is converted to the new format. If there happens to be
some older data out of the reach of the data conversion and you remove the
conversion code, the data gets corrupted. Overall, I just think it's an
unnecessary maintenance burden for developers to take care of something as
mundane as the data conversion.

For the final build you obviously have all the data available, thus you can
update the data to the most recent version and strip off the type
information from the data. You probably want to process the data anyway to
linearize it for DVD streaming, swap the endianess, etc.


Cheers, Jarkko


-----Original Message-----
From: Adrian Bentley [mailto:ad...@gm...] 
Sent: Monday, April 20, 2009 3:08 AM
To: Game Development Algorithms
Subject: Re: [Algorithms] Complexity of new hardware

If you can break off a script by diffing two sets of type metadata is
that hard coded?  It would be unnecessary maintenance work, unless you
want to be able to change your data and can't do it within your
framework :P.  Maybe there's a way I haven't thought of.  Every time I
look at C# serialization, I've come up with a number of things I
wouldn't be able to do very easily (rename B, break A into 2 pieces,
etc.).

I certainly hadn't thought about it from a middleware perspective, but
all middleware needs a data upgrade path between versions.  Otherwise
you get stuck in time and become another point in favor of rolling
one's own tech.

Unless I'm missing something, you can't strip off all the class/type
information unless all your data is in the final format.  At that
point, you've solved your upgrade problem.  Linearly allocating
_definitely_ helps.  For some, though, even running simple
serialization code may not be fast enough.

Cheers,
Adrian

Re: [Algorithms] Complexity of new hardware

[Alen L. <ale...@cr...>]

I am talking about dependencies between magic files causing the
generated files to be rebuilt too often.

Any change to *.myformat can cause change to *.cpp and/or *.h. Most
often you do implementation changes which impact only .cpp, and it is
possible to detect that you have nothing new to change in .h. But, can
be hard to explain this kind of "conditional" dependency to a build
system. If you leave .h as always changed, you get a lot of unneeded
recompiling.

So, parsing the header, where the header contains extra meta info you
need and generating your metadata from that, while letting the
compiler use that same header directly works better, IME.

Alen



Friday, April 17, 2009, 10:42:05 PM, you wrote:

> Do tell! Are you talking about cross dependencies between magic file<->C++?

> MSN
> -----Original Message-----
> From: Alen Ladavac [mailto:ale...@cr...]
> Sent: Friday, April 17, 2009 1:37 PM
> To: Mat Noguchi
> Cc: Game Development Algorithms; Jarkko Lempiainen
> Subject: Re[2]: [Algorithms] Complexity of new hardware

> Friday, April 17, 2009, 9:59:01 PM, Mat wrote:
>> You could always flip that around and have a to-C++ compiler.

> And get tangled in a dependency quagmire. Used that a long time ago
> and I like this direction much better.  

> Alen




-- 
Best regards,
 Alen                            mailto:ale...@cr...

Re: [Algorithms] Complexity of new hardware

[Jon W. <jw...@gm...>]

Nicholas "Indy" Ray wrote:
> I think this is a matter of hiring skilled professionals who can learn
> new languages, they already have to learn so much else at new studios,
> I don't figure it to be a large issue.
>
>   

Wouldn't that, like, cost more money than wringing code out of freshmen 
who should be grateful for having a job at all? If you changed that 
cornerstone of the starving game studio, what would be next? 
Well-defined acceptance milestones with testable pass/fail criteria? 
Pretty soon you'll be asking for the moon!

Sincerely,

jw

Re: [Algorithms] Complexity of new hardware

[Rachel B. <r....@gm...>]

> Wouldn't that, like, cost more money than wringing code out of  
> freshmen
> who should be grateful for having a job at all? If you changed that
> cornerstone of the starving game studio, what would be next?
> Well-defined acceptance milestones with testable pass/fail criteria?
> Pretty soon you'll be asking for the moon!

Even worse, it might lead to experienced people *staying* in the  
industry, thus allowing us to learn from previous failures. Now that's  
just crazy talk!

Rachel

Re: [Algorithms] Complexity of new hardware

[Alen L. <ale...@cr...>]

Saturday, April 18, 2009, 12:10:24 AM, Jarkko wrote:
> So far defining introspection straight in C++ has worked well for me, so you
> don't have to generate nor parse anything and have full arsenal of C++
> features in your use.

Interesting. So you can handle templates as well with that method?

Alen

Re: [Algorithms] Complexity of new hardware

[Jarkko L. <al...@gm...>]

Yes, it works with templates as well. I have been using it quite extensively
for all kinds of classes. If you are interested in checking out some of the
code: http://sourceforge.net/projects/spinxengine/


Cheers, Jarkko


-----Original Message-----
From: Alen Ladavac [mailto:ale...@cr...] 
Sent: Sunday, April 19, 2009 12:15 AM
To: Jarkko Lempiainen
Cc: 'Game Development Algorithms'
Subject: Re[2]: [Algorithms] Complexity of new hardware

Saturday, April 18, 2009, 12:10:24 AM, Jarkko wrote:
> So far defining introspection straight in C++ has worked well for me, so
you
> don't have to generate nor parse anything and have full arsenal of C++
> features in your use.

Interesting. So you can handle templates as well with that method?

Alen

Re: [Algorithms] Complexity of new hardware

[Will V. <wi...@se...>]

On Tue, 21 Apr 2009 04:55:20 +1200, Jon Watte <jw...@gm...> wrote:
> You can actually use some template trickery to hoist the RTTI() /
> MEMBER() parts into the struct itself.

I think that's pretty neat, but it only moves, rather than removes the  
duplication, although I can see that it's easier to verify in one place  
like that. (I also needed to add an implementation to the cpp file to  
provide storage for foo::_theInfo to get it to link under VC9.)

It also generates code-to-generate-data rather than data, which was  
something I was keen to avoid as much as possible. That said, if you  
remove the virtual base then the compiler generates pretty good code. That  
would allow you to separate the "find what type" code (one virtual call)  
 from the "interrogate type data" (no virtual calls) code.

Cheers,

Will

Re: [Algorithms] Complexity of new hardware

[Jon W. <jw...@gm...>]

Will Vale wrote:
> On Tue, 21 Apr 2009 04:55:20 +1200, Jon Watte <jw...@gm...> wrote:
>   
>> You can actually use some template trickery to hoist the RTTI() /
>> MEMBER() parts into the struct itself.
>>     
>
> I think that's pretty neat, but it only moves, rather than removes the  
> duplication, although I can see that it's easier to verify in one place  
> like that. (I also needed to add an implementation to the cpp file to  
> provide storage for foo::_theInfo to get it to link under VC9.)
>
> It also generates code-to-generate-data rather than data, which was  
> something I was keen to avoid as much as possible. That said, if you  
>   


Sorry, the _theInfo can be wrapped as a static singleton in a static 
inline function, and then it will link with VC as well.

I don't actually generate (much) code to generate data, although I 
suppose the constructors do count. It all gets run at static init AFAICT.

The edit for VC++:

  static _info<T> _theInfo;
  static inline _info<T>  &info() {
    return _theInfo;
  }

turns into:

  static inline _info<T>  &info() {
    static _info<T> _theInfo;
    return _theInfo;
  }

Toggling two lines can make all the difference in the world :-)

(And I suppose I could even use the instance() template that automates 
this pattern)

Sincerely,

jw

Re: [Algorithms] Complexity of new hardware

[Pal-Kristian E. <pal...@na...>]

Gregory Junker wrote:
> 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
>   
I'll have to correct you in some of your assumptions. Goal:

    * Was imperative and not (very) functional. For instance, it didn't
      support closures.
    * Had okey (but not great) object-oriented support.
    * Had good introspection qualities (except where you didn't need to
      have it).
    * Had an excellent macro processor, corresponding to Lisp.
    * Had excellent support for fibers.
    * Made use of the REPL style of programming, including on-line
      updates of code and data.
    * Was an excellent assembler, since you had register scope as well
      as access to macros and direct access to "high-level" data types.
    * Was quite a poor code generator (but it didn't matter because of
      the above).
    * Had no visual debugger, but the REPL and on-line updates usually
      negated the need for one.

Goal was a great system - one that we still greatly miss. If we had to 
make a Goal2, then we'd probably:

    * Use an SML-ish or Scala-ish surface syntax, while trying to retain
      the power of Lisp macros.
    * Introduce stronger typing features, which is difficult, given the
      need for REPL and hot updates.
    * Do more in terms of high-level optimization, though LLVM might
      negate the need for some of that.
    * Go towards a more functional style, especially due to current
      generation hardware's need for concurrency.

Before anyone jumps up and down, no - we're probably never going to get 
around doing this. We simply don't have the time to spend too much 
effort on such an en devour.

Thanks,

PKE.

-- 
Pål-Kristian Engstad (en...@na...), 
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.

Re: [Algorithms] Complexity of new hardware

[Sam M. <sam...@ge...>]

Here's a fairly crazy idea, but I'd like to put it out there anyway: Is there a middleware market for something like GOAL?

 

Frankly, I have no idea whether it could make money - I'm not interested in worrying about this at the moment (and it's off topic). But I am interested in finding out whether the industry would actually be interesting in adopting one or more domain-specific languages in games development?

 

As an example, I've been particularly impressed by Haskell. It's a pure, strictly-typed "lazy" functional language and looks like a good fit in many ways. I won't rattle on about how cool it is here, but suffice to say I think it warrants some attention. The slightly iffy state of its C compatibility currently lets it down (IMHO), but I think some sort of "Haskell for games dev" project/compiler/code generator is a not totally insane idea.

 

Any thoughts?

 

Cheers,

Sam

 

From: Pal-Kristian Engstad [mailto:pal...@na...] 
Sent: 21 April 2009 20:44
To: Game Development Algorithms
Subject: Re: [Algorithms] Complexity of new hardware

 

Gregory Junker wrote: 

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
  

I'll have to correct you in some of your assumptions. Goal:

*	Was imperative and not (very) functional. For instance, it didn't support closures.
*	Had okey (but not great) object-oriented support.
*	Had good introspection qualities (except where you didn't need to have it).
*	Had an excellent macro processor, corresponding to Lisp.
*	Had excellent support for fibers.
*	Made use of the REPL style of programming, including on-line updates of code and data.
*	Was an excellent assembler, since you had register scope as well as access to macros and direct access to "high-level" data types.
*	Was quite a poor code generator (but it didn't matter because of the above).
*	Had no visual debugger, but the REPL and on-line updates usually negated the need for one.

Goal was a great system - one that we still greatly miss. If we had to make a Goal2, then we'd probably:

*	Use an SML-ish or Scala-ish surface syntax, while trying to retain the power of Lisp macros.
*	Introduce stronger typing features, which is difficult, given the need for REPL and hot updates.
*	Do more in terms of high-level optimization, though LLVM might negate the need for some of that.
*	Go towards a more functional style, especially due to current generation hardware's need for concurrency.

Before anyone jumps up and down, no - we're probably never going to get around doing this. We simply don't have the time to spend too much effort on such an en devour. 

Thanks,

PKE.



-- 
Pål-Kristian Engstad (en...@na...), 
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.
 

Re: [Algorithms] Complexity of new hardware

[Andrew V. <and...@ni...>]

Yes, I think there is.
But I think you'd be competing with (possibly lower-level) scripting
languages rather than engine level C/C++. Not that that's necessarily a bad
thing.
Of course, if you could get a language that interfaced correctly and
completely with all the existing SDKs on all platforms and you could use it
to write/generate code that ran in comparable time to equivalent C then it
could be a valid replacement for everything. But I reckon a script-style
language is a more feasible goal to start with.
 
There definitely needs to be a change to the way most games are written when
considering new hardware. It's perfectly possible that a new/different
language might be a good way to go - however, I'd be concerned that it would
introduce more complexity, i.e. if you already expect people to change the
way they program, is it too much to expect them to do so while also learning
a completely new language?
Maybe not - maybe the language can help the process?
 
Cheers,
Andrew.


  _____  

From: Sam Martin [mailto:sam...@ge...] 
Sent: 22 April 2009 11:05
To: Game Development Algorithms
Subject: Re: [Algorithms] Complexity of new hardware



Here’s a fairly crazy idea, but I’d like to put it out there anyway: Is
there a middleware market for something like GOAL?

 

Frankly, I have no idea whether it could make money - I’m not interested in
worrying about this at the moment (and it’s off topic). But I am interested
in finding out whether the industry would actually be interesting in
adopting one or more domain-specific languages in games development?

 

As an example, I’ve been particularly impressed by Haskell. It’s a pure,
strictly-typed “lazy” functional language and looks like a good fit in many
ways. I won’t rattle on about how cool it is here, but suffice to say I
think it warrants some attention. The slightly iffy state of its C
compatibility currently lets it down (IMHO), but I think some sort of
“Haskell for games dev” project/compiler/code generator is a not totally
insane idea.

 

Any thoughts?

 

Cheers,

Sam

 

From: Pal-Kristian Engstad [mailto:pal...@na...] 
Sent: 21 April 2009 20:44
To: Game Development Algorithms
Subject: Re: [Algorithms] Complexity of new hardware

 

Gregory Junker wrote: 

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
  

I'll have to correct you in some of your assumptions. Goal:

*	Was imperative and not (very) functional. For instance, it didn't
support closures. 

*	Had okey (but not great) object-oriented support. 

*	Had good introspection qualities (except where you didn't need to
have it). 

*	Had an excellent macro processor, corresponding to Lisp. 

*	Had excellent support for fibers. 

*	Made use of the REPL style of programming, including on-line updates
of code and data. 

*	Was an excellent assembler, since you had register scope as well as
access to macros and direct access to "high-level" data types. 

*	Was quite a poor code generator (but it didn't matter because of the
above). 

*	Had no visual debugger, but the REPL and on-line updates usually
negated the need for one. 

Goal was a great system - one that we still greatly miss. If we had to make
a Goal2, then we'd probably:

*	Use an SML-ish or Scala-ish surface syntax, while trying to retain
the power of Lisp macros. 

*	Introduce stronger typing features, which is difficult, given the
need for REPL and hot updates. 

*	Do more in terms of high-level optimization, though LLVM might
negate the need for some of that. 

*	Go towards a more functional style, especially due to current
generation hardware's need for concurrency. 

Before anyone jumps up and down, no - we're probably never going to get
around doing this. We simply don't have the time to spend too much effort on
such an en devour. 

Thanks,

PKE.



-- 
Pål-Kristian Engstad (en...@na...), 
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.
 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

Re: [Algorithms] Complexity of new hardware

[Jon W. <jw...@gm...>]

Andrew Vidler wrote:
> Yes, I think there is.
> But I think you'd be competing with (possibly lower-level) scripting 
> languages rather than engine level C/C++. Not that that's necessarily 
> a bad thing.

Wouldn't that be a tough sell? You'd already be competing with free 
implementations of LUA, Python, JavaScript and their ilk on the low end, 
and built-in languages like UnrealScript on the high end. While 
middleware for something like mesh exporting and animation (Granny) or 
something like networking or AI make sense, because there is no good 
free library for those areas, the scripting language market seems full 
of entrenched competitors with a zero dollar price point.

>
> There definitely needs to be a change to the way most games are 
> written when considering new hardware. It's perfectly possible that a 
> new/different language might be a good way to go - however, I'd be 
> concerned that it would introduce more complexity, i.e.

Doesn't this bring us back full circle? I recall a statement from a 
month ago saying that we all need to think differently about how we put 
together massively parallel software, because the current tools don't 
really help us in the right ways... That's not just games, mind you, but 
business software is often less performance critical, and server 
software already has a reasonable parallelization strategy with data and 
service federation (and 800-way CPU boxes like those from Azul...).

Sincerely,

jw

Re: [Algorithms] Complexity of new hardware

[Marc B. R. <mar...@or...>]

IMHO the best solution is multiple HL languages that frontend compile into a
common high-level IR. 
 
I like functional languages, but most worldbuilders/scripters should
(virtually) never need to write in one. 

Re: [Algorithms] Complexity of new hardware

[Gregory J. <gj...@da...>]

CLR, in other words.  ;)

 

  _____  

From: Marc B. Reynolds [mailto:mar...@or...] 
Sent: Wednesday, April 22, 2009 4:56 AM
To: 'Game Development Algorithms'
Subject: Re: [Algorithms] Complexity of new hardware

 

IMHO the best solution is multiple HL languages that frontend compile into a
common high-level IR. 

 

I like functional languages, but most worldbuilders/scripters should
(virtually) never need to write in one. 

Re: [Algorithms] Complexity of new hardware

[Marc B. R. <mar...@or...>]

 > CLR, in other words.  ;) 
 
I said a high level IR, not FORTH! 

Re: [Algorithms] Complexity of new hardware

[Alen L. <ale...@cr...>]

Just that the safest bet for the common representation is C++. It already compiles to high-performance code on all platforms. :p

Alen

Gregory wrote at 4/22/2009:


CLR, in other words.  ;)
 

From: Marc B. Reynolds [mailto:mar...@or...] 
Sent: Wednesday, April 22, 2009 4:56 AM
To: 'Game Development Algorithms'
Subject: Re: [Algorithms] Complexity of new hardware
 
IMHO the best solution is multiple HL languages that frontend compile into a common high-level IR. 
 
I like functional languages, but most worldbuilders/scripters should (virtually) never need to write in one. 





-- 
Alen

Re: [Algorithms] Complexity of new hardware

[Sam M. <sam...@ge...>]

Exactly - C/C++ is an excellent target format.

Haskell already compiles 'via-c'. I'd be looking at targeting any domain
specific language at generating C/C++, not assembly. This would also
greatly ease interoperability with other C/C++ which (as previously
discussed on this list) is absolutely essential.

I note that generating C/C++ doesn't mean you can't run your DSL in an
interpreted mode for fast development/debugging. I'd expect the tight
control over side effects in functional languages to aid this.

Ta,
Sam

-----Original Message-----
From: Alen Ladavac [mailto:ale...@cr...] 
Sent: 22 April 2009 16:35
To: Gregory Junker
Cc: 'Game Development Algorithms'
Subject: Re: [Algorithms] Complexity of new hardware

Just that the safest bet for the common representation is C++. It
already compiles to high-performance code on all platforms. :p

Alen

Gregory wrote at 4/22/2009:


CLR, in other words.  ;)
 

From: Marc B. Reynolds [mailto:mar...@or...] 
Sent: Wednesday, April 22, 2009 4:56 AM
To: 'Game Development Algorithms'
Subject: Re: [Algorithms] Complexity of new hardware
 
IMHO the best solution is multiple HL languages that frontend compile
into a common high-level IR. 
 
I like functional languages, but most worldbuilders/scripters should
(virtually) never need to write in one. 





-- 
Alen


------------------------------------------------------------------------
------
Stay on top of everything new and different, both inside and 
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today. 
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-lis
t

Re: [Algorithms] Complexity of new hardware

[Marc B. R. <mar...@or...>]

How the backend is handled is irrelevant to what I was attempting to say,
which is basically I don't believe in any "fits-all" languages.


-----Original Message-----
From: Sam Martin [mailto:sam...@ge...] 
Sent: Wednesday, April 22, 2009 5:59 PM
To: Alen Ladavac; Game Development Algorithms; Gregory Junker
Subject: Re: [Algorithms] Complexity of new hardware


Exactly - C/C++ is an excellent target format.

Haskell already compiles 'via-c'. I'd be looking at targeting any domain
specific language at generating C/C++, not assembly. This would also greatly
ease interoperability with other C/C++ which (as previously discussed on
this list) is absolutely essential.

I note that generating C/C++ doesn't mean you can't run your DSL in an
interpreted mode for fast development/debugging. I'd expect the tight
control over side effects in functional languages to aid this.

Ta,
Sam

-----Original Message-----
From: Alen Ladavac [mailto:ale...@cr...] 
Sent: 22 April 2009 16:35
To: Gregory Junker
Cc: 'Game Development Algorithms'
Subject: Re: [Algorithms] Complexity of new hardware

Just that the safest bet for the common representation is C++. It already
compiles to high-performance code on all platforms. :p

Alen

Gregory wrote at 4/22/2009:


CLR, in other words.  ;)
 

From: Marc B. Reynolds [mailto:mar...@or...] 
Sent: Wednesday, April 22, 2009 4:56 AM
To: 'Game Development Algorithms'
Subject: Re: [Algorithms] Complexity of new hardware
 
IMHO the best solution is multiple HL languages that frontend compile into a
common high-level IR. 
 
I like functional languages, but most worldbuilders/scripters should
(virtually) never need to write in one. 





-- 
Alen


------------------------------------------------------------------------
------
Stay on top of everything new and different, both inside and 
around Java (TM) technology - register by April 22, and save $200 on the
JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical
and hands-on sessions. Register today. 
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
GDAlgorithms-list mailing list GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-lis
t

----------------------------------------------------------------------------
--
Stay on top of everything new and different, both inside and 
around Java (TM) technology - register by April 22, and save $200 on the
JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical
and hands-on sessions. Register today. 
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
GDAlgorithms-list mailing list GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list

Re: [Algorithms] Complexity of new hardware

[Rachel B. <r....@gm...>]

> Exactly - C/C++ is an excellent target format.

Maybe, possibly, C is a decent target format. C++, for all intents and  
purposes, is a dinosaur in an evolutionary dead end. The compile times  
are completely unacceptable for what it gives you.

It might be worth considering a VM as your intermediate target instead.


> Haskell already compiles 'via-c'. I'd be looking at targeting any  
> domain
> specific language at generating C/C++, not assembly.

In turn extending your compile times... which is really not that high  
on my list of priorities. Writing a front end for your DSL that works  
with e.g. LLVM seems like the better choice, if you *have* to write  
your own DSL compiler.

> I note that generating C/C++ doesn't mean you can't run your DSL in an
> interpreted mode for fast development/debugging. I'd expect the tight
> control over side effects in functional languages to aid this.

Ultimately, that's the first step into a model of "calcifying"[1]  
software. You start with an extremely malleable language, and it  
gradually hardens over time. (By compiling, providing annotations to  
the compiler, etc...)

Haskell seems to be the farthest along that way, for now.  If there  
are any other recommendations, I'd love to hear them.

Rachel

[1] My own terminology. If there's a commonly agreed upon term, please  
let me know. (And if there's any *research* in that area, doubly so!).  
Thanks in advance!

Re: [Algorithms] Complexity of new hardware

[Nicholas \Indy\ R. <ar...@gm...>]

On Sat, Apr 25, 2009 at 2:53 PM, Rachel Blum <r....@gm...> wrote:
> In turn extending your compile times... which is really not that high on my
> list of priorities. Writing a front end for your DSL that works with e.g.
> LLVM seems like the better choice, if you *have* to write your own DSL
> compiler.

I've found LLVM is a great compiler backend, and a pleasure to work
with. I've only found a handful of cases where compiling to LLVM IR is
more difficult then to C, and I feel there are an equivalent amount of
circumstances where the opposite is true. It's particularly
pleasurably using the C++ API.

> Ultimately, that's the first step into a model of "calcifying"[1] software.
> You start with an extremely malleable language, and it gradually hardens
> over time. (By compiling, providing annotations to the compiler, etc...)
>
> Haskell seems to be the farthest along that way, for now.  If there are any
> other recommendations, I'd love to hear them.

It seems to me that you are only referring to the advantages of Type
Inference in haskell, as other then that most software will "calcify"
to a degree, however I do agree that type inference can be a very nice
feature in a language, and helps to keep the whole application stable
as it enlarges. But with that in mind I feel that the family of ML
languages are also very suitable, and eager evaluation seems better
suited for game development.

> As far as I'm concerned, C++ is nearing a breaking point. We constantly cram
> new features into it (sorry, I meant "we extend the number of supported
> paradigms" ;), and design is by committee. Which leads to an extremely
> powerful and overly complex language that's almost unreadable. On top of
> that, the tool set is falling more and more behind.

As I mentioned, C++ was not designed for making games, it's very
suitable systems language, and for many systems in game development, I
do find it enjoyable, however it starts to break down while combining
systems into a large application, and additionally leads to a lot of
repeated and glue code, which is often ad-hoc and bug-ridden. That
combined with the very poor toolset makes it less then ideal to write
entire games in.

> At least for private projects, I've almost completely abandoned it - work
> has a slightly higher inertia ;)

I don't know if you're private projects are game related. But at the
moment there seems to be a much bigger issue then inertia in the work
environment, which is the lack of a viable alternative in our field.

Nicholas "Indy" Ray

Re: [Algorithms] Complexity of new hardware

[Gribb, G. <gg...@ra...>]

>As I mentioned, C++ was not designed for making games, it's very
suitable systems language, and for many systems in game development, I
do find it enjoyable, however it starts to break down while combining
systems into a large application, and additionally leads to a lot of
repeated and glue code, which is often ad-hoc and bug-ridden. That
combined with the very poor toolset makes it less then ideal to write
entire games in.


Seem like the death of C/C++ has been proclaimed for at least 20 years. As game developers, for say at least the last 12 years or so, we have done lots of work with scripting languages of all sorts. Outside of the game proper, we use all tools available including really high level stuff like commercial databases. So it isn't like game developer are just oblivious to language technology.
 
But if we are talking about big-budget commercial games, and we are talking about the runtime code, the stuff that actually executes on the 360 or PS3, then the death of C++ is greatly exadgerated. Game developers find sucess with C/C++.
 
The proposed benefits of highler level languages strike me as nieve and theoretical. In practice those benefits don't materialize, in my experience anyway. It isn't clear to me if those lobbying for change are saying "we had a really tough time with C++ on our last game, so we are going to try something different next time", or "we switched to language X for our development last game and saw real benefits".  It would be nice to hear more about practical experience, rather than dubious theory.
 
Let me just pick on one thing today: Garbage collection. Having made big-budget commercial games both with and without garbage collection, in my experience, these are myths:
 
Myth: C++ does not "support" garbage collection.
Myth: Garbage collection saves development time. 
Myth: Garbage collection reduces bugs.
 
To me, "ownership and lifetime" is an important concept in software engineering.  When is something created, when is it destroyed and what higher level object is accountable for it? Garbage collection offers ONE answer to the question of ownership and lifetime: Everyone referencing something share ownership and the lifetime lasts until it can't be referred to anymore.
 
I feel that having only one answer to the ownership and lifetime question is very limiting on expressive power. In many cases, a different approach to ownership and lifetime will give you a superior design. We sure don't want to live with inferior designs because the language has a dogmatic and limiting view of ownership and lifetime.
 
As far as development time and bugs, well in my experience a garbage collection system just gives you different sorts of bugs. With garbage collection, you will spend your debugging time trying to understand what link in super complex dependency chain is problematic, and even when it is identified you are left with only hacky approaches to breaking the undesirable links. Realize that with a console game, an object that does not get destroyed soon enough is just as fatal as an object that gets destroyed too soon, except the former is much harder to track down and fix.
 
In the end using garbage collection isn't a huge problem; I'm satisfied with the products I've made that use GC. But I will say that whoever thinks garbage collection offer significant benefits to game development doesn't seem to be facing or solving the same problems that I confront.
 
-Gil 
 
 
 

Re: [Algorithms] Complexity of new hardware

[Sebastian S. <seb...@gm...>]

On Sun, Apr 26, 2009 at 3:10 PM, Gribb, Gil <gg...@ra...> wrote:
>
> Seem like the death of C/C++ has been proclaimed for at least 20 years. As
> game developers, for say at least the last 12 years or so, we have done lots
> of work with scripting languages of all sorts. Outside of the game proper,
> we use all tools available including really high level stuff like commercial
> databases. So it isn't like game developer are just oblivious to language
> technology.
>

I don't think the death has been proclaimed or even predicted, merely wished
for :-)


> To me, "ownership and lifetime" is an important concept in software
> engineering.  When is something created, when is it destroyed and what
> higher level object is accountable for it? Garbage collection offers ONE
> answer to the question of ownership and lifetime: Everyone referencing
> something share ownership and the lifetime lasts until it can't be referred
> to anymore.
>

You don't say which language you're referring to, but there is nothing about
garbage collection that excludes all other forms of resource management from
co-existing with it. At worst you may need to live with the memory being
"backed" by garbage collection at the bottom (though most "full blown"
languages offer an escape hatch), but you could usually just allocate a big
block (that's garbage collected) and portion it out manually from there.
There's no reason why you couldn't use RAII or even manual resource
management in many high level languages that also have garbage collection.

However, I'd wager that the vast majority of allocations are not special
enough to need manual care, having a built in efficient system for
automatically dealing with it in a way which is guaranteed to never corrupt
the heap is jolly convenient.

Also, not having to worry about memory fragmentation over time is pretty
sweet too. That's definitely an issue a lot of people spend a lot of
engineering effort to work around.


>
> As far as development time and bugs, well in my experience a garbage
> collection system just gives you different sorts of bugs. With garbage
> collection, you will spend your debugging time trying to understand what
> link in super complex dependency chain is problematic, and even when it is
> identified you are left with only hacky approaches to breaking the
> undesirable links. Realize that with a console game, an object that does
> not get destroyed soon enough is just as fatal as an object that gets
> destroyed too soon, except the former is much harder to track down and fix.
>

This would happen in a system with automatic memory management too, except
rather than getting bloated memory with a nice heap you could inspect using
a variety of tools to find the unwanted reference, you get a bunch of stale
pointers to random memory because the data they pointed to has been deleted
from somewhere else.
Yes, you may need to manually null out a few references to avoid space
leaking, but in those instances you'd almost certainly need to do something
equivalent for a manually managed system too (and if you mistakenly didn't
it would be a lot harder to track down).

Compare this to double deletes, memory leaks and scribbles which are often
manifested as heisenbugs, I would definitely prefer these rare and easily
fixed issues that GC has.

You're absolutely right that it's not a perfect solution, and you'd
definitely need to spend some effort dealing with memory management issues
even with a garbage collector, but it does solve (or at least makes it
easier to track down) a lot of the pedestrian hassle of doing it manually.

-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862

Re: [Algorithms] Complexity of new hardware

[Jon W. <jw...@gm...>]

Nicholas "Indy" Ray wrote:
>> At least for private projects, I've almost completely abandoned it - work
>> has a slightly higher inertia ;)
>>     
>
> I don't know if you're private projects are game related. But at the
> moment there seems to be a much bigger issue then inertia in the work
> environment, which is the lack of a viable alternative in our field.
>   

If you do PC games, then C# is within inches of being a totally suitable 
general purpose replacement, and it already is a good replacement for 
many specific games or subsystems. It has nice reflection, you can poke 
at objects while you're developing the classes, it has good interfacing 
to existing native libraries, it has good performance, it allows 
byte-by-byte access, etc.

Sincerely,

jw

Re: [Algorithms] Complexity of new hardware

[Nicholas \Indy\ R. <ar...@gm...>]

On Sun, Apr 26, 2009 at 5:46 PM, Jon Watte <jw...@gm...> wrote:
> If you do PC games, then C# is within inches of being a totally suitable
> general purpose replacement, and it already is a good replacement for
> many specific games or subsystems. It has nice reflection, you can poke
> at objects while you're developing the classes, it has good interfacing
> to existing native libraries, it has good performance, it allows
> byte-by-byte access, etc.

I don't know if PC Games include Mac or other *nix systems, but I
don't feel mono is yet mature enough for game development, and thus
for those who choose not to develop for Microsoft's platforms
exclusively it's not yet a suitable replacement.

Nicholas "Indy" Ray