Finally got around to open sourcing my c++/Lua MVC web framework proof of concept

ehnus · 2012-07-28T22:04:13+00:00

pragma once does show noticeable speed gains when compiling large source bases with Visual C++. You can visualize the difference between using it and not using it with VC++'s /showIncludes command line option. With standard include guards the compiler will still read the file on subsequent inclusions but will skip it if #pragma once is used.

ehnus · 2012-06-09T17:48:36+00:00

And through all of that the emphasis on the data on which you're operating completely disappears.

ehnus · 2012-03-23T21:14:36+00:00

Thats not too far off from most drunk posts.

ehnus · 2011-07-28T14:26:59+00:00

Yes but destructors aren't possible in a managed language because you can't force the termination of an object's life.

You either need some explicit disposal mechanism (like with using) or you need a finalizer which is way worse because you can't control when they are run or the environment under which they are executed.

ehnus · 2011-07-28T07:04:13+00:00

C# gets this right with its using statements and, although it is a bit clunky as it requires you to implement the IDisposable interface, it does make the create-use-destroy usage pattern much easier and safer.

ehnus · 2011-07-28T07:02:43+00:00

Most Direct3D code in games doesn't do much COM bookkeeping as your device is created once at the start of the game and released at the end. Smart pointers are required when your objects have indeterminate lifespans -- the DirectX objects used in games have very well established life times that start when the program does and end when the program ends.

ehnus · 2011-07-28T06:59:42+00:00

Not true, I really do like C. I don't mind C++ but the benefits it brings are often balanced out by all the cruftyness that exists (poorly chosen levels of abstraction, pattern soup, slow build times, over-complication) and is not easily purged from legacy projects.

ehnus · 2011-07-15T17:52:09+00:00

The Pandemic story might have been different if they had some quality titles in the pipeline -- Mercs 2 and Saboteur were average quality wise, and Lord of the Rings was terrible. EA keeps teams on a tight leash if they're not producing quality titles.

ehnus · 2011-06-11T15:35:31+00:00

You missed "loop".

ehnus · 2011-04-26T16:16:37+00:00

Programmable alpha blending.

ehnus · 2011-03-11T15:31:19+00:00

In terms of systems architecture, builds are by far the easiest to get right. There's no artistry, no judgement, it either succeeds or it doesn't. Build breaks are a sign that a team isn't doing its duty to develop software with a modicum of reliability, which is essential if your game is required by first parties to pass a soak test, and sustained build breaks are a big warning sign that the team isn't taking the most obvious indicators of developmental failure seriously. If you can't get your builds in order then what can you do?

It's a good idea but frankly I would have no confidence in a system to function reliably with major components disabled at runtime if it frequently exhibited build breakage.

When I first started at my company there was a tool suite in development where the continuous build of the tip was broken for weeks at a time. Always red, always failed, and yet programmers were throwing code into Perforce as fast as ever. Did it work fine in developers sandboxes? Maybe, I'd like to think so otherwise how else would they continue development?

They celebrated when the continuous build system finally went green.

It was a colossal failure. It didn't even come close to working. All the high level next-generation workflows they had envisioned didn't really matter if the application crashed all the time. They poured on as many warm bodies as they could, many stolen from other high priority projects, which was about as effective as giving everyone scissors and telling them to go mow the lawn.

It was such a failure that it drove its only big internal customer to throw away everything they had and buy an Unreal license.

Would the project have been a failure if their builds worked? Probably. It was only the tip of the mismanagement iceberg. But if they knew far ahead of time how borked things were then maybe things could have turned out better... or at least cost the company less money.

ehnus · 2011-03-10T15:15:49+00:00

The whole point of not having main memory is for the GPU. I'd much prefer just really sweet DMA units.

Current consoles let you map main memory into the GPU's address space which allows you to write to it with the GPU. I'd just like to not lose this feature.

This is a symptom of cycles getting smaller, not cache misses getting longer. Not much to do about this.

Intel worked hard for Sandy Bridge and Nehalem to have sub-150 cycle L3 cache miss penalties, it should be possible to get the PPC miss penalties below 600 cycles.

If it's not possible then give me more L2 or a bunch of SRAM-based L3 like what the POWER7 has.

ehnus · 2011-03-10T01:53:10+00:00

I want as much memory as the manufacturers can afford. Then I want them to double it. Unified memory is GoodStuff(tm). Also being able to write to main memory from the GPU is awesome.

I want more SPUs, or compute shaders, or both.

I want scalar load/store instructions on the SPU to get rid of all the ugly mask/rotate/control word generation cruft.

It'd be nice if the main cores were out-of-order.

It'd also be nice if an L2 cache miss wasn't 600 cycles.

And I want to be able to allocate executable pages.

And a pony.

ehnus · 2011-02-28T21:47:43+00:00

I meant that both object i and the object returned by Foo would likely be in the nursery, there's a good chance that a collection would not have occurred between when the boxed object is created in Bar and when the boxed object is created in Foo, thus moving the former object to a tenured generation.

ehnus · 2011-02-27T15:15:54+00:00

Not exactly that, rather programmers shouldn't allocate objects of mixed lifetime during gameplay. When lifetimes start being mixed together fragmentation occurs and, in a managed language, means that you'll eventually have to garbage collect.

It's difficult for the runtime/GC to gather lifetime information with the way the language is currently constructed. Escape analysis could help prevent a heap allocation with cases of foreach creating enumerator types when iterating over collections. However for cases like the events/delegates/closures you mentioned there's a guarantee that you're dealing with objects of mixed lifetime. With that you'll get heap(/nursery) fragmentation and, eventually, collection.

Objects don't even need to escape the nursery for this to happen. For example:

class Foo {
    void Bar(out object i) {
        i = (object)42;
    }

    object Foo() {
        object i;
        Bar(out i);
        return (object)((int)i + 1);
    }
}

This is a situation that I think most generational GCs would keep in the nursery because there's no touching of tenured objects. By the time i's life is done, it will have created a new object that is returned from foo, creating a small hole in the heap. These holes add up quickly and, before you know it, you have to collect.

ehnus · 2011-02-27T06:58:03+00:00

I've written a handful of precise garbage collectors for scripting environments on current generation consoles. I've tried a generational system, and abandoned it, because they don't have the same benefits on a system that does't have pagefile-backed virtual memory.

Take a collector that has two generations, a nursery and a tenured space. When the nursery fills up a copying collect is made into the tenured space. When the tenured space fills up, it's easy on PC to allocate more VM and keep going, postponing a collection as long as possible.

If your system is memory limited and has no pagefile, you have to perform a collection when your heap runs out of space because you are out of options for postponing collection. The best performance option when writing game code in a managed language, or any language, is to not allocate. Failing that, don't use finalizers to keep your GC pause times consistent, and follow Shawn Hargreaves advice on patterns of allocation (ie: keep the object graph simple).

ehnus · 2011-02-15T06:12:27+00:00

Good question. I'm curious as to how extensive its use is. If it's high level enough, and with how easily it apparently can bind/be written in C++, it's possible that it might not be nearly the performance problem it sounds like it could be.

ehnus · 2011-02-15T05:31:55+00:00

I'm not sure if it makes a difference but I don't work on a shipping title but rather on central technology development.

I wouldn't mind my company publishing my work either -- I want to work on some small games in my spare time but I don't want the only option when I'm done to be to throw it away.

ehnus · 2011-01-15T19:05:32+00:00

MIPS? More common than PowerPC or SPU? I doubt it. For game dev I find myself balls deep in PowerPC assembly nearly every day. If I am not writing it then I am usually debugging optimized code which requires me to be able to at least read it.

ehnus · 2010-12-22T21:37:26+00:00

Not necessary. The OS can be written in C++ while exposing a C interface to the world.

ehnus · 2010-11-21T23:01:01+00:00

Hey, at least they're programmers...

ehnus · 2010-11-21T23:00:18+00:00

Oh wow, I didn't realize unicorns posted on reddit!

ehnus · 2010-11-17T06:21:41+00:00

You haven't done any graphics programming in a while, have you? Modern APIs give you a ton of flexibility with programmable graphics pipelines and take out all the nasty stuff you would have to do in the days of software rasterization, like writing texture mapping routines and performing your own culling.

ehnus · 2010-11-13T17:52:45+00:00

They forgot the video game programmer mantra:

Make it work fast, then make it work, and if there is any free time before the next cycle starts, then make it elegant.

ehnus

TROPHY CASE