There is no such thing as "real value of a currency" in international trade. The amount of finished goods a currency can buy, for example, depends on the salaries, measured in that currency, of the people producing the goods, which depends on the exchange rate between that currency and whatever currency they're actually being paid in.
The US dollar definitely needs to depreciate, though. The fact that it's as high as it is (artificially propped up by other countries in many cases) is actively bad for the US economy. The dollar falling would be a _good_ thing.
> Also IF China off its bonds, do you for a second > believe that other countries would KEEP theirs?
They would probably _increase_ their bond purchases.
Other countries buy US bonds to to the extent that they have a trade surplus with the US. They're not buying them because they want to fund us; they're buying them because that's how they can prevent their currencies from appreciating too much against the dollar and the trade balance equalizing. If the yuan appreciates, we buy less from China, more from other countries, they have a bigger trade suprlus with us, and end up having to buy more bonds.
If China did this, then the value of the renmibi would immediately rise relative to the dollar; the only reason they're buying bonds is to hold the exchange rate down. This would have the effect of reducing Chinese exports to the US while making US industry more competitive.
The result may well be a net win for the US. It's a bit hard to predict a priori.
Also, just to put this in perspective, China bought about $250 billion of US bonds between Feb 2010 and Feb 2011. That's about 1/3 of total bond purchases by foreign governments over that time span (see http://www.treasury.gov/resource-center/data-chart-center/tic/Documents/mfh.txt ). It's also about 10% of the total bond sales over the time period as far as I can tell (I haven't found a good authoritative source for this; just graphs). That 10% drop in bond purchases would be annoying, but not fatal.
For example, Chrome's certainly fighting for the right to push their own standards; they just don't mind if someone else implements them too, since it all helps their non-browser business. But there's a fair amount of "we'll implement this, write up a useless description that doesn't actually describe how it works, throw it over the wall at the W3C, open-source the code, and claim that this is an open standard" going on in Chrome-land. This is how NaCl is being done, this is how a bunch of DOM stuff is being done, this is how some CSS features are being done.
It's a slightly better approach than MSIE in 2000, but only slightly.
Unlike a lot of government stuff, this case is interesting because post offices and post roads are one of the explicitly enumerated congressional powers (and ipso facto responsibilities) in the US constitution.
Though I would argue that what at the time was "post offices and post roads" is now "communications networks of every type"; there just weren't others at the time.
Sure. Better Privacy is nice if you want its features. But it's not strictly necessary to just delete Flash cookies, which is what the article is about.
It really depends on the code. In particular, in both Tracemonkey and Crankshaft it's quite possible to end up with code that can't be compiled with the optimizing compiler and then falls back to a less-optimizing JIT (JM and the V8 baseline compiler respectively) .
If you have an example of the sort of code we're talking about here, I'd be happy to see what numbers for it look like.
> I was under the impression that the IR optimizations > are mostly what makes the difference between gcc > -O0 and gcc -O2,
Depends on your code, but yes.
> isn't that a minor speed gap compared to the > still-existing gap between JS and C that doesn't > have all these IR optimizations enabled?
No.
> I think most people would be overjoyed if JS had > performance like C code compiled with gcc -O0
On numeric code, Tracemonkey and Crankshaft have about the same performance as gcc -O0 in my measurements.
> I guess to me the -O0/O2 gap seems like a minor > speed gap compared to the JS/C gap
For numeric code, the gap between -O0 and -O2 is a factor of 10. It's much larger than the gap between -O0 and current JS JITs, which is somewhere between "small" and "nonexistent".
The big gains from JS interpreters to most of the current crop of JS JIT compilers (excluding Crankshaft and Tracemonkey, and possibly excluding Carakan's second-pass compiler) come from class infrence, type specialization, ICs, etc. That work is already done. The result is about 30x slower than C code (gcc -O2, say) on numeric manipulation.
To get better performance than that, you need to do more complicated optimizations. For example, Crankshaft does loop-invariant code motion, Crankshaft and Tracemonkey both do common subexpression elimination, both do more complicated register allocation than the baseline jits, both do inlining, both do dead code elimination. For a lot of code the difference is not that big because there are big enough bottlenecks elsewhere. For some types of code (e.g. numeric manipulation) it's a factor of 2-3 difference easily, getting into the range of gcc -O0. And that's without doing the really interesting things like range analysis (so you can eliminate overflow guards), flow analysis so you know when you _really_ need to sync the stack instead of syncing after every arithmetic operation, and so forth.
For code that wants to do image or audio manipulation on the web, the textbook IR optimizations make a gigantic difference. That assumes that you already have the dynamic-language problems of property lookup and whatnot solved via the techniques Smalltalk and Self pioneered.
One end goal here is pretty explicitly to be able to match C or Java in performance on numeric code, at least in Mozilla's case.
For example, it eliminated code that included |TargetAngle > CurrAngle| but not code that was otherwise identical but said |CurrAngle >) was not. Addition and subtraction were eliminated while multiplication and division and % were not.
If it eliminated "any code that doesn't touch the DOM" that would be a perfectly good general-purpose eliminator. That's not what IE9 was doing, though.
There was the side issue that it also produced buggy code; that's been fixed since, so at least IE9 final doesn't dead-code eliminate live code.
No, they just pointed out that IE's dead-code elimination was somewhat narrowly tailored to the Sunspider benchmark. That's quite different from "crying bloody murder".
Tracemonkey does dead-code elimination right now; it has for years. It's just that it's a generic infrastructure, so you don't usually get artifacts with code being eliminated only if you write your script just so. On the other hand, you also don't usually get large chunks of web page dead code eliminated, because that wasn't a design goal. Keep in mind that a lot of the dead code JS JIT compilers eliminate is code they auto-generated themselves (e.g. type guards if it turns out the type doesn't matter, stack syncs it it turns out that no one uses the value, and so forth), not code the JS author wrote.
OK. Let's look at http://code.jquery.com/jquery-1.5.2.js very quick. This isn't even a minified version; just the original source. Pretend like you don't know what jquery is doing. The first few functions with arguments here:
> function( selector, context )
What are the types of those?
> function( selector, context, rootjQuery )
And those?
> function( num )
And that one? Hint: the function expects it to be "null" or at least "undefined" sometimes.
> function( elems, name, selector )
And that? Note that the function itself is not sure what to expect in |elems| and has different codepaths depending on what it finds there.
The point is, going from name to type is not really that easy.
Worse yet, "type" in this context also means what JS engines variously call "shape" or "hidden type": two instances of Object are considered the same type if they have the same properties in the same order. Telling _that_ from a variable name is pretty hard.
> Damn, Mozilla changes JIT engines like every year
Unlike Chrome, who has now had two (more actually, but two that they publicly named) jit engines between December 2008 and December 2010?
> Why should be believe this one will last any longer > than all the others they have tried?
What does "last longer" mean? Mozilla is still using the very first jit they did (tracemonkey); they're just not trying to use it for code it's not well-suited for.
http://blog.mozilla.com/dmandelin/2011/04/22/mozilla-javascript-2011/ has some discussion about LLVM in the comments. The short summary is that the LLVM register allocator, for example, is very slow; when doing ahead-of-time compilation you don't care much, but for a JIT that could really hurt. There are various other similar issues with LLVM as it stands.
This part is one major difference "Clean, textbook IR so optimization passes can be separated and pipelined with well-known algorithms."
The current JM is somewhat goes directly from SpiderMonkey bytecode to assembly, which means any optimizations that happen in the process are ad-hoc (and typically don't happen at all; even basic things like CSE aren't done in JM right now).
Slashdot Mirror
The problem is rampant in liberal circles too. Lucky us.
There is no such thing as "real value of a currency" in international trade. The amount of finished goods a currency can buy, for example, depends on the salaries, measured in that currency, of the people producing the goods, which depends on the exchange rate between that currency and whatever currency they're actually being paid in.
"Destruction of currency" when currency manipulators are purposefully propping it up is NOT easy and can well be a good thing.
I understand the interest rate situation, yes.
The US dollar definitely needs to depreciate, though. The fact that it's as high as it is (artificially propped up by other countries in many cases) is actively bad for the US economy. The dollar falling would be a _good_ thing.
> Also IF China off its bonds, do you for a second
> believe that other countries would KEEP theirs?
They would probably _increase_ their bond purchases.
Other countries buy US bonds to to the extent that they have a trade surplus with the US. They're not buying them because they want to fund us; they're buying them because that's how they can prevent their currencies from appreciating too much against the dollar and the trade balance equalizing. If the yuan appreciates, we buy less from China, more from other countries, they have a bigger trade suprlus with us, and end up having to buy more bonds.
I suggest reading http://mpettis.com/2011/04/chinese-recycling-and-us-interest-rates/ for an analysis of the situation that tries to actually consider what happens the day _after_ China stops buying US bonds, if that were to happen.
If China did this, then the value of the renmibi would immediately rise relative to the dollar; the only reason they're buying bonds is to hold the exchange rate down. This would have the effect of reducing Chinese exports to the US while making US industry more competitive.
The result may well be a net win for the US. It's a bit hard to predict a priori.
Also, just to put this in perspective, China bought about $250 billion of US bonds between Feb 2010 and Feb 2011. That's about 1/3 of total bond purchases by foreign governments over that time span (see http://www.treasury.gov/resource-center/data-chart-center/tic/Documents/mfh.txt ). It's also about 10% of the total bond sales over the time period as far as I can tell (I haven't found a good authoritative source for this; just graphs). That 10% drop in bond purchases would be annoying, but not fatal.
Sort of.
For example, Chrome's certainly fighting for the right to push their own standards; they just don't mind if someone else implements them too, since it all helps their non-browser business. But there's a fair amount of "we'll implement this, write up a useless description that doesn't actually describe how it works, throw it over the wall at the W3C, open-source the code, and claim that this is an open standard" going on in Chrome-land. This is how NaCl is being done, this is how a bunch of DOM stuff is being done, this is how some CSS features are being done.
It's a slightly better approach than MSIE in 2000, but only slightly.
Unlike a lot of government stuff, this case is interesting because post offices and post roads are one of the explicitly enumerated congressional powers (and ipso facto responsibilities) in the US constitution.
Though I would argue that what at the time was "post offices and post roads" is now "communications networks of every type"; there just weren't others at the time.
Yeah, the headline writing is just broken.
Sure. Better Privacy is nice if you want its features. But it's not strictly necessary to just delete Flash cookies, which is what the article is about.
This also works in Firefox 4 last I checked; I'm not sure why the article just talks about Chrome and IE.
Actually, Firefox 4 supports this as well, out of the box.
Maybe. Maybe not. http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospective.html is also worth reading for context here. The "Lessons About LLVM" part.
It really depends on the code. In particular, in both Tracemonkey and Crankshaft it's quite possible to end up with code that can't be compiled with the optimizing compiler and then falls back to a less-optimizing JIT (JM and the V8 baseline compiler respectively) .
If you have an example of the sort of code we're talking about here, I'd be happy to see what numbers for it look like.
> I was under the impression that the IR optimizations
> are mostly what makes the difference between gcc
> -O0 and gcc -O2,
Depends on your code, but yes.
> isn't that a minor speed gap compared to the
> still-existing gap between JS and C that doesn't
> have all these IR optimizations enabled?
No.
> I think most people would be overjoyed if JS had
> performance like C code compiled with gcc -O0
On numeric code, Tracemonkey and Crankshaft have about the same performance as gcc -O0 in my measurements.
> I guess to me the -O0/O2 gap seems like a minor
> speed gap compared to the JS/C gap
For numeric code, the gap between -O0 and -O2 is a factor of 10. It's much larger than the gap between -O0 and current JS JITs, which is somewhere between "small" and "nonexistent".
Turns out, figuring out whether code in JS is dead is hard. See http://blog.mozilla.com/rob-sayre/2010/11/17/dead-code-elimination-for-beginners/ for some examples of things that look dead but aren't.
The big gains from JS interpreters to most of the current crop of JS JIT compilers (excluding Crankshaft and Tracemonkey, and possibly excluding Carakan's second-pass compiler) come from class infrence, type specialization, ICs, etc. That work is already done. The result is about 30x slower than C code (gcc -O2, say) on numeric manipulation.
To get better performance than that, you need to do more complicated optimizations. For example, Crankshaft does loop-invariant code motion, Crankshaft and Tracemonkey both do common subexpression elimination, both do more complicated register allocation than the baseline jits, both do inlining, both do dead code elimination. For a lot of code the difference is not that big because there are big enough bottlenecks elsewhere. For some types of code (e.g. numeric manipulation) it's a factor of 2-3 difference easily, getting into the range of gcc -O0. And that's without doing the really interesting things like range analysis (so you can eliminate overflow guards), flow analysis so you know when you _really_ need to sync the stack instead of syncing after every arithmetic operation, and so forth.
For code that wants to do image or audio manipulation on the web, the textbook IR optimizations make a gigantic difference. That assumes that you already have the dynamic-language problems of property lookup and whatnot solved via the techniques Smalltalk and Self pioneered.
One end goal here is pretty explicitly to be able to match C or Java in performance on numeric code, at least in Mozilla's case.
> Narrowly pointing out and having their lead
> "evangelist", Asa Dotzler
Uh... I think you're confused about Asa's role here. But anyway...
> I haven't seen any proof that the dead-code
> eliminator is "somewhat narrowly tailored for
> Sunspider"
Well, it only elimintated code that restricted itself to the set of operations used in the Sunspider function in question. This is pretty clearly described at http://blog.mozilla.com/rob-sayre/2010/11/17/dead-code-elimination-for-beginners/
For example, it eliminated code that included |TargetAngle > CurrAngle| but not code that was otherwise identical but said |CurrAngle >) was not. Addition and subtraction were eliminated while multiplication and division and % were not.
If it eliminated "any code that doesn't touch the DOM" that would be a perfectly good general-purpose eliminator. That's not what IE9 was doing, though.
There was the side issue that it also produced buggy code; that's been fixed since, so at least IE9 final doesn't dead-code eliminate live code.
Not quite. More precisely they add new engines, and give them names, then use whichever one does the job best (or is likely to do the job best).
No, they just pointed out that IE's dead-code elimination was somewhat narrowly tailored to the Sunspider benchmark. That's quite different from "crying bloody murder".
Tracemonkey does dead-code elimination right now; it has for years. It's just that it's a generic infrastructure, so you don't usually get artifacts with code being eliminated only if you write your script just so. On the other hand, you also don't usually get large chunks of web page dead code eliminated, because that wasn't a design goal. Keep in mind that a lot of the dead code JS JIT compilers eliminate is code they auto-generated themselves (e.g. type guards if it turns out the type doesn't matter, stack syncs it it turns out that no one uses the value, and so forth), not code the JS author wrote.
OK. Let's look at http://code.jquery.com/jquery-1.5.2.js very quick. This isn't even a minified version; just the original source. Pretend like you don't know what jquery is doing. The first few functions with arguments here:
> function( selector, context )
What are the types of those?
> function( selector, context, rootjQuery )
And those?
> function( num )
And that one? Hint: the function expects it to be "null" or at least "undefined" sometimes.
> function( elems, name, selector )
And that? Note that the function itself is not sure what to expect in |elems| and has different codepaths depending on what it finds there.
The point is, going from name to type is not really that easy.
Worse yet, "type" in this context also means what JS engines variously call "shape" or "hidden type": two instances of Object are considered the same type if they have the same properties in the same order. Telling _that_ from a variable name is pretty hard.
> Damn, Mozilla changes JIT engines like every year
Unlike Chrome, who has now had two (more actually, but two that they publicly named) jit engines between December 2008 and December 2010?
> Why should be believe this one will last any longer
> than all the others they have tried?
What does "last longer" mean? Mozilla is still using the very first jit they did (tracemonkey); they're just not trying to use it for code it's not well-suited for.
> just micro-fractional improvements
If a factor of 2-3 is "micro-fractional", yes.
No idea; you'll have to ask someone familiar with both LLVM and the needs of a JIT for that....
http://blog.mozilla.com/dmandelin/2011/04/22/mozilla-javascript-2011/ has some discussion about LLVM in the comments. The short summary is that the LLVM register allocator, for example, is very slow; when doing ahead-of-time compilation you don't care much, but for a JIT that could really hurt. There are various other similar issues with LLVM as it stands.
This part is one major difference "Clean, textbook IR so optimization passes can be separated and pipelined with well-known algorithms."
The current JM is somewhat goes directly from SpiderMonkey bytecode to assembly, which means any optimizations that happen in the process are ad-hoc (and typically don't happen at all; even basic things like CSE aren't done in JM right now).