A few articles I wrote on working at Igalia last year:
http://wingolog.org/archives/2013/06/05/no-master
http://wingolog.org/archives/2013/06/13/but-that-would-be-an...
1,533 karma · joined May 12, 2008
A few articles I wrote on working at Igalia last year:
http://wingolog.org/archives/2013/06/05/no-master
http://wingolog.org/archives/2013/06/13/but-that-would-be-an...
Here is a good introductory talk: http://www.infoq.com/presentations/Understanding-Java-Garbag...
Your point about size is well-taken though. Besides libc in this case, Guile's build products are much larger (and slower) than LuaJIT's images because we've been trying to write the compiler in Scheme from the very beginning. We can't even think about doing a nice JIT until we have a good AOT compiler, because otherwise the JIT written in Scheme would be too slow.
Fixed by Mark H Weaver, on Fri, 7 Dec 2012.
Avoid signed integer overflow in scm_product
* libguile/numbers.c (scm_product): Avoid signed integer overflow, which modern C compilers are allowed to assume will never happen, thus allowing them to optimize out our overflow checks.
* test-suite/tests/numbers.test (*): Add tests.
The new standard will help marginally, but there will be no grand unification of Schemes. R6RS was big enough for your needs but did not achieve wide adoption. There is no fundamental reason why this would be different for the larger R7RS report (on which work has not yet begun). Indeed, some implementations have already forked with an explicit intention of going on their own paths (Racket).
In short, for serious work, you might be able to share modules between implementations if that matters to you, but your overall application will be implementation-specific.
FWIW, IMHO, etc...
"MCNP is written in the style of Dr. Thomas N. K. Godfrey, the principal MCNP programmer from 1975-1989 ... All variables local to a routine are no more than two characters in length, and all COMMON variables are between three and six characters in length ... The principal characteristic of Tom Godfrey's style is its terseness. Everything is accomplished in as few lines of code as possible. Thus MCNP does more than some other codes that are more than ten times larger. It was Godfrey's philosophy that anyone can understand code at the highest level by making a flow chart and anyone can understand code at the lowest level (one FORTRAN line); it is the intermediate level that is most difficult. Consequently, by using a terse programming style, subroutines could fit within a few pages and be most easily understood. Tom Godfrey's style is clearly counter to modern computer science programming philosophies, but it has served MCNP well and is preserved to provide stylistic consistency throughout."
This from MCNP4c chapter 2, section B, quoted here: http://wingolog.org/archives/2005/04/09/101. Alas, the link in that article is dead.
FWIW, I neither agree nor disagree with Godfrey's style.
As you can see, the situation is a bit complicated. If I could have made the article shorter, I would have :)
If this is the sort of topic you are interested in, then you can have the patience to read a few paragraphs. If it's not, then summarizing isn't going to help :)
In any case I don't see why anyone would allow such lampreys to suck the life of their own web page.
Regarding the script injection from image file names, there is a simple solution to this problem: separate the data types of strings and document structure. For example:
http://www.gnu.org/software/guile/manual/html_node/Types-and...
In the meantime, this headline had me a little confused, thinking of the chip designer Chuck Moore who was Forth's creator. It doesn't seem that this is the same Moore. Just FYI :)
Uf. Haskell impresses me a lot, but it seems that performance-wise, it would be better if it were strict by default.
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-11....
Maybe the YC model will reach that "how will we be computing in 10 years" phase at some point. But (perhaps with good reason?) it does not seem to be there yet.
I wonder though, how do you know that is parsing time? There are a number of things happening when JS is loaded, and parsing is only one of them.
Also, an update on that article would probably be useful -- a number of things have changed in the major browsers since you wrote it.
Happy hacking :)
Fetching js over the net is slow (multiple orders of magnitude slower than parsing).
Optimized compilation is slow (an order of magnitude).
But you can't even do baseline compilation without knowing what's in your evironment. For example, JSC (from WebKit) compiles to bytecode. But the compilation process happens lazily, as functions are first executed. (There is a quick pass to check syntax, beforehand. V8 does this too AFAIR.)
But OK, let's say you're parsing. You parse, create an AST, and go to compile it. The result of bytecompiling for V8 is native code! You can't cache that effectively, it will embed too many runtime constants. For JSC you do produce bytecode, but that bytecode too is dependent on runtime object layouts: for example if you reference a binding in the global object, and the binding is present, then the compiler will produced an indexed lookup into the global. That depends on what's in the global when the compilation unit (function, eval, or global code) is compiled. Caching is a security / correctness risk, in that context.
And then you have the negative impacts of caches on browser memory footprint (and associated GC cost).
It's no wonder why modern JS engines prefer to just keep around the source, and re-parse on demand.
Interesting.