Because the issue lies in the multiple invocations to free() memory that you HAVE TO MAKE in a C programming model. The problem is FUNDAMENTAL to the usage pattern, not just the allocation model. Freeing all at once instead of multiple times is smarter and cheaper.
That said, pretty much all malloc allocation algorithms are slower than generational GCs PURELY at allocation since mallocs have to find a good fit on the heap whereas generational GCs have contiguous free space and allocation can be done with a simple pointer addition. It doesn't get any cheaper than that, and malloc simply CANNOT match that unless you're dealing with an infinite memory space and you never call free().
Seriously, go read the literature - you're just repeating all the same old myths which have been refuted for years now (generation GC came in with Java 1.2 for christ's sake!)
This isn't a C versus Java discussion - it's Objective-C versus Objective-C with GC discussion, so your point is completely irrelevant as both OC with and without GC have stack allocation.
That said, *yes* stack variables allow a certain amount of programmer optimisation not explictly available to Java programmers, *but* that is all optimisation that the JVM can do via escape analysis (but you knew that, didn't you?). What's more, that kind of analysis can allow a JVM to optimise values onto the stack depending on usage - something not at all possible with C's ahead-of-time compiler.
You really are going a long way to split hairs. Saying that malloc isn't part of C is like saying that printf isn't part of C - yes, it's in a library, but it's pretty fundamental to most C programmers (it's in K&R after all).
Still, if being a pedant helps you avoid thinking, all power to you. I hope that sand is keeping your ears warm.
I've been coding C for just under twenty years and I can tell you, you're wrong. Modern GC's allocate faster than C's malloc routine. Java does tend to allocate more than euqivallent C programs due to the lack of programmer access to the heap, but that's Java's choice (and not one that a smart JVM can't work around anyway). BUT, we weren't discussing Java, we were discussing GC, and the fact is that modern GC is more often faster than explicit memory allocation and de-allocation (this has been proven multiple times, go Google for it if you care to educate yourself). Dealing with memory yourself is a huge benefit for about 1% of real code, for the rest it's just an area to make unneccesary errors in for no gain.
That anyone could refer to other human beings as cockroaches to be eradicated and be modded 5 - Insightful is as disgusting an indictment on Slashdot as anything I could imagine.
You disgust me and the retarded fucks who modded you up for this hate speech need their heads read.
I fully agree with that. The fact is that, on average, Java is still a wee bit slower than C++ (ranging between 70-105% last time I micro benchmarked - which was with Java 1.4) My point was only that it is not true by definition that something written in C cannot be faster than an ahead-of-time compiled C program. And in fact, in some (admitedly small) cases that actually happens right now.
JITting can produce higher performance than ahead-of-time compiled code, which is one of the ways in which a language coded in C can run faster than the same code in C. All you need is a problem with a lot of runtime constants in big oft-repeated loops and you're there.
Not really true. Runtime optimisations aren't really possible in C unless you think that implementing a runtime C compiler (and ignoring CPU cache flushes for re-writing code) is something you should consider as part of normal C code optimisation.
Microsoft have released several updates to DX which are substantial upgrades and have done this on existing machines.
It's a fucking API. APIs are DESIGNED to provide functionality over a potentially changing base implementation. In JUST THE SAME WAY DirectX has ALWAYS done it and OPENGL does it RIGHT now.
If you beleive that crock of shit in the article, you are seriously deluded.
SCEE PR manger Jennie Kong blasted the rumor as " false speculation." "PlayStation 3 software will not be copy protected to a single machine but will be playable on any PlayStation 3 console,"
The story is a lie. Clearly Slashdot editors hate Sony enough that any slander they come across is promoted immediately to a top level article.
I think you'll find that this is patently, provably false. If they were equivallent, the market would be using these clean room implementations now. The fact that they're not, and that people call for Sun to OSS SUN Java proves that there's a difference according to the market.
Slashdot Mirror
here's an IBM article which explains why GC has performance wins (a little old now, but still good)
t p01274.html
http://www-128.ibm.com/developerworks/library/j-j
Because the issue lies in the multiple invocations to free() memory that you HAVE TO MAKE in a C programming model. The problem is FUNDAMENTAL to the usage pattern, not just the allocation model. Freeing all at once instead of multiple times is smarter and cheaper.
That said, pretty much all malloc allocation algorithms are slower than generational GCs PURELY at allocation since mallocs have to find a good fit on the heap whereas generational GCs have contiguous free space and allocation can be done with a simple pointer addition. It doesn't get any cheaper than that, and malloc simply CANNOT match that unless you're dealing with an infinite memory space and you never call free().
Seriously, go read the literature - you're just repeating all the same old myths which have been refuted for years now (generation GC came in with Java 1.2 for christ's sake!)
This isn't a C versus Java discussion - it's Objective-C versus Objective-C with GC discussion, so your point is completely irrelevant as both OC with and without GC have stack allocation.
That said, *yes* stack variables allow a certain amount of programmer optimisation not explictly available to Java programmers, *but* that is all optimisation that the JVM can do via escape analysis (but you knew that, didn't you?). What's more, that kind of analysis can allow a JVM to optimise values onto the stack depending on usage - something not at all possible with C's ahead-of-time compiler.
I am *well* aware of that.
You really are going a long way to split hairs. Saying that malloc isn't part of C is like saying that printf isn't part of C - yes, it's in a library, but it's pretty fundamental to most C programmers (it's in K&R after all).
Still, if being a pedant helps you avoid thinking, all power to you. I hope that sand is keeping your ears warm.
I've been coding C for just under twenty years and I can tell you, you're wrong. Modern GC's allocate faster than C's malloc routine. Java does tend to allocate more than euqivallent C programs due to the lack of programmer access to the heap, but that's Java's choice (and not one that a smart JVM can't work around anyway). BUT, we weren't discussing Java, we were discussing GC, and the fact is that modern GC is more often faster than explicit memory allocation and de-allocation (this has been proven multiple times, go Google for it if you care to educate yourself).
Dealing with memory yourself is a huge benefit for about 1% of real code, for the rest it's just an area to make unneccesary errors in for no gain.
*sigh*
I grew up programming in assembler and C. Even dinosaurs like myself know that memory allocation is not an issue for 99% of software projects.
Get with the new century dude.
Why?
I hope your hatred keeps you warm at night.
That anyone could refer to other human beings as cockroaches to be eradicated and be modded 5 - Insightful is as disgusting an indictment on Slashdot as anything I could imagine.
You disgust me and the retarded fucks who modded you up for this hate speech need their heads read.
The difference is that your allies used to like you.
I fully agree with that. The fact is that, on average, Java is still a wee bit slower than C++ (ranging between 70-105% last time I micro benchmarked - which was with Java 1.4) My point was only that it is not true by definition that something written in C cannot be faster than an ahead-of-time compiled C program. And in fact, in some (admitedly small) cases that actually happens right now.
JITting can produce higher performance than ahead-of-time compiled code, which is one of the ways in which a language coded in C can run faster than the same code in C. All you need is a problem with a lot of runtime constants in big oft-repeated loops and you're there.
Not really true. Runtime optimisations aren't really possible in C unless you think that implementing a runtime C compiler (and ignoring CPU cache flushes for re-writing code) is something you should consider as part of normal C code optimisation.
Zonk hates the PS3 and loves XBOX360. Move on!
The US did not invent the internet. The web is for most people 'the internet' and that was invented by a Brit.
Calling moronic comments moronic is not juvenile, it's just stating facts.
Killer argument, you must be proud of yourself.
I'm 35, and a veteran software engineer, by the way. But keep working on those ESP skills.
You are a moron.
Microsoft have released several updates to DX which are substantial upgrades and have done this on existing machines.
It's a fucking API. APIs are DESIGNED to provide functionality over a potentially changing base implementation. In JUST THE SAME WAY DirectX has ALWAYS done it and OPENGL does it RIGHT now.
If you beleive that crock of shit in the article, you are seriously deluded.
And if you believe that BS, you would have to be a M$ fanboy (or a moron) - you choose.
..and more importantly, it would avoid the editor's rather obvious biases.
This is complete and utter BS. JVM startup on Windows is just over one second - I just tested a hello world app 1.125 sec.
I was more concerned with the fact that it was a dull shooter on rails. But yes, the story was rather limited as well.
SCEE PR manger Jennie Kong blasted the rumor as " false speculation." "PlayStation 3 software will not be copy protected to a single machine but will be playable on any PlayStation 3 console,"
The story is a lie. Clearly Slashdot editors hate Sony enough that any slander they come across is promoted immediately to a top level article.
I think you'll find that this is patently, provably false. If they were equivallent, the market would be using these clean room implementations now. The fact that they're not, and that people call for Sun to OSS SUN Java proves that there's a difference according to the market.