There are several probalems with that idea. First, C allows you to do arbitrary things to the point where it's very much not amenable to sandboxing. And I'm not talking about the standard library. Most simply, you can fill memory with binary code and then jump to it directly. Now we can talk about ways to restrict the C code you can write so as to mitigate things like this, restrict which pages are writable and which are executable, etc, etc, but it won't be quite C anymore, and the exact language subset it will actually be needs to be defined. And all of this will just convert execution of arbitrary code into a SIGSEGV, which is not great for a "sandbox" either.
Second, compiling C is not necessarily all that fast. Compile time does matter for the web. I would welcome data about relative compile speeds of C and JS, though; I don't have hard data on this.
Third, how do you propose dealing with memory leaks? Given what most web JS looks like, I would NOT be trusting these people to not leak in their C code. You see GC as an overhead; I see it as a required part of the sandbox.
Fourth, the browser would have to ship a C compiler, linker, etc, since most end-user systems don't have one. Doable, obviously, but C compilers are not small things.
Fifth, the cost of downloading C source code that does the equivalent of what a major web app does today in JS could be prohibitive: JS is a much higher language than C and tends to be a lot more concise, even when authored in brain-dead ways.
Sixth, writing actual portable C is not all that easy, especially because a lot of tutorials recommend doing various non-portable stuff. I very much doubt, again based on the quality of the JS I see on the web, that this would happen. If you're lucky, this would just mean that the site in question would not work right on 64-bit (or 32-bit, or big-endian, or little-endian, or whatever) hardware. If you're not lucky, it will crash.
What you propose is perhaps worth it, but C is the wrong language. Then you have to ask yourself what the right language is, and whether it's easier to create it or to evolve JS in the direction of being that right language under opt-ins of various sorts: ES5 strict mode, which disallows some hard-to-optimize stuff, the various Harmony proposals, and so forth.
Oh, I don't think gcc is the best compiler by any means, especially since I have good data to the contrary. As you say, MSVC has much better code generation.
But on simple numeric benchmarks, GCC does produce pretty good code, as does any other sane compiler. The point being that these benchmarks are _simple_ and hence easy to optimize.
> Your comparison to gcc optimization levels is apples >. and oranges,
Well... any inter-level comparison is, to some extent.
> it's a bit misleading
How so?
> I'd be interested in hearing where you got your > information.
Which information? The performance numbers? I wrote some code, and then timed how long it takes to run: the usual way.;)
> Getting wider spread support of different types of > scripts more universally accepted and adding > proper DOM handling libraries and runtime > isolation to them sounds like a good solution > to me.
It also greatly expands the complexity of the VM: for example now you have to deal with GC across multiple language runtimes. Even just GC across the two languages in modern browsers (JS and C++) is a huge pain...
For what it's worth for a while there Gecko supported python for extension authors. No one used it; the support has now been removed as a result (since it made the code more complex and slowed down things people _did_ use). It'll be a hard sell to convince us to put the functionality back given that experience.
For what it's worth, V8 is also not a good indicator of the performance of real web pages.
In fact, no such good indicator exists yet even for today's pages, much less tomorrow's (which is what you _really_ want out of a benchmark: driving improvement where it will help the most with the things you plan to do once the improvement has happened).
It really just depends on your code and on your compiler.... and on your hardware.
My personal experience is that the same code was fastest with -Os on hardware as of 7 years ago and when compiling with GCC 4.0 (due to i-cache effects, as near as anyone could tell) but fastest with -O3 on hardware as of a year ago and when compiling with GCC 4.5....
> I don't recall gcc -O3 and -O0 having a factor of 10 > difference for most tasks.
They don't. My comment was quite specific: the cited numbers are simple number-crunching code. The fact that -O0 stores to the stack after every numerical operation while -O3 keeps it all in registers is the source of the large performance difference as long as you don't run out of registers and such. The stack stores are also the gating factor in the code generated by Tracemonkey, at least.
> And Javascript definitely isn't close to C > performance, even unoptimized.
For simple number-crunching code, Tracemonkey as shipping in Firefox 4 runs at the same speed as C compiled with GCC -O0, in my measurements. I'd be happy to point you to some testcases if you really want. Or do you have your own measurements that you've made that are the basis for your claim and that you'd care to share?
Note that we're talking very simple code here. Once you start getting more complicated the gap gets somewhat bigger.
As an example of the latter, see https://github.com/chadaustin/Web-Benchmarks which has multiple implementations of the same thing, in C++ (with and without SIMD intrinsics) and JS with and without typed arrays. This is not a tiny test, but not particularly large either.
On my hardware the no-SIMD C++ compiled with -O0 gives me about 19 million vertices per second. The typed-array JS version is about 9 million vertices per second in a current Firefox 4 nightly.
For comparison, the same no-SIMD C++ at -O2 is at about 68 million vertices per second. -O3 gives about the same result as -O2 here; -O1 is closer to 66 million.
> Besides, gcc -O3 can actually be somewhat > slower than -O2
Yes, it can, depending on cache effects, etc. For the sort of code we're talking about here it's not (and in fact typically -O2 and -O3 generate identical assembly for such testcases. See the numbers above.
One other note about JS performance today: it's heavily dependent on the browser and the exact code and what the jit does or doesn't optimize. In particular, for the testcase above V8 is about 30% faster than Spidermonkey on the regular array version but 5 times slower on the typed array version (possibly because they don't have fast paths in Crankshaft yet for typed arrays, whereas Spidermonkey has made optimizing those a priority).
Again, I suspect that things will look somewhat different here in a year. We'll see whether I'm right.
gcc compiles C to native code, but there's a noticeable speed difference between compiling with -O0 and -O2 for most C code.
There are plenty of things people are doing in JS nowadays where the DOM is only a limiting factor because JS implementations are 10x faster than they were 4 years ago...
LLVM is not target-architecture-independent, last I checked. For example, you can't use the same LLVM bitcode on both big-endian and little-endian hardware. Or use the same LLVM to produce both x86-32 and x86-64 binaries.
Or has that changed? I admit I haven't looked in a year or so.
Modern JS jits (tracemonkey, crankshaft) seem to be able to get to within about a factor of 10 of well-optimized (gcc -O3) C code on simple numeric stuff. That's about equivalent to C code compiled with -O0 with gcc, and actually for similar reasons if you look at the generated assembly. There's certainly headroom for them to improve more.
For more complicated workloads, the difference from C may be more or less, depending. I don't have any actual data for that sort of thing, unfortunately.
Look, everyone understands the Nobel Peace Prize is a joke. Many people/organizations who get it really deserve it. But laureates have also included Al Gore, Henry Kissinger, Jimmy Carter, Yasser Arafat, the UN, UNHCR, and a few other questionables (your list of questionables may obviously differ from mine). Obama's case is more glaring than most of those because for the most part the laureates had done things (even if what they did was to kill lots of people and then stop)....
But you're tarring with a broad brush if you think that all the Nobel prizes work the way Peace does. The difference is in who's doing the awarding. The Physics, Chemistry, Medicine, and Literature Nobels are awarded by the Swedish Academy of Sciences (which hands out physics and chemistry), the Karolinska Institute (a medical university), and the Swedish Academy (which consists of people who actually deal with language for a living).
In all four of those cases, the prize-awarding body selects a small committee to propose laureates, then take a vote in a much bigger group (the full membership for the two academies and a 50-person group appointed for the purpose at the Karolinska Institute.
For peace, on the other hand, the selection is done entirely by the 5 members of the committee, who are not in the business of "peace" themselves but are effectively political appointees (appointed by the Norwegian Parliament).
So the peace prize process is really sort of set up to fail to start with, compared to the other four.... It's a pleasant surprise that it doesn't fail more often than it actually does.
That's being done. Firefox 4 Mobile will be shipping with out-of-process tabs. Firefox 4 for all versions has out-of-process plug-ins. Desktop Firefox will be getting out-of-process tabs as soon as the UI is fixed to work with them (the back end is all done, since it's shared with Firefox Mobile).
From what I've seen in elections in general, it doesn't take that much to elect "extremists" as long as you hate the other guy.
The conditions for hating the other guy have been around since 1948 at least in this case; possibly somewhat earlier.
The Nazi rise to power is interesting, since it depended strongly on electoral politics winning out over the old-style aristocracy. Once that sort of thing happens, you get mob rule; the only question is what will get the mob fired up.
Which is why most functioning democracies have systems of checks and balances (both official and not) of various sorts to prevent elected leaders from effectively doing what the electorate wanted them to do, such that the only way to get things to happen is for the electorate to want them for a good long while (a generation or so).
Punishing people as a group for the actions of their freely elected government does not in fact strike me as collective punishment. Israel has certainly engaged in collective punishment in the past, but the Gaza/Hamas example seems poorly chosen.
If you allow that as an example of collective punishment, then would you consider economic sanctions collective punishment? What about imposing tariffs that lead to unemployment and hardship in the target country?
What about a declaration of war against an a country that has a draft?
Heck, is there any way you can think of to prosecute a war at all without effectively engaging on collective punishment?
I agree that it would be really nice if wars weren't fought, of course. But I don't see how one can be fought with modern weapons between modern states or any semblance thereof without ending up in collective punishment territory, with the exception of blitzkrieg campaigns with limited objectives like the 1967 Arab-Israeli war (and even that arguably had collective punishment as part of the consequences)...
> There aren't many fundamentalists compared to > moderates
Is this gut feeling, or do you have data? If the latter, can you cite?
Also, do note that "moderate" might mean different things in different places if you're simply defining it in terms of the population median. If that's the case, you may be interested in http://blogs.discovermagazine.com/gnxp/2011/02/egypt-vs-indonesia-in-attitudes/ and can of course not provide data to support the initial claim, since it becomes true by definition.
> Stop the cycle of violence. BE the bigger man you > claim you are.
This is a lot easier to do if you have strategic depth, for what it's worth. Or even tactical depth. Both commodities are unfortunately in short supply in the Middle East....
To become a Recommendation (which is the 2014 date here), a standard has to be written, then an exhaustive test suite for it needs to be created, and then two implementations need to pass the test suite.
The goal is apparently to be done with that first step this year; the expectation is that writing the hundreds of thousands of tests and then fixing the thousands of browser bugs that they will uncover will take several years.
I suspect that the 2014 timeframe is too optimistic, personally.
Dirac is meant to be a high-quality codec, period; it was largely designed for archival work. It makes no particularly strong effort to be low-bitrate in the process.
The result is that at high bitrates it's pretty good (and even offers lossless compression, etc). At the bitrates at which people normally serve internet video today, it's worse quality than Theora, I'm told. But this is third-hand, so don't take my word for it.
As bandwidth goes up, Dirac might find a place on the web, but we're not there yet.
Well, it's quite possible to not have inflation even if you print money like mad if people immediately hide the money under their mattress.
Our inflation measures have some quirks, but they're not that bad. As long as you don't mistake inflation for changes in cost of living, of course... But that starts getting back to how you define "inflation".
Slashdot Mirror
There are several probalems with that idea. First, C allows you to do arbitrary things to the point where it's very much not amenable to sandboxing. And I'm not talking about the standard library. Most simply, you can fill memory with binary code and then jump to it directly. Now we can talk about ways to restrict the C code you can write so as to mitigate things like this, restrict which pages are writable and which are executable, etc, etc, but it won't be quite C anymore, and the exact language subset it will actually be needs to be defined. And all of this will just convert execution of arbitrary code into a SIGSEGV, which is not great for a "sandbox" either.
Second, compiling C is not necessarily all that fast. Compile time does matter for the web. I would welcome data about relative compile speeds of C and JS, though; I don't have hard data on this.
Third, how do you propose dealing with memory leaks? Given what most web JS looks like, I would NOT be trusting these people to not leak in their C code. You see GC as an overhead; I see it as a required part of the sandbox.
Fourth, the browser would have to ship a C compiler, linker, etc, since most end-user systems don't have one. Doable, obviously, but C compilers are not small things.
Fifth, the cost of downloading C source code that does the equivalent of what a major web app does today in JS could be prohibitive: JS is a much higher language than C and tends to be a lot more concise, even when authored in brain-dead ways.
Sixth, writing actual portable C is not all that easy, especially because a lot of tutorials recommend doing various non-portable stuff. I very much doubt, again based on the quality of the JS I see on the web, that this would happen. If you're lucky, this would just mean that the site in question would not work right on 64-bit (or 32-bit, or big-endian, or little-endian, or whatever) hardware. If you're not lucky, it will crash.
What you propose is perhaps worth it, but C is the wrong language. Then you have to ask yourself what the right language is, and whether it's easier to create it or to evolve JS in the direction of being that right language under opt-ins of various sorts: ES5 strict mode, which disallows some hard-to-optimize stuff, the various Harmony proposals, and so forth.
There are effectively no US assets in China. Foreigners aren't allowed to own Chinese real estate, etc, etc.
You can if they're doing certain things in the US. See the references to the Foreign Sovereign Immunities Act elsewhere in this thread.
Note, by the way, that a similar question can be raised about the International Criminal Court, the International Court of Justice, etc.
Not quite territorial. Tribal. There's your tribe, and the Others. And you have to protect your tribe from those Others....
Yes, which is precisely the point. On Mac there is no way to easily do 2d hardware acceleration at the moment.
There's an implementation of ECMAScript called "V8". There's also a particular benchmark called "V8". You can thank Google for that naming snafu.
> Well... any inter-level comparison is, to some extent.
I meant inter-language.
Oh, I don't think gcc is the best compiler by any means, especially since I have good data to the contrary. As you say, MSVC has much better code generation.
But on simple numeric benchmarks, GCC does produce pretty good code, as does any other sane compiler. The point being that these benchmarks are _simple_ and hence easy to optimize.
> Your comparison to gcc optimization levels is apples
>. and oranges,
Well... any inter-level comparison is, to some extent.
> it's a bit misleading
How so?
> I'd be interested in hearing where you got your
> information.
Which information? The performance numbers? I wrote some code, and then timed how long it takes to run: the usual way. ;)
> Getting wider spread support of different types of
> scripts more universally accepted and adding
> proper DOM handling libraries and runtime
> isolation to them sounds like a good solution
> to me.
It also greatly expands the complexity of the VM: for example now you have to deal with GC across multiple language runtimes. Even just GC across the two languages in modern browsers (JS and C++) is a huge pain...
For what it's worth for a while there Gecko supported python for extension authors. No one used it; the support has now been removed as a result (since it made the code more complex and slowed down things people _did_ use). It'll be a hard sell to convince us to put the functionality back given that experience.
For what it's worth, V8 is also not a good indicator of the performance of real web pages.
In fact, no such good indicator exists yet even for today's pages, much less tomorrow's (which is what you _really_ want out of a benchmark: driving improvement where it will help the most with the things you plan to do once the improvement has happened).
It really just depends on your code and on your compiler.... and on your hardware.
My personal experience is that the same code was fastest with -Os on hardware as of 7 years ago and when compiling with GCC 4.0 (due to i-cache effects, as near as anyone could tell) but fastest with -O3 on hardware as of a year ago and when compiling with GCC 4.5....
I'm very sure, yes.
> I don't recall gcc -O3 and -O0 having a factor of 10
> difference for most tasks.
They don't. My comment was quite specific: the cited numbers are simple number-crunching code. The fact that -O0 stores to the stack after every numerical operation while -O3 keeps it all in registers is the source of the large performance difference as long as you don't run out of registers and such. The stack stores are also the gating factor in the code generated by Tracemonkey, at least.
> And Javascript definitely isn't close to C
> performance, even unoptimized.
For simple number-crunching code, Tracemonkey as shipping in Firefox 4 runs at the same speed as C compiled with GCC -O0, in my measurements. I'd be happy to point you to some testcases if you really want. Or do you have your own measurements that you've made that are the basis for your claim and that you'd care to share?
Note that we're talking very simple code here. Once you start getting more complicated the gap gets somewhat bigger.
As an example of the latter, see https://github.com/chadaustin/Web-Benchmarks which has multiple implementations of the same thing, in C++ (with and without SIMD intrinsics) and JS with and without typed arrays. This is not a tiny test, but not particularly large either.
On my hardware the no-SIMD C++ compiled with -O0 gives me about 19 million vertices per second. The typed-array JS version is about 9 million vertices per second in a current Firefox 4 nightly.
For comparison, the same no-SIMD C++ at -O2 is at about 68 million vertices per second. -O3 gives about the same result as -O2 here; -O1 is closer to 66 million.
> Besides, gcc -O3 can actually be somewhat
> slower than -O2
Yes, it can, depending on cache effects, etc. For the sort of code we're talking about here it's not (and in fact typically -O2 and -O3 generate identical assembly for such testcases. See the numbers above.
One other note about JS performance today: it's heavily dependent on the browser and the exact code and what the jit does or doesn't optimize. In particular, for the testcase above V8 is about 30% faster than Spidermonkey on the regular array version but 5 times slower on the typed array version (possibly because they don't have fast paths in Crankshaft yet for typed arrays, whereas Spidermonkey has made optimizing those a priority).
Again, I suspect that things will look somewhat different here in a year. We'll see whether I'm right.
gcc compiles C to native code, but there's a noticeable speed difference between compiling with -O0 and -O2 for most C code.
There are plenty of things people are doing in JS nowadays where the DOM is only a limiting factor because JS implementations are 10x faster than they were 4 years ago...
LLVM is not target-architecture-independent, last I checked. For example, you can't use the same LLVM bitcode on both big-endian and little-endian hardware. Or use the same LLVM to produce both x86-32 and x86-64 binaries.
Or has that changed? I admit I haven't looked in a year or so.
Modern JS jits (tracemonkey, crankshaft) seem to be able to get to within about a factor of 10 of well-optimized (gcc -O3) C code on simple numeric stuff. That's about equivalent to C code compiled with -O0 with gcc, and actually for similar reasons if you look at the generated assembly. There's certainly headroom for them to improve more.
For more complicated workloads, the difference from C may be more or less, depending. I don't have any actual data for that sort of thing, unfortunately.
There _are_ things "wrong" with javascript that make it hard to optimize (lack of typing, very dynamic, etc). Things like http://blog.mozilla.com/rob-sayre/2010/11/17/dead-code-elimination-for-beginners/ (see the valueOf example) make it a bit of a pain to generate really fast code. But projects like https://wiki.mozilla.org/TypeInference are aiming to deal with these issues. We'll see what things look like a year from now!
Well, ok. Everyone I'd want to actually have a conversation with understands it's a joke. And some of them are even NGO members... ;)
Look, everyone understands the Nobel Peace Prize is a joke. Many people/organizations who get it really deserve it. But laureates have also included Al Gore, Henry Kissinger, Jimmy Carter, Yasser Arafat, the UN, UNHCR, and a few other questionables (your list of questionables may obviously differ from mine). Obama's case is more glaring than most of those because for the most part the laureates had done things (even if what they did was to kill lots of people and then stop)....
But you're tarring with a broad brush if you think that all the Nobel prizes work the way Peace does. The difference is in who's doing the awarding. The Physics, Chemistry, Medicine, and Literature Nobels are awarded by the Swedish Academy of Sciences (which hands out physics and chemistry), the Karolinska Institute (a medical university), and the Swedish Academy (which consists of people who actually deal with language for a living).
In all four of those cases, the prize-awarding body selects a small committee to propose laureates, then take a vote in a much bigger group (the full membership for the two academies and a 50-person group appointed for the purpose at the Karolinska Institute.
For peace, on the other hand, the selection is done entirely by the 5 members of the committee, who are not in the business of "peace" themselves but are effectively political appointees (appointed by the Norwegian Parliament).
So the peace prize process is really sort of set up to fail to start with, compared to the other four.... It's a pleasant surprise that it doesn't fail more often than it actually does.
That's being done. Firefox 4 Mobile will be shipping with out-of-process tabs. Firefox 4 for all versions has out-of-process plug-ins. Desktop Firefox will be getting out-of-process tabs as soon as the UI is fixed to work with them (the back end is all done, since it's shared with Firefox Mobile).
From what I've seen in elections in general, it doesn't take that much to elect "extremists" as long as you hate the other guy.
The conditions for hating the other guy have been around since 1948 at least in this case; possibly somewhat earlier.
The Nazi rise to power is interesting, since it depended strongly on electoral politics winning out over the old-style aristocracy. Once that sort of thing happens, you get mob rule; the only question is what will get the mob fired up.
Which is why most functioning democracies have systems of checks and balances (both official and not) of various sorts to prevent elected leaders from effectively doing what the electorate wanted them to do, such that the only way to get things to happen is for the electorate to want them for a good long while (a generation or so).
Punishing people as a group for the actions of their freely elected government does not in fact strike me as collective punishment. Israel has certainly engaged in collective punishment in the past, but the Gaza/Hamas example seems poorly chosen.
If you allow that as an example of collective punishment, then would you consider economic sanctions collective punishment? What about imposing tariffs that lead to unemployment and hardship in the target country?
What about a declaration of war against an a country that has a draft?
Heck, is there any way you can think of to prosecute a war at all without effectively engaging on collective punishment?
I agree that it would be really nice if wars weren't fought, of course. But I don't see how one can be fought with modern weapons between modern states or any semblance thereof without ending up in collective punishment territory, with the exception of blitzkrieg campaigns with limited objectives like the 1967 Arab-Israeli war (and even that arguably had collective punishment as part of the consequences)...
> There aren't many fundamentalists compared to
> moderates
Is this gut feeling, or do you have data? If the latter, can you cite?
Also, do note that "moderate" might mean different things in different places if you're simply defining it in terms of the population median. If that's the case, you may be interested in http://blogs.discovermagazine.com/gnxp/2011/02/egypt-vs-indonesia-in-attitudes/ and can of course not provide data to support the initial claim, since it becomes true by definition.
> Stop the cycle of violence. BE the bigger man you
> claim you are.
This is a lot easier to do if you have strategic depth, for what it's worth. Or even tactical depth. Both commodities are unfortunately in short supply in the Middle East....
To become a Recommendation (which is the 2014 date here), a standard has to be written, then an exhaustive test suite for it needs to be created, and then two implementations need to pass the test suite.
The goal is apparently to be done with that first step this year; the expectation is that writing the hundreds of thousands of tests and then fixing the thousands of browser bugs that they will uncover will take several years.
I suspect that the 2014 timeframe is too optimistic, personally.
Apart from the "internet video free to the viewer", all the rest of that is subject to change when the MPEG-LA wants.
Now I agree that it's not worth their time to go after you if you have no money. But nothing says the "2% or 2 cents" thing won't suddenly rise.
Dirac is meant to be a high-quality codec, period; it was largely designed for archival work. It makes no particularly strong effort to be low-bitrate in the process.
The result is that at high bitrates it's pretty good (and even offers lossless compression, etc). At the bitrates at which people normally serve internet video today, it's worse quality than Theora, I'm told. But this is third-hand, so don't take my word for it.
As bandwidth goes up, Dirac might find a place on the web, but we're not there yet.
Well, it's quite possible to not have inflation even if you print money like mad if people immediately hide the money under their mattress.
Our inflation measures have some quirks, but they're not that bad. As long as you don't mistake inflation for changes in cost of living, of course... But that starts getting back to how you define "inflation".