Linked by kragil on Wed 23rd Jan 2013 20:26 UTC
Google "Native Client enables Chrome to run high-performance apps compiled from your C and C++ code. One of the main goals of Native Client is to be architecture-independent, so that all machines can run NaCl content. Today we're taking another step toward that goal: our Native Client SDK now supports ARM devices, from version 25 and onwards."
Thread beginning with comment 550554
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[12]: Comment by Laurence
by satsujinka on Sat 26th Jan 2013 09:13 UTC in reply to "RE[11]: Comment by Laurence"
satsujinka
Member since:
2010-03-11

Any of the tricks a system allocator is capable of is also possible in a GCed language. It's not like the algorithms are only possible by the system (and if they were the runtime can just use the system allocator.)

Further, in practice it turns out that you're completely incorrect about fragmentation. GCed languages have less issues with fragmentation.

GC may have a base cost that's higher than manual memory management, but it can be pushed into the same ranges as manual memory management, even if it takes more work to do so. That's the trade off, GC makes life easy when you don't care, but makes life more difficult if you need the performance. But sacrificing GC for some dubious performance gain is not good engineering (though choosing a language with optional GC would be a good decision if you know you'll have performance issues, if only because it gives you more options.) So: write the code with GC, profile it, tune your code, repeat; if after a certain number of iterations you still can't get the performance you need disable the GC in that section or drop down to C or assembly and rewrite your bottlenecks there.

Reply Parent Score: 2