Fog Creek Software
Discussion Board




a case for non-managed memory

Seems to me that the basic applications-- writing documents (pdfs, whatnot), email, IM, etc, all have been more or less solved.  Yes, there are the occaisionally difficult things to do, but writing equations and document formatting was solved way back with LaTeX and making sure your grandmother can get email with your kids in the picture is something people do every day (assuming that all those generations are still around, of course).

The harder applications, the ones that aren't so quick to be finished, are certainly still around, and they might not be so quick to move to a managed memory environment.  Case in point: I write software designed to help biologists track particles.  Is it a huge market?  It's large enough to support several companies that are aimed at this space, but you won't be seeing these applications become household names any time soon.  But the stuff we're doing is very unlikely to be move to a managed memory environment, simply because of the sloppiness that that environment allows.

Whenever I've worked in a managed memory environment, I've never worried about memory getting deallocated or anything like that, which is the point.  But in our app, we're constantly hitting the 2 gig limit; you might be surprised at just how much data people can capture, and how much intermediate data has to be generated to answer their questions.  Why do we not develop on Unix or something else?  Because biologists like to use Windows and Macs, plain and simple, and neither of those are yet ready for 64 bits.  It's not in our market yet.

I don't see this as a trend that will decrease any time soon, either.  Games are going to start hitting the 2gb barrier when their textures get very complicated, they're going to have to manage both memory on the CPU and memory on the GPU (which has to be done already, but GPUs don't have virtual memory, really, as far as I know).  The more lifelike the game and the larger the gaming environment, the more control over memory you need; you can't let memory get handled by a garbage collector when a) you need all the speed you can get, and can't let a garbage collector run amok and b) you need to be able to load and unload levels at the player's whim.  Here I speak of things which I only tangentially know, but have never actually developed.

My point is this: managed memory is not such a great thing for everyone.  There is a certain segment of the programming world, one which in my mind is constantly hungry for the fastest hardware, which requires that a person still manage the memory.  This means that adopting the 'sandbox' approach just will not cut it; it's too lackadaisical when every byte counts.  The web is so far removed from a possibility that it's not even funny.  There is proof of concept software to do what we do over the web; but it lacks the ability to easily and transparently navigate 4D datasets that are gigabytes in size.

For us, then vc++6.0 is as good as it gets; perhaps the vc++ in .net is good enough as well, but I fail to see the benefit in the port, especially if we're going to have to make this massive switch to winFX. But if WinFX requires all managed code in order to run, well, we're really going to have a problem, because we need that control.

mmr
Wednesday, June 16, 2004

I agree with your point, that there are many product spaces where memory performance is important enough that you want to do it yourself rather than wait for a GC to come along when it feels like it.  There are many such product spaces, and there will be for a long long time, if not forever.

But just a point about the compilers.  Plain old C++ in VC 7 is significantly better than in VC 6 in terms of standards support and quality of code generated.  You might want to check it out, even if you have no intention of leaving the native unmanaged world.

Michael Kale
Wednesday, June 16, 2004

I don't get it. You still have a 2 gig limit on non-memory managed apps. I run into it all the time.

The short term solution is to use the 3GB switch and the long term solution is to go to 64 bit CPU/OS.

MilesArcher
Wednesday, June 16, 2004

It's like my first programming instructor said about assembler (and machine language):

"You _can_ program everything in assember, but why?Programming in a modern language is faster and probably going to be more acurate.

Assembler's only advantages are where speed [of execution] and memory is limited. And even at that, it might be a better idea to code in higher level language like C and then hand tune the assember."

And there is another favorite instructor of mine who (after using a "goto" in an example and seeing our faces) said
"Some times, it's better to break the rules than to blindly follow them - 'LOOK!!!! I'm running with scissors'". The point of with being, you have to understand why the rule is there, its implecations, and when it is better for the program to break that rule [and in this case the "goto" made the function much easier to understand to the lay reader, quicker to execute, and quicker to write]

I agree. In the particular instance you describe, using managed memory language is probably not the best practice. And I would suggest staying that way, you understand the rule that you are breaking, its implications, and your program will be better by breaking that rule.

We teach new and novice codes these rules to protect them from themselves. When they get into a situation where that rule needs to be broken for the good of the program, then they can be enlighted.

I'm not saying don't teach lower level languages. A lot can be learned from them, and it helps with more subtle issues (like MM verses non-MM). Let them get a handle on the simpler concepts before you through them at doubly-linked-circular-linked-lists, programmer directed memory managment, and inline assembly.

Sean Ennis
Wednesday, June 16, 2004

Michael:  Do you have a changelist that describes those standards compliance issues?  I've looked, and found no real reason to upgrade, but I'm all for it if it's the goodness.

Miles: It's not that there's enough memory, is that memory is constantly getting allocated and deallocated, and I need control over it.  I can't leave it up to a GC to do it for me.

Sean: A good point.  I guess my temperature goes up every time I read Joel make yet another broad statement about computing that I can't identify with, something he warned me he'd do :)  But on the other hand, I think there's a larger point here worth discussing:  Those applications that are truly pushing the envelope right now depend on tools that are not part of the Microsoft paradigm and what they are pushing for, vis-a-vis managed code.  Perhaps winfx allows for non-managed executions, I don't know.  But if it does not, then that means Bad Things for this direction of coding.  We'll either have to limit our customers from upgrading, port everything to winFX or linux or whatever, or die, none of which are particularly attractive prospects.  For games, it will, I suppose, be easier, given the shorter lifetimes of those projects, but all the libraries and engines that people use (Quake, Lithtech, etc), will also have to be rewritten.  In other words, backwards compatibility isn't the only bad thing to break; if managed code is the Wave of the Future, then stuff like what I do will become massively inefficient, perhaps to the point of unusability.

mmr
Wednesday, June 16, 2004

Joel's argument is a statistical one. One can always find cases that contradict it. But the contraditions don't invalidate it as long as it's true for the majority.

Joel is certainly not suggesting that managed-memory should be the exclusive approach.  That is, he is not saying it's a "one size fits all" situation.

He's saying (among more significant things), that managed memory is a big improvement for most kinds of software. There certainly exist important cases where non-managed memory is necessary (but these cases are, relatively, infrequent).

njkayaker
Wednesday, June 16, 2004

What's the memory problem here -- as long as you can still write programs in C/C++, you can always allocate a huge char array and stuff or arrange whatever data you want in it yourself.

It's still pretty common in the PC game industry at least to write your own memory manager, since you know your dynamic data is usually limited to one of several data types that you can keep in a pool and reuse, both to keep it contiguous and minimize CPU cache misses, and to minimize heap fragmentation and spilling into the swap file.

Writing an entire commercial game in C# is never going to happen, which MS knows, so they're never going to require all apps to be written in that (or one of the other .NET languages). We've been told this by the DirectX evangelists... though they did say probably different API calls will get restricted (e.g. no file opening unless you have permission, or only in your apps' allocated area), and others may require managed data structures to pass back and forth. But Windows/Longhorn/Future Project X will always support C and C++ because there's just too much existing codebase to drop it.

Game Programmer Bob
Wednesday, June 16, 2004

Cripes, how many times does he have to repeat '''When I say things like "nobody" I really mean "fewer than 10,000,000 people"'''

As for all those other problems being solved... the problem the wheel solved was done perhaps tens of thousands of years ago, and yet we still have tire and rim designers.

Bob
Wednesday, June 16, 2004

bob-- do you think games are only played by less than 10 million people?

mmr
Wednesday, June 16, 2004

That came out more snarky than I meant it to, sorry about that.

This just seems very reminiscent to me of the OSX transition, with a few major exceptions.  The OSX transition requirements are all necessary to make the Mac both stable and useful.  Managed code is not necessary, but if it becomes an arbitrary requirement, then that's a lot of busywork for not a lot of gain  (one point of Joel's article).  But in some cases, like the games that will never be in C# or apps like mine, it's not just busywork, it's well nigh impossible, and a strong reason to not use that platform.  This isn't a small segment of the computing population, but a significant enough population to make games one of the most lucrative industries today.

mmr
Wednesday, June 16, 2004

I'd be willing to bet that 10 years from now, many, if not all, games will be written in a managed memory environment.

When I was a kid, virtually all games were written in assembly and the idea of using a higher level language was ridiculed. With Moores law and the ever increasing complexity of games, the forces that pushed business software to use high level languages will also affect the games industry, although at a slower rate.

MilesArcher
Wednesday, June 16, 2004

"I'd be willing to bet that 10 years from now, many, if not all, games will be written in a managed memory environment."

Well you'll lose that bet, because the majority of titles are written for the console, not the PC, and the next generation Sony and Nintendo machines have mentioned nothing about putting an OS in them let alone some kind of memory management scheme. Sony's API's have always been absolute bare-bone, you (have to) control everything down to what goes on what bus and when.

Game Programmer Bob
Wednesday, June 16, 2004

mmr, yes the game industry currently has higher sales than the movie industry (over $10 Billion last year).

Game Programmer Bob
Wednesday, June 16, 2004

Sounds like you're comparing total global game sales to something like US domestic box office receipts.  The movie companies do better than $10B.  Single summer blockbusters often approach $1B.

the other Bob
Wednesday, June 16, 2004

Oh, could be... according to http://www.the-infoshop.com/press/fi16112_en.shtml wordlwide movie receipts in 2003 were $20 Billion, with $10 Billion from North America.

Game Programmer Bob
Wednesday, June 16, 2004

"I'd be willing to bet that 10 years from now, many, if not all, games will be written in a managed memory environment."

Only if they don't mind having a variable frame rate - if you can't control when and where memory is deallocated it will happen when you don't want it to. Which is fine for most apps but games need to be smoothly hitting 50/60 Hz and generally have no room to spare in doing so.

Games manage their own memory because it's important to them. You have a highly limited amount of memory on a console - and if you want to be the best you had better get the best out of it.

Mr Jack
Thursday, June 17, 2004

Also note that these are only _ticket sales_. The movie industry makes tons of extra cash on DVD/VHS sales and rentals, plus broadcasting rights, plus merchandise such as action figures, posters, t-shirts...

Some industry lobbyist came up with this "games are bigger than movies" nonsense a while back, and since then it's been quoted all over the place, but it's never been true. Games are still way smaller than movies.

Chris Nahr
Thursday, June 17, 2004

That was a reply to GP Bob, obviously...

Chris Nahr
Thursday, June 17, 2004

"Well you'll lose that bet, because the majority of titles are written for the console, not the PC, and the next generation Sony and Nintendo machines have mentioned nothing about putting an OS in them let alone some kind of memory management scheme. Sony's API's have always been absolute bare-bone, you (have to) control everything down to what goes on what bus and when."

Sony or the console maker doesn't have to provide the managed-memory environment.  A game developer may write their own or a third party may provide one. It could be included on the game disc and the game itself would run on top of it.

Remember we are talking about 10 years from now.  10 years ago the typical new PC was 66MHz and had 4MB of RAM.  Now they are 3GHz and 512 MB.  Consoles have expanded in power at a similar rate.  If consoles have 50 gigs of memory and have the equivalent processing power of 100GHz (of course, actual 100GHz may be infeasible due to the extreme heat it would generate), the productivity gains from managed memory may very well outweigh the performance hit even for game consoles.

T. Norman
Thursday, June 17, 2004

"Miles: It's not that there's enough memory, is that memory is constantly getting allocated and deallocated, and I need control over it.  I can't leave it up to a GC to do it for me."

Can you go into why unmanaged memory usage is crucial for this project?  Off the top of my head; I can't really think of a reason.

Jason McCullough
Friday, June 18, 2004

Jason:  unmanaged memory is crucial because I'm allocating large (400mb, in some cases) blocks of memory, and need to be able to control when those appear and disappear.  Also, when generating transition matrices to get statistics for objects, those matrices can be large for large datasets.

The devil is in the details, and in this case, the details are how the edge conditions of large images (large in spatial and large in temporal) are handled.  I can't afford to be sloppy with hundreds of megabytes.

mmr
Friday, June 18, 2004

>> the productivity gains from managed memory may very well outweigh the performance hit

TT. Norman, you're lettiing the unix mentality creep into windows land.  The two things you list are not hitting the same party.  The productivity gain affect the developer only, and not by more than 1 or 2 percent.  Anyone who claims that memory mgt is taking a significant chunk of development time is simply deluding themselves and others for the sake of an agenda.  And for this minicule gain, they make the customer pay dearly.

Gunnar Skogsholm
Saturday, June 19, 2004

The game industry argument is completely invalid because there are probably no-more than 5 major game engines and I doubt that there are more than 50 developers involved in them.  Even less in the actual memory management part of the code.

Most people working on games are all the designers - levels, characters, storyline, sound, speech, etc.; testers and what not.

For every John Carmack there are million others that just want to slap a new body and face textures to the characters.

tekumse
Monday, June 21, 2004

*  Recent Topics

*  Fog Creek Home