bnoordhuis's comments

It's in the works: https://code.google.com/p/v8/issues/detail?id=811

You can tell by the number of CLs that a lot of work has been done already but there are a few more still in progress. It's probably still a few weeks out.

Disclaimer: I don't speak for the V8 team, I'm just an interested onlooker.

I've been going back and forth on this.

On the one hand, I feel that positive discrimination is just as bad as the other kind and that its proponents are not thinking things through as clearly as they should.

On the other hand, board members are humans too. Given the choice, and whether consciously or unconsciously, they will typically elect people much like themselves, because that's the kind of person they can understand and relate to. It's an understandable human trait but it does perpetuate the status quo.

I do wish the focus was less on gender and more on diversity in general. We have sizable ethnic minorities in the Netherlands but they are quite underrepresented in upper management and I'm not sure it can be fully explained by the socioeconomic and education gap.

Interesting results, thanks for sharing. I can perhaps shed some light on the performance differences.

> Buffer 4.259 5.006

In v0.10, buffers are sliced off from big chunks of pre-allocated memory. It makes allocating buffers a little cheaper but because each buffer maintains a back pointer to the backing memory, that memory isn't reclaimed until the last buffer is garbage collected.

Buffers in node.js v0.11 and io.js v1.x instead own their memory. It reduces peak memory (because memory is no longer allocated in big chunks) and removes a whole class of accidental memory leaks.

That said, the fact that it's sometimes slower is definitely something to look into.

> Typed-Array 4.944 11.555

Typed arrays in v0.10 are a homegrown and non-conforming implementation.

Node.js v0.11 and io.js v1.x use V8's native typed arrays, which are indeed slower at this point. I know the V8 people are working on them, it's probably just a matter of time - although more eyeballs certainly won't hurt.

> Regular Array 40.416 7.359

Full credit goes to the V8 team for that one. :-)

Libuv author here. Libuv doesn't try to be all things to all people - its main users are Node.js and Rust - but if you have suggestions on how to improve the API or the implementation, please file issues[1] or join us in #libuv on irc.freenode.org. We welcome outside input.

As a bit of history, the reason why uv_loop_new() mallocs memory for the struct (and it's something of an anomaly in that respect, most other API functions don't) is that the thing that came before libuv, libev, worked like that. It's something we can change if there is demand for it.

[1] https://github.com/joyent/libuv/issues

On and off kernel hacker here. Compile and test the release candidates Linus puts out every fortnight. When the inevitable breakage happens, use `git bisect` to track down the offending commit.

It's tedious and time consuming but you will make people very happy. The only way to test something as big and critical as the kernel is by having users actually run it.

That's a regression we'll probably have fixed in 0.6.1.

Note that I/O read performance is up 35%, from 19.7 mb/s in 0.4 to 26.6 mb/s in 0.6.

I suspect that it's a jab at ALSA which, for reasons unknown, ships with a full LISP interpreter[1] that it doesn't actually use...

Lennart Poetering is the author of PulseAudio. He probably has a bone or two to pick with ALSA.

[1] http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/...

> Isn't Node.js single threaded ?

Yes (for now, we might take up V8 isolates).

> Would it not under-perform , say compared to Erlang or Netty, in a multi-core CPU.

No. You can spin up multiple processes and handle the load with (for example) cluster[1].

[1] http://learnboost.github.com/cluster/

It's been fixed in master. 0.5.2 comes out tomorrow (if all goes well) and will also contain the fix.

https://github.com/joyent/libuv/issues/112 for details.

linux doesn't have kqueue. But kqueue is only an API, you could emulate it with io_submit() and io_getevents().

A bigger obstacle is that not all file systems support asynchronous I/O, the io_*() syscalls won't help you there.

That was the impression I walked away with too: much CS ivory tower thinking, little real-world relevance. But they're only interviews, everyday life at Google is probably (hopefully!) different.

As a counterpoint to the HR horror stories: my recruiter was a friendly woman who always responded quickly and politely. No complaints here.

There isn't a shred of the original mongrel parser left. I'm not 100% sure but http-parser looks more like it's inspired by nginx than that it actually contains nginx code.

Disclosure: I know both http-parser and nginx fairly well. I'm one of the 'other Node contributors'. :-)

Maybe I can help. I'm relatively local (Gouda, ZH) and I've managed teams like the one you mention before. Shoot me an email, address is in my profile.

The language was C and my solution (adapted to the article) was something like this:

    // TODO enforce! see also: soylent green
    #define MAX_AGE 100

    struct student {
        const char *name;
        int age;
    };

    struct students {
        long n_students;
        struct student *students[10e6];
    };

    struct students all_students[MAX_AGE];

    void insert(struct student *s) {
        struct students *ss = &all_students[s->age];
        ss->students[ss->n_students++] = s;
    }

So O(1) insertion and O(n) post-processing to stitch the arrays together again. Seems like pretty acceptable performance to me but the Google guy thought otherwise, the answer he was looking for was (probably) a counting sort.

I tried to argue that my solution was a fair bit faster and simpler to boot. That's probably why I didn't get a follow-up interview - no-one likes a smart arse. :-)

> His grandmother knew radix sort.

Radix sort? I read it as a trick question where the answer is 'hash table with numberOfYearsOld as the key'.

I suggested that as the solution to an almost identical question when interviewing with Google - and it got rejected by the interviewer. Ah, the arbitrariness of it all!

Sounds about right. My base salary, no benefits, would be about 58K a year if I worked full-time. This is in Rotterdam, where salaries are slightly lower than in Amsterdam.

I hear you, threading in SM is indeed fraught with dangers.

On the off chance that you're going to revisit it, the way to go is to compile with -DJS_THREADSAFE and register a callback with JS_SetGCCallback() that tells the VM when it's safe to run the garbage collector.

Actually, the approach I took was to always tell the VM 'no' and invoke JS_GC() manually from time to time. Conceptually easy and performance is mostly amortized.

PS: Feel free to contact me if you have follow-up questions, my email is in my profile.

V8 is a single-threaded VM and I don't see that changing any time soon, it's very much married to Chrome's per-process model. SpiderMonkey doesn't have that drawback, it supports threads just fine.

These guys have their work cut out for them if they want to support the V8 API from within SM. It's a well designed API but large and fast moving.

Still, an interesting project. I'm going to watch it, maybe submit a few patches.

You'll be hard-pressed to exhaust all ports: modern operating systems track connections by source address + source port + target address + target port. I wouldn't be surprised if the TCP sequence number is also part of the mix.

TIME_WAIT times can be tweaked with the net.ipv4.tcp_tw_recycle and net.ipv4.tcp_tw_reuse sysctls, on Linux systems anyway.

Take the staged approach:

1. Begin with a simple JDBC-backed servlet + JSP web app, like a blog (boring, I now), and deploy it to a servlet container like Jetty or Tomcat.

2. Migrate your servlets to Spring MVC and all that that entails: creating an applicationContext.xml, setting up the DispatcherServlet, view resolvers, message sources, form binding, transaction management, etc.

3. Migrate the JDBC components to Hibernate. I hate Hibernate with a passion but it's de rigueur in modern JEE. Bonus points if you use it as a JPA provider.

4. Deploy your app to a application container like Glassfish. Learn how to use JTA and how to access container-managed resources with JNDI.

5. Make the front end and back end of your web app talk to each other over JMS. Look into ActiveMQ and other service bus middleware.

The first three are pretty much essential if you want to score a gig. The next two not so much but they'll give you an edge during interviews.