HN user
http://wingolog.org/
Igalia, http://www.igalia.com/ -- 40+ people, 11 or 12 years old (I forget!).
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...
GC needs to know about all references in the program. If the mutator (the program) is running concurrently with the collector, it's difficult (though not impossible) for the collector to construct this consistent view.
Here is a good introductory talk: http://www.infoq.com/presentations/Understanding-Java-Garbag...
That's certainly the case for full CPS, but using a CPS intermediate language does not imply call/cc. Indeed Kennedy targeted the .Net CIL; a direct-style VM. The important thing to note is that continuations and functions can be statically distinguished. The article conflates the two, which is why I don't find it very useful.
I recommend Andrew Kennedy's "Compiling with Continuations, Continued" article if you are actually interested in using continuations in a production compiler. Might's formulation of CPS is good for analysis but not actually that great for code generation in my opinion. My take on the topic is here: http://wingolog.org/archives/2014/01/12/a-continuation-passi...
They play this video while you wait for the train to take you up to that glacier (the mer de glace). I stared at it gapemouthed for some time!
I'm pretty impressed, and especially by the apachebench test -- to serve a spike of 30K reqs/s while having 600K idle connections is quite good.
You already have a programming language in your makefiles.
AFAIUI libc is in the initrd, but it's a statically linked libc. Guile's dynamic FFI uses dlopen/dlsym to get its function pointers, so it can't do that in a statically linked libc. (Or could it? I suppose there's no reason why a statically linked library wouldn't expose symbol tables, whether via dlsym or some other means.)
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.
You can redirect the control-flow of the program by overwriting a return address or a vtable. Once you've done that, it's easiest if you can redirect control to code you've written, in executable heap; but if that's not possible, you can still use return-to-libc, or potentially "return-oriented programming" strategies.
Sure, it's possible. The sequence of multiplications chosen to reach the exponent is different, so these expressions take different paths through scm_integer_expt.
http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commit;h=2...
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.
Sounds like your problem is more that Scheme is too small for the programs you'd like to write. Implementations that are adequate to your needs being incompatible with each other is a natural side effect.
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...
An interesting perspective here:
"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.
Well, I guess the one thing I would correct is the "why". The LLInt doesn't just produce assembler to be fast, though it is faster than the old interpreter. The real reason it produces assembler is to control the stack representation, so that it works better with tiering, exceptions, and the optimizing compiler (DFG). Otherwise, interpreting was a lose, because tiering up cost too much.
As you can see, the situation is a bit complicated. If I could have made the article shorter, I would have :)
No offense intended, but this comment does not add very much while misunderstanding some other things. For example, I did not write the LLInt. It was mostly written by Apple's Filip Pizlo.
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 :)
How does such a touching, honest article get such terrible comments? (Referring to the comments on the author's blog.)
In any case I don't see why anyone would allow such lampreys to suck the life of their own web page.
Nice work, and (as another fastmail.fm user) thank you for the responsible disclosure. May it amply repay you in consulting gigs :)
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...
Fold is implicitly sequential. See Guy Steele's ICFP 09 presentation on conc lists, previously discussed here as http://news.ycombinator.com/item?id=814632.
I look forward to seeing articles on Moore's work; I did not have the pleasure of knowing him.
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 :)
Besides what sdcooke said, ad networks also use the HTTP requests to track users. Embedding the ad in the (third-party) page defeats that purpose.
> The fix is straightforward: just use a strict pair type for nested accumulators:
Uf. Haskell impresses me a lot, but it seems that performance-wise, it would be better if it were strict by default.
A form of this will probably be in ES6:
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-11....
Much love for lisp machines, but stack machines do not offer any performance advantages over register machines, and actually make optimization much harder. See Ungar's 1993 thesis on the Self 93 compiler for an early realization of this, where he examines what microcode / register windows / etc could do for him, and how he was able to do just as well with registers.
Dunno, Paul. While SPJ does have a lot of relevance to current computing, his work is not a product like Etherpad was. I haven't seen YC companies moving towards or staying with fringe languages -- not that I criticize that business decision.
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.
Lovely article!
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 :)
abarth's reply below indicates that V8 does cache something. I should have poked into things more before replying.
Parsing is not the slow part.
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.
It's definitely relevant here on HN -- a good article with a bad title probably won't go anywhere. A good article with a great title will stay on the front page for hours.
Nicely done!
> New Tumblr > Changed to a JVM centric approach for hiring and speed of development reasons.
Interesting.