Agreed on all of the above. The upshot for PNaCl is:

1) Unreliable performance characteristics have to be traded off against not allowing all programs to run, as you note.
2) Sandboxing is a problem.
3) Actually getting it to run on a new architecture involves implementing the relevant LLVM virtual machine, not just writing the LLVM-to-native compiler you were probably writing anyway.

The message in question is http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html

LLVM is only expressive enough to have C++ compiled to it if you use the parts of LLVM that are architecture-dependent. In particular, they depend on word sizes and endianness at the very least. You can't compile C++ to architecture-independent LLVM.

See http://news.ycombinator.com/item?id=2499763 for some links to the relevant LLVM documentation.

Now of course you can take any LLVM target you want and define a virtual machine for that target. Heck, you could define a virtual machine whose "bytecode" is x86 assembly. Whether such things are "suitable" or good for the web is a separate question entirely.

Chrome is not in fact open source. It includes a bunch of open source code but also various closed-source components. Perhaps you confused Chrome and Chromium? They're not the same thing.

If you compile Chrome yourself, you're not using Chrome, of course (and in particular, some features that this particular security evaluation ticks as positives, like the bundled Flash, will be missing).

(There's the side issue that compiling yourself gives you no particular guarantees either if your compiler is in cahoots with the code you're compiling, but for now the chances of that for Chrome are low.)

> You have to go out and download it to get it on your
> computer.

As it happens, this is not true, and was even less true last year, before Microsoft bought Skype. See http://en.wikipedia.org/wiki/Google_Chrome#Bundling_practices for a brief summary, but there's plenty of information on this out there if you go to look for it.

> What should I do with the nightlies?

You were saying you see startup being slow when it didn't use to be slow, right? What would be good is testing the various nightlies to see which one is the first one that appears.

I really have no idea what the issue could be here, hence trying to gather more data.

Mostly additions, but it turns out that the way web apps are written adding new APIs can easily break them....

I totally understand not being willing to stick python on your machines.

If you're willing to, you can also manually download nightlies from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ (you want the dated directories ending in "mozilla-central"). Again, I understand if you don't want to put in the time to do this; it's just that we do have AMD test machines and they're not showing the symptoms you describe....

I believe every single one of Firefox 5, 6, 7, 8, 9, 10 had changes to web standards support... That's one of the reasons the version numbers are what they are.

That's really odd. If you're willing to spend a bit of time on this and have a machine on which performance noticeably dropped from one Firefox release to another, would you be willing to use http://harthur.github.com/mozregression/ to find when exactly that drop happened? That would be incredibly useful!

What sort of AMD chip are you using? Does it have SSE2 support?

For some workloads, I can definitely see a P4 with SSE2 blowing away a processor that doesn't have SSE2.... Some of those workloads can include "JS execution", because at least some JS jits depend on having SSE2 instructions (the alternative being to have a whole bunch of extra code to do x87 codegen).