604 karma · joined March 19, 2010
https://github.com/bnoordhuis
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.
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.
> 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. :-)
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.
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.
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.
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/...
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].
https://github.com/joyent/libuv/issues/112 for details.
A bigger obstacle is that not all file systems support asynchronous I/O, the io_*() syscalls won't help you there.
As a counterpoint to the HR horror stories: my recruiter was a friendly woman who always responded quickly and politely. No complaints here.
Disclosure: I know both http-parser and nginx fairly well. I'm one of the 'other Node contributors'. :-)
// 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;
}
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. :-)
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!
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.
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.
TIME_WAIT times can be tweaked with the net.ipv4.tcp_tw_recycle and net.ipv4.tcp_tw_reuse sysctls, on Linux systems anyway.
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.
I don't see how it could.
The CPU essentially drops everything it's doing when a packet comes in. Have that happen often enough and there won't be time left to do anything else, unless you start dropping packets.
Disclaimer: I sometimes consult for HFTs but we don't use FPGAs (yet).
With pre-fork and threaded, every connection takes up a process or thread. This sucks for keep-alive because it can take a while before the client issues the next request.
The event MPM puts that idle connection in a kqueue/epoll/etc. pollset and recycles the process/thread for another request.
It's a conceptually simple change but it has some profound performance implications.
* Robust: that's reflected in its internal API that makes it near impossible to leak resources.
* Extensible: witness the gazillion modules out there.
* Portable: compiles and runs on very exotic or outdated systems. SCO, IRIX, Digital UNIX, VMS, the list goes on.
nginx and such were designed from the ground up with performance in mind - and with success - but the trade-off is a lack of portability and an API that is much harder to program to.
`httpd -X` and `gdb httpd $(pidof httpd)` are a great help when debugging.
[1] http://mail-archives.apache.org/mod_mbox/httpd-modules-dev/
But - and I don't want to sound pedantic - how is m^2 not exponential growth?
Edit: mea culpa guys, I carelessly translated from Dutch. You're all right: quadratic, not exponential growth.
A quick review of the code makes me think that its worst case is actually on the order of O((s * (s + 1)) / 2), where s = m / 2.
The Achilles heel is the hash function. It's trivial to create collisions and have the insertion time for word w turn from O(1) to O(w).
Several.
Since node.js 0.2.0, V8 has been incrementally upgraded from 2.4.2 to 3.1.2.
The changelog is here: https://github.com/ry/node/blob/master/deps/v8/ChangeLog