I'm pretty sure this is old and well known, but here are some highlights. This is from the founder of Epic Games, which makes Unreal Engine, which runs tons of modern games. Thus, it's from someone doing real-world work with high performance requirements.
Here are some highlights:
- "Gladly sacrifice 10% perf for 10% higher productivity"
- "Never use assembly language"
- 50% of bugs are array indices, null pointers, integer overflow, uninitialized vars
- Suggests dependent types to solve array bounds issues
- 90% of integers are array indices, 80% could be dependently-typed
- For loops: "40% are functional comprehensions, 50% are functional folds"
- Gameplay code is hard to make concurrent - thousands of mutable objects, updated tens of times per second, each update touches many other objects
- Suggests transactional memory: 2-4X perf overhead is acceptable if code can scale to many threads
- "Garbage collection should be the only option"
- "Syntax requirement: Must not scare away mainstream programmers"
About transactional memory: I know that software TM has 2-4x performance overhead, but hardware can eliminate that. I've been working on hardware transactional memory design, and I can say with some authority: if chip-makers add proper HTM, and the software compilers and runtime environments use it in a non-braindead way, transactional memory will run at greasy fast speed. Faster than locks, usually. It's going to be great.
For example, did you know that you can get a highly scalable priority queue data structure by just using a skip list and hardware transactional memory? It's so simple that I felt almost ripped off when I realized how much easier TM makes it. If you've ever tried to make a concurrent priority queue with locks or compare-and-swap primitives, you'll be pleasantly surprised by how much easier it could have been if only we had hardware transactional memory.
This question has been bugging me in my mind ever since I first saw this presentation back in 2005:
What integer value in a game gets so big that it can potentially overflow a 64 bit integer?
I've literally been thinking about this question for years and I can't think of a single case. Bignums are pretty much only used in scientific computations and the only thing in a game that would come close to this would be encryption, in which case the programmers would know what they are doing and wouldn't mistakenly used fixed size integers.
(Of course back in the day integer overflow bugs in games were everywhere, one awesome example being level number 256 in pacman)
That was a good (if old) presentation. I worked for a few years in the entertainment industry (Nintendo U64 and PC games, virtual reality projects for Disney and SAIC) and it is an experience that I can recommend to any computer scientist because there are so many interesting problems to solve. Anyway, if you can take a few years off from whatever career path you are on, you will enjoy the experience.
Off topic, but it always surprises me how someone with all this knowledge can ..well, use Comic Sans for the presentation. While I understand that it's about games and that Comic Sans is supposed to be perceived as a "fun" font, this is really an odd choice.
[+] [-] MichaelGG|16 years ago|reply
Here are some highlights:
- "Gladly sacrifice 10% perf for 10% higher productivity"
- "Never use assembly language"
- 50% of bugs are array indices, null pointers, integer overflow, uninitialized vars
- Suggests dependent types to solve array bounds issues
- 90% of integers are array indices, 80% could be dependently-typed
- For loops: "40% are functional comprehensions, 50% are functional folds"
- Gameplay code is hard to make concurrent - thousands of mutable objects, updated tens of times per second, each update touches many other objects
- Suggests transactional memory: 2-4X perf overhead is acceptable if code can scale to many threads
- "Garbage collection should be the only option"
- "Syntax requirement: Must not scare away mainstream programmers"
[+] [-] sketerpot|16 years ago|reply
For example, did you know that you can get a highly scalable priority queue data structure by just using a skip list and hardware transactional memory? It's so simple that I felt almost ripped off when I realized how much easier TM makes it. If you've ever tried to make a concurrent priority queue with locks or compare-and-swap primitives, you'll be pleasantly surprised by how much easier it could have been if only we had hardware transactional memory.
[+] [-] iman|16 years ago|reply
What integer value in a game gets so big that it can potentially overflow a 64 bit integer?
I've literally been thinking about this question for years and I can't think of a single case. Bignums are pretty much only used in scientific computations and the only thing in a game that would come close to this would be encryption, in which case the programmers would know what they are doing and wouldn't mistakenly used fixed size integers.
(Of course back in the day integer overflow bugs in games were everywhere, one awesome example being level number 256 in pacman)
[+] [-] stcredzero|16 years ago|reply
[+] [-] zbanks|16 years ago|reply
He _does_ point out a few of the downfalls of Haskell, but there seems to be some positive element there.
[+] [-] nash|16 years ago|reply
I had assumed the problem was being able to use it when we liked.
[+] [-] blasdel|16 years ago|reply
Wonder if this is still true: "Factoid: C# exposes more than 10 integer-like data types, none of which are those defined by (Pythagoras, 500BC)."
[+] [-] snprbob86|16 years ago|reply
System.Numerics.BigInteger: http://msdn.microsoft.com/en-us/library/system.numerics.bigi...
I'm sure there are more.
[+] [-] kunley|16 years ago|reply
[+] [-] mark_l_watson|16 years ago|reply
[+] [-] esad|16 years ago|reply