Exactly, which is why PNaCl is superior at the end of the day. Good luck trying to jam multi-threaded, shared memory programming into JS. The standards committee itself already hate JS (but they maintain it for the "good of the web"). Don't even think about getting the standards committee to even think about a shared memory (webworkers with ArrayObject ownership transfer is as much of a concession as anyone's ever going to get). All JS VMs will have to be written from scratch just to support this programming model.

That's because:

• 1) The code being benchmarked and compared against usually aren't production code, and are tight for-loops that're easy to optimize -- i.e. hit the cache all the time due to small code/data size, simple instruction mix, lack of SIMD comparisons, no real memory allocations, etc....
• 2) If it's a section of full production code and the results are similar, then "native" code is most likely nowhere near optimal to begin with. Just because it's "native" doesn't mean it's good. One can still write really shitty code in C/C++, i.e. triple nested vectors.
• 3) And if it's not complete shit and the "native" code still runs close to JS performance, then the programmer in question probably doesn't have as much experience optimizing for instruction mix, L1/L2 cache hit, pipeline balancing, software pipelining, etc....

I haven't seen any non-trivial high level code come close to real optimized C.

Asm.js is basically a somewhat limited (wrt native hardware capabilities) bytecode format in human-read/writeable form. Mozilla is resisting hard because it's just like the GP said -- their architecture isn't suited for Pepper. And as Mozilla tries to solve the multi-threading/SIMD/(u)int64 issue, it just looks more and more like (P)NaCl. I guess the nice thing about asm.js is that it doesn't require such a large upfront cost.

Are you talking about self-modifying code? You can certainly do that in C, but just much, much more involved.

Are you're still living in the 90s? Or is that supposed to be tongue-in-cheek?

This is one of those things that's not necessarily true (usually true in a managed memory environment, though). If you have control to the OS functionality of memory and know your memory usage pattern, then you can actually reserve a lot of virtual memory pages in advance. Only the committed ones will consume physical memory -- in other words, you can expand your array by committing subsequent pages. And since we haven't gotten to the point where computers actually have 2^64 bytes of memory, we don't need to worry too much about running out of address space.

Or maybe people should just stop using so much templates, and use code generation instead. Oh, and also supporting the Apple/LLVM initiative to modularize C++ would be double plus good too (think #import in C++).

Please do explain if possible -- I'm very interested in reading the explanation. However, I have to admit I have the preconception of "we're not letting you play video games because this is for your own good."

Troll fail often? iPad and iPhones tend to have the top of the line internals at the time of release, CPU and GPU (they do skimp on RAM, though). If it wasn't for them maintaining screen resolution to help developers, they probably would've held on to the highest res screens title as well.

Well, it doesn't matter -- I thought the point is that everyone is born with sin. Therefore, Jesus's point is that no one should be casting anything, including magic missiles.

Ok how? I don't believe YouTube monetizes your videos (read: the ones you hold copyrights to, barring an unlawful claim to your original work) unless you explicitly tell it to.

Sure, there is a case as you pointed out -- people sitting on the fence will chose DRM when given the option. But did having a way to explicitly monetize help or dimish the App Store? I would argue if anything, the platform allowed Apple's ecosystem to flourish (let's not get into the whole walled garden argument).

Furthermore, if DRM is a form of economic protectionism, then so are the police who make sure people don't steal. Is that anti-competitive? Sure, for the thieves. But that doesn't mean it's discouraging economic participation.

If you honestly think that is one practical way, then I really don't see how you're being reasonable and not just nitpicking. If you think the standards people want to use this as a way to hijack the openness of the browser in general, that's probably the tin foil hat letting in the mind controlling waves.

If that is the case, then everyone would've turned on DRM and monetized all their videos on YouTube (you can already do that now, you know?). Since that isn't the case, I don't see how your argument fits observed human behavior.

Right, obfuscation. Still hackable, just like EME. If the Content Decryption Module is sitting on your machine, you can still attach a debugger to it. Just...how much work do you want to spend? This is the same issue in all DRM schemes -- someone can break it, but it'll require a lot of effort to do so. And also, by your example, does that mean you want more EME?