Jump to content
  • Advertisement
Sign in to follow this  
JimPrice

Speed : she cannae take any more, cap'n!

This topic is 4971 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

One of the recurring themes on these boards is speed (despite the high number of learners here, to whom it matters very little compared to other major considerations). Topics such as: Java versus C versus Asm versus C++ versus C# versus (insert language here). To STL or not? If I rewrite this in asm will it improve on standard functionality? It seems to be a given that speed is a major factor in games development - after all, you only have 1/60th of a second to whip that next frame to screen. But - I wonder how much of this is historical? Is speed such a major issue in modern game development? And are the topics that commonly come up (such as those above) such show-stoppers compared to such things as algorithmical improvements? As an example : I was looking through some historical C(++) versus C# threads recently. The consensus seemed to be there was maybe a 1-5% slowdown using C#. Accepting this as true (bear with me) - what is the actual implication of this? Considering PC development - do you try and squeeze your next-gen ap into your target spec, or (assuming a 5% performance lag), up your target spec from a 1gHz processor to a 1.05gHz processor? Are target specs so immutable - especially given the speed of technology advances? As a secondary question to this : how do you reconcile having a more complex language that allows you to gain 5% speed against having to spend twice as long (for example) on development? If you could push out two titles in the same time as one, is this not sound business sense? I guess consoles are a whole 'nother bag of chips, though. Here you have a platform spec that is relatively consistent over a long (in computer terms) time - say 3 - 4 years. In such cases, I can see a stronger case for optimising certain routines. But is this likely to become less of an issue as consoles become more powerful (yes, I'm looking at you PS3 and Nextbox)? Another question, then - and this is the really important one - what proportion of games are really pushing the envelope, and really need that speed? And what proportion of the total market does this represent? In the last year (the Chinese year of the FPS) we had (on PC) FarCry, Doom3 and Half-life - all games that have high-specs based upon their graphical capacities (I assume - although I suppose the AI (FarCry) and physics (HL) may have something to do with it). Now I have an off-the-shelf 3ghz / 512mb RAM / fx5200 (urgh!) - and I have played Doom3 and FarCry acceptably (haven't tried HL2 yet - wait till the price comes down). Surely I'm around average spec for computer hardware? What proportion of the total market is the hardcore gamer with their 6800's? What games / genres could be considered good candidates for a more RAD language that takes a slight speed hit? A final thought - is marketing an important part of this? As the majority of advertising outlets are visual in nature (ie magazines, or screenshots on a website), does a purty screen-shot sell more units? If this is the case, does this justify the usge of a certain language that may allow prettier pictures? So - in summary - is worrying about language speed performance really that big a deal? Is this likely to change with hardware advances? Are we really relying on processor-intensive processes (graphics) to give our games gameplay? And - my big question : What proportion of games are really pushing the envelope speed-wise? And if you've stuck with this till the end - thanks for reading! Jim. PS : And yes, I'm aware of 'Premature optimisation is the root of all evil!".

Share this post


Link to post
Share on other sites
Advertisement
You're forgetting one very important thing: Optimizing for speed is fun (which is the primary reason that most of us are here) and require close to zero creativity. And then there's the appeal of doing what the "pros" are rumored to do, wheter you actually need the performance yourself or not.

However I'd argue that this shift is already taking place, just not to so much towards traditional languages such as Java or C# but to scripting languages instead. In most big commercial games of today the amount of scripted content probably outweights the optimized native code (most of which is often provided by an external engine anyway) by a factor of 5, although this depends heavily on the game itself.

And yes, screenshots sell.

Share this post


Link to post
Share on other sites
Quote:
Original post by JimPrice
As an example : I was looking through some historical C(++) versus C# threads recently. The consensus seemed to be there was maybe a 1-5% slowdown using C#. Accepting this as true (bear with me) - what is the actual implication of this?


The only implication of this that I can see, would be that if your team knew C# and C++ equally well, and felt that C# made you more productive, then you could use that instead. But most people don't know C# to the same degree, and if the flip side of the equation was that it only makes you 1-5% more efficient as a developer, you would probably lose more time in learning the language to full effect than you would save in development.

Quote:
Considering PC development - do you try and squeeze your next-gen ap into your target spec, or (assuming a 5% performance lag), up your target spec from a 1gHz processor to a 1.05gHz processor? Are target specs so immutable - especially given the speed of technology advances?


Technology advances have slowed down, and so have new computer purchases. One of the horrific errors I've seen some people make on this forum is to assume that the average spec of the computers in the shops is the average spec of the computers at home. No way.

Quote:
As a secondary question to this : how do you reconcile having a more complex language that allows you to gain 5% speed against having to spend twice as long (for example) on development? If you could push out two titles in the same time as one, is this not sound business sense?


The problem is that you're quantifying speed but you're not quantifying productivity. There's a leap of faith involved in assuming that, for example, Java or C# provide productivity gains over C++. To a new programmer, I would bet large amounts of money that Java or C# provide instant benefits compared to C++. To someone who is already experienced in C++, I would be much less certain. If you took a much more high level language like Ruby or Python that feels elegant, rather than including features that feel like hacks (eg. Java generics or C# delegates) I would be more inclined to believe you.

Quote:
I guess consoles are a whole 'nother bag of chips, though. Here you have a platform spec that is relatively consistent over a long (in computer terms) time - say 3 - 4 years. In such cases, I can see a stronger case for optimising certain routines. But is this likely to become less of an issue as consoles become more powerful (yes, I'm looking at you PS3 and Nextbox)?


Doubt it. The problem moves but doesn't go away. In a few years graphics will be photorealistic but physics won't be totally accurate and AI will still be neglected. If you can play to the hardware's strengths to get yourself extra cycles for other aspects, you'd do it.

Quote:
Another question, then - and this is the really important one - what proportion of games are really pushing the envelope, and really need that speed?


Wrong question, I think. I'd bet it's less about pushing the envelope and more about running well on more than just hardcore gamer PCs.

Quote:
A final thought - is marketing an important part of this? As the majority of advertising outlets are visual in nature (ie magazines, or screenshots on a website), does a purty screen-shot sell more units? If this is the case, does this justify the usge of a certain language that may allow prettier pictures?


Nope. Aren't you missing the point that screenshots are static? You could write the game in some slow language that runs at 3fps with all the detail turned up, yet it would work fine as a screenshot.

Share this post


Link to post
Share on other sites
I think your whole premise is wrong. that optimizing takes a long time, somehow C++ is a really fast language, C# is slightly slower, processor speed makes up the difference...

People who have never actually optimized code write things like this.

Speed is about memory bandwidth. Optimizing happens when you're designing your data structures... not an afterthought that mysteriously improves performance while doubling production time. The fact is that as processor speeds have improved 1000%, memory access time has improved maybe 50-100%, and games have become much more memory intensive.

There are no analogies to be drawn here. No unambiguous trade-offs. No silver bullet. If your program is slow, the language is not your problem. If you are unproductive, the language is not your problem.

Share this post


Link to post
Share on other sites
Quote:
Original post by ajas95Speed is about memory bandwidth. Optimizing happens when you're designing your data structures... not an afterthought that mysteriously improves performance while doubling production time.

While for the most part this is true, there is a not unreasonable amount of optimizing that can be done "after the fact". Once you've nailed the asymptotic runtime down to something reasonable, it's not at all a bad idea to run an analyzer on your code to see where the major bottlenecks are. You may find that you have a loop somewhere where you spend 95% of your time, regardless of the data structure you're using. That's the kind of situation that warrants special considerations.

Designing with performance in mind is still an excellent idea, of course. In fact, spending time designing your program can save you massive amounts of rewriting further down the line. Just do start coding eventually. :)

Share this post


Link to post
Share on other sites
Quote:
Original post by doynax
However I'd argue that this shift is already taking place, just not to so much towards traditional languages such as Java or C# but to scripting languages instead. In most big commercial games of today the amount of scripted content probably outweights the optimized native code (most of which is often provided by an external engine anyway) by a factor of 5, although this depends heavily on the game itself.


[Warning!!! I am going to ramble on for several paragraphs and not really draw a conclusion.]

Sad, in a way. My view of things is that languages like Java and C# do a pretty good job of letting you treat them as either a (relatively) high-level or low-level language, and think in one way at a time. You can work things out in Java (and I assume C#, but I haven't used C# yet so I won't speak authoritatively about it) in a relatively rough way, profile things, and then optimize the important stuff - in Java. (By removing layers of indirection, and generally moving away from 'nice' OO design - after exploiting the code organization that the OO provided you in order to remove "high-level redundancy".)

C++ has libraries available these days (notably the Boost collection) that let you do certain things in a very high-level way - but you are still stuck with something that transforms to C++ code, and has to be fed to the C++ compiler, a horridly complex beast that barely speaks English back to you when something goes wrong. In effect there is no escaping from having to work at a low level at the same time as you (try to) take advantage of whatever wonderful library. (As just one example of the phenomenon, consider how often I find myself linking this article - and how none of that advice is really needed for any language other than C or C++, that I can think of anyway.)

Scripting languages do high-level by design, to the extent that there are large amounts of wrapping around things that you can't get rid of within the language; the low level simply isn't available. So if you want to "optimize the hard bits", you drop down to C++, and use some interface or other between code in the two languages.

Of course, there are lots of ways to pair up languages, some more sensical than others. Python (and Perl too) seems designed more to interface with plain C than C++, but Boost has (apparently) made things much nicer for those who would like to use objects on both sides of the fence. You can interface Python with Java quite easily, although it may not help much with limits on performance. And hell, you can even interface Java to C++ if you really want to, through JNI calls; but I can't imagine it being practical very often.

Anyway, I'm left wondering why more people don't write the whole thing in Java or C#, with "scripts" becoming more data-like, or perhaps custom-done. I assume that a good number of people have actually weighed all the alternatives and considered the matter in some depth. (I fully expect to be very sorely disappointed on that score, though.)

It seems as though while Java lets you do things at both ends of the spectrum pretty well, it doesn't go far enough either way - doesn't handle truly high or low level programming well enough - for some tastes. It must be enough of a problem to offset the difficulty of interfacing two languages.

Of course, using a scripting language like Python means that creating content that requires a bit of "intelligence" becomes a lot easier - in many cases it's better to go this way than to try and create your own language. OTOH, we all know what a hard time artists and programmers generally have understanding each other ('s worlds). Do you really want your artists to have to learn a "real programming language", even if it's Python?

Perhaps something less powerful is called for, for content. When you make something yourself, you can tailor the language to the task. At one end of the spectrum of customization, you approach real-world scripting languages like Python (or Lua, etc. for that matter). At the other end, you are reduced to POD. It seems to me though that people often assume that these two endpoints are the only possibilities, when actually I am pretty convinced there is a more or less continuous progression from one to the other.

My best guess is that non-programming types would most like to express their ideas as a combination of (1) POD (i.e. for artists, the images they produced in Photoshop) and (2) a natural-language description of how the data needs to be manipulated.

Traditionally (2) is communicated to the programmer, who somehow embeds it into the engine. Natural language communication is inefficient and prone to data loss, but we used to pay this price in exchange for handing off the translation task to someone better skilled for the job. And there's no getting around the translation; computers don't understand natural language, while even the best programmers still think natural language (and can't be counted on to have the best ideas for content anyway; that's basically why the artists and designers are there in the first place.)

In more modern times, we decide to let the computer do the work as much as possible, and thus make the translation task easier, so that (2) can be formulated and "plugged in" by the same person responsible for (1). This ensures integrity of the ideas; but clearly we need to make the task as easy as possible - and then count on programmers to cover up the losses in efficiency. This isn't likely to change much in the near future; ten years from now it may be possible to do entirely in Python what must be done entirely in C++ now, but people, being competitive by nature, are certain to raise the bar by nearly as much in that time. Meanwhile, if people good at C++ were also generally good at drawing (and writing, creating sounds etc.), then we'd be seeing a lot more high-quality one-person productions out there, and companies employing people with titles like "game creation assistant" rather than "programmer" or "designer" or "artist" or "audio engineer". (but wouldn't that be nice?)

Maybe just dropping a really pretty language on people isn't the best way to go about that. Some customization would help out. And maybe making programmers be aware of two radically different languages at once isn't the best way to let them do their thing, either. The alternative approach, then, is to have the programmers work in a "middle-level" language, and as part of the engine, work out some implementation of a "little language" for content development/manipulation (according to the project's specific needs). It doesn't even necessarily have to be Turing-complete.

(Edit: I write all those paragraphs of solid thought on the matter, and then mess up closing a tag... grr!)

[Edited by - Zahlman on January 6, 2005 8:45:47 AM]

Share this post


Link to post
Share on other sites
Quote:
Original post by ajas95
I think your whole premise is wrong. that optimizing takes a long time, somehow C++ is a really fast language, C# is slightly slower, processor speed makes up the difference...

People who have never actually optimized code write things like this.

Speed is about memory bandwidth. Optimizing happens when you're designing your data structures... not an afterthought that mysteriously improves performance while doubling production time. The fact is that as processor speeds have improved 1000%, memory access time has improved maybe 50-100%, and games have become much more memory intensive.

There are no analogies to be drawn here. No unambiguous trade-offs. No silver bullet. If your program is slow, the language is not your problem. If you are unproductive, the language is not your problem.


The last paragraph does not follow from the previous bit. Higher-level languages obstruct or even prevent the process of making the data structures smaller (i.e. only as big as they need to be), because in the interest of making things easier to develop, they add layers of indirection, reference counts, etc. behind the scenes that the programmer can't (easily) strip away. Consider:


C++:
struct foo {
char bar[4][4];
}
// The size is 16 bytes. Since there are no virtual methods, no vtable needs to
// be emitted - the struct just consists of its data members; and the
// double-array is just syntactic sugar for a single array really.

Java:
public class Foo {
public byte bar[4][4];
}
// An instance of Foo consists of:
// - 8-12 bytes object overhead (reference count, object lock, other bookkeeping)
// - A pointer to a byte[][] object.
// Once instantiated, the byte[][] object contains the same object overhead,
// and 4 pointers to byte[] objects.
// Once those are instantiated, they each contain the same object overhead, and
// a set of 4 actual bytes.
// So by the time you get to write all 16 actual bytes, there are also 6 object
// allocations: 4 adding 8-12 bytes overhead (the byte[]s),
// 1 adding 24-28 bytes overhead (the byte[][]), and 1 adding 12-16 (the foo).



In total, in Java you pay anywhere from 68 to 92 bytes of overhead on top of 16 actual useful bytes, in exchange for the huge amount of flexibility you give yourself. In C++ you pay nothing: you might pay a significant amount by using vectors instead (and I wouldn't be able to calculate exact amounts), but the point I am making is about the minimum cost when you write things in an idiomatic way. In Python where everything is a PyObject, including individual numbers, there are no smaller-than-int numeric values, and those PyObjects include runtime type information - the overhead is much higher still.

Now, if you happen to know a thing or two about the JVM, you will probably cut down on this by quite a bit, in the 'optimization' phase of your project - possibly by swapping all these foos out for raw byte[16]'s, and using a bunch of preprocessor magic (or a bunch of static functions and a good bytecode optimizer) to make it all work out properly. But you still pay 8-12 bytes there, which competes with the size of the useful data. And in Python, you're pretty much stuck.

Keeping all this in mind, it's rather a wonder that optimization tutorials still talk obsessively about speed directly, rather missing the point about size...

Share this post


Link to post
Share on other sites
Good point about the scripting languages - the vast majority of developers for 'real' games use C++, and I don't think any consoles support anything newer yet (doubtlessly MS consoles will support .NET eventually).
We didn't have the games written in scrpting language, but Python was used quite a bit for various things, and most developers use a lot more scripting than we did.

Share this post


Link to post
Share on other sites
My rant:

- Developer productivity is probably more related to tools than language. So using a "Good" language with poor tools, is worse than using a "Poor" language with good tools.
- The reason that scripting languages aren't necessarily good for productivity, is that they make bugs easier to create. Finding bugs I think is a large proportion of developer-time, not writing code.

In any case, scripting can be very important anyway as it allows content creators to cross-over and become programmers without having to modify the core engine or create "badness"-generating bugs (Null pointers etc).

Most of the performance-related questions on this board are:

"What is faster? C++ or Java or C#"?
"What is faster? signed int or unsigned int?"
"What is faster? hash_map or tree map?"

In every case, my answer is "It depends on your program." and "Profile them".

If you can't profile your code, you can't even BEGIN to work out which one is faster. Or even if it needs optimising in the first place.

This is why I worry relatively little about my J2ME code performance - I don't have on-device profiling, so there's no easy way of measuring it.

The other answer is: Does it really matter?

I am all for people using the technology they're most comfortable with and does the job. I believe that "just good enough" is, well, good enough.

People care far too much about optimisation in general and nit-picking stuff in particular.

Mark

Share this post


Link to post
Share on other sites
Quote:
Original post by Zahlman
(As just one example of the phenomenon, consider how often I find myself linking this article - and how none of that advice is really needed for any language other than C or C++, that I can think of anyway.)


There is a reason why the author of that article prefers to use Python whenever possible... ;)

Quote:
Anyway, I'm left wondering why more people don't write the whole thing in Java or C#, with "scripts" becoming more data-like, or perhaps custom-done. I assume that a good number of people have actually weighed all the alternatives and considered the matter in some depth. (I fully expect to be very sorely disappointed on that score, though.)


Assuming performance is essentially unchanged, the benefit of a new language equals the net productivity gain minus the cost of learning it properly. With that in mind, I don't see much point upgrading a small step from C++ to C# or Java. I do see the point in new programmers going straight into those languages, as long as they're not totally oblivious to what goes on under the hood.

I recently saw someone who was trying out Python after having used VB. He was complaining about a speed decrease, and he had loops like this:

for i in range(len(myList)):
processItem(myList)


Although the above loop did what the programmer wanted, any Python programmer reading that will probably cringe. Yet a VB programmer will probably not see anything wrong with it. Even easy languages take time to learn properly.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!