Alternatives to C/C++

Instead of sticking with C/C++ for performance consider:
1.Free Pascal -Small memory use,very fast, easy debug
2.OCaml - medium memory use, fast,very terse, functional and secure.
3.FreeBasic - very fast,easy to use, low memory use, supports QBasic code as dialect. Other Basics to consider: PureBasic/Gambas/PowerBASIC
4.Digital Mars D- fast, easy to write and debug, large library, transition from C/C++ much easier.Garbage collection can be turned off.

audomatic
I'm having trouble wrapping my head around the mechanics of that typo... anyway...

>>54
I was off. It was this:

http://www.joelonsoftware.com/articles/fog0000000319.html
Eventually, the free chain gets chopped up into little pieces and you ask for a big piece and there are no big pieces available the size you want. So malloc calls a timeout and starts rummaging around the free chain, sorting things out, and merging adjacent small free blocks into larger blocks. This takes 3 1/2 days. The end result of all this mess is that the performance characteristic of malloc is that it's never very fast (it always walks the free chain), and sometimes, unpredictably, it's shockingly slow while it cleans up. (This is, incidentally, the same performance characteristic of garbage collected systems, surprise surprise, so all the claims people make about how garbage collection imposes a performance penalty are not entirely true, since typical malloc implementations had the same kind of performance penalty, albeit milder.)
The claim is not speed, but collection stutter. The problem with this is that calling malloc during RT events (eg. in signal handlers, say... vblank) is verboten, literally incorrect. So your stutter never has an opportunity to happen at the wrong time (with video games don't think Linux, think gaming consoles. Sometimes developers would even use hblank handlers to get more sprites on the screen, or whatever zany effects--with NTSC you have something like ~0.07ms to get the job done.) Compare with Java's GC which (last I had the pleasure) runs whenever the hell it wants, usually long after the program has exhausted its heap and stalled for over an hour (I wish I was joking. Things must have improved by now, yes?)

Even if you aren't in a handler (or re-entrant call or whatever) manual management makes it easy to avoid triggering collection processes at the wrong time. So the characteristic is subtly but fundamentally different because you must decide when to risk collection. I can't stress that enough, but the BBCode is garish enough as it is.

Not to mention the malloc he refers to is old enough that it makes dlmalloc¹ look the very picture of sophistication. This lovely little gem is more or less what you get if you use newlib (cygwin, msys), glibc, etc.

Of course you can talk to your GC and tell it when to shut up or prod it to run whenever you want it to and fine tune it this way and that depending on your language, implementation and so on. It's perfectly reasonable to do so, but just because you can doesn't mean it's all been made a non-issue. It's still essentially harder to constrain GC finely in auto-GC languages (at least when using the auto-GC -- though it really doesn't have to be this way, and there may be a few exceptions. Someone is going to say something long and involved about Lisp now. Easy!)

_{^{1. http://en.wikipedia.org/wiki/Malloc#dlmalloc_and_its_derivatives}}