Comment by MichaelGG | Hacker News Reader

Comment by MichaelGG | Hacker News Reader

Parent Full thread

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.

go on. I'm not a hardware guy, but i'm pretty interested in STM/HTM. From what I understand, its harder than it appears considering Sun scrapped The Rock after its HTM speedups weren't as good as they were supposed to be.

Is your design pure HTM, or a hybrid approach? Or hardware support for STM? (Which seems more doable). Cliff Click of Azul fame has some interesting comments on how HTM didn't really work as a 'dusty deck' solution for replacing locks, which is why I assumed its support and not a pure HTM implementation.

  What happens if you overflow the 'rollback memory/cache' (or whatever you kids are calling it these days?)

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)

64 bit integers should be enough for anybody :)

I don't know, why people keep asking for more resources? Maybe he wants to store every pixel, its lightning and physics from a 32 multiplayer game to offer time-machine features (like the TimeShift game). Maybe he wanted to make a scientific game, something like EVE online, but analysing Hubble data. Maybe he just thinks it would be nice to be the first to break the current limits to sell future-proof game engines.

I don't know. But asking why would people ever want more in their computing power than what's been offered has always came back to bite the questioner :)

What integer value in a game gets so big that it can potentially overflow a 64 bit integer?

2^64 meters is only around 1900 lightyears, which is woefully insufficient for a galaxy-scale RTS.

But a game that uses integer meters for coordinates has galaxy-scale problems of another kind.

I've tried to write a space game, and let me tell you, 32 bit floating point is woefully inadequate. Unfortunately, most 3D hardware at the time was built around 32 bit floats. Those only give you about 1 in 100,000 resolution. I had to create scaled-down "billboards" for nearby celestial objects and park them 1000's of kilometers away. (When they were actually 10's or 100's of kilometers away.)

Even 64 bits wouldn't allow for a naive implementation of a realistically scaled space game. There would still have to be a lot of optimization tricks played.

EDIT: I realize that the parents posts are talking about Integers, but you can't send those directly to the GPU!

Perhaps he foresees a high score inflation.

My favorite integer overflow bug was the max score in original tetris -- 32767. Although seeing IKEA chair* tester's counter overflow and bring the system down is a close second.

[* chair tester just like one shown here: http://www.youtube.com/watch?v=uaZ3ikJ-M4o&NR=1]

I kept thinking about Go.

Go's concurrency support isn't that exciting. It's basically very efficient UNIX processes. Which is fine, but not as good as composable concurrent state changes, which is what STM offers. (The key is composability; that's what you don't get with locks or "just do it in another process".)

What go has isn't just, "locks or just do it in another process." Either that, or Erlang just has "locks or just do it in another process."

What Rob Pike has put into Go, he used in a previous language he developed called Newsqueak, which enabled him to write an entire GUI windowing system in one afternoon. That combination of shared-nothing concurrency and message passing is pretty darned powerful. In such a system, locks are there under the covers and are invisible to the programmer.

I think you vastly over estimate how much a productivity boost 'shared nothing, message passing' concurrency adds.

I've programmed a lot of both, and while shared nothing makes the easy stuff easier, it doesn't seem to make the hard locking problems any less hard. You still have to think about race conditions and deadlocks.

I think that's an oversimplification. For example, most people do not associate Unix processes with a single address space. In any case, the paper is not asking for a revolutionary threading model.

On the contrary, STM is pretty revolutionary and its exactly what it asks for. :-)

Reply on news.ycombinator.com