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.
> 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.
The issue is at what point does the need for diversity kick in? If I start a startup right now with a friend, a person who is much like myself, very few people will criticize us for diversity issues at 2 people. But if we continue to hire friends, when does it become a diversity issue that needs addressing?
I think a good moment to start thinking about this is when you are legally required to have an Ondernemingsraad [1]. Which is at 50 employees.
It's an arbitrary threshold, but seems like a good point in the life of a company where it transitions from a small company to a larger one, where you need to start making various informal policies and company customs and values more formal.
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.
I can explain what happened to Array case. 100000 used to be the threshold at which new Array(N) or arr.length = N started to return a dictionary backed array. Not anymore: this was changed by https://codereview.chromium.org/397593008 - now new Array(100001) returns fast elements array.
I will check out what happened to Buffer/TypedArray. Should not degrade that much unless something really goes south here.
The first major one is related to mortality of TypedArray's maps (aka hidden classes). When typed array stored in the Data variable is GCed and there are no other Uint8Array in the heap then its hidden class is GCed too. This also causes GC to find and discard all optimized code that is specialized for Uint8Array's and clear all type feedback related to Uint8Array's from inline caches. When we later come and reoptimize - optimizing compiler thinks that cleared type feedback means we need to emit a generic access through the IC (there is reasoning behind that) because this is potentially going to be a polymorphic access anyways. I have filed the issue[1] for the root cause (mortality of typed array's hidden class).
Now there is a second much smaller issue (which also explains performance of the Buffer case) - apparently there were some changes in the optimization thresholds and OSR heuristics. After these changes we hit OSR at a different moment: e.g. I can see that we hit inner loop one that loops over `j` instead of hitting outer loop which leads to better code. In V8 OSR is implemented in a way that tries to produce optimized code that is both suitable for OSR and as a normal function code - this is done by adding a special OSR entry block that jumps to the preheader of the selected loop we are targeting with the OSR. This allows V8 to reuse the same optimized code without optimizing it again for the normal entry - but this also leads to code quality issues if OSR does not hit the outer loop because OSR entry block inhibits code motion. This is a know problem and there are plans to fix it. The hit usually is quite small unless you have very tight nested loops (like in this case).
Disabling OSR (--nouse-osr) not only "solves" the second issue but it also partially fixes (hides)the first issue: 1) we no longer optimize with partial type feedback - so we never emit generic keyed access but always specialize it for the typed array 2) we no longer emit OSR entry - hence no code quality issues related to it.
Very interesting. After reading your comment, I tried allocating another Uint8Array and keeping it allocated throughout the entire test as a workaround for the issue you mentioned. Time for Node.js was unchanged, but io.js was down to about 5.5s now. Almost the same time as Node. Only about 10% slower.
The same happens when I use the --nouse-osr parameter that you mentioned.
Ok, I hadn't tested with both before. Keeping the array alive and using --nouse-osr makes io.js only 2.3% slower than my original measurement for Node 0.10.35. Median of 5058ms.
And Node 0.10.35 shows basically the same results as before. I see less than 1% difference. Maybe just random fluctuation. Even if not. 1% is irrelevant.
I posted this reply on your site, but I will duplicate it here for the sake of HN readers:
> BTW --nouse-osr makes all three tests run faster.
As I tried to explain above: OSR at it is implemented now impacts code quality depending on which loop OSR hits. Which in turn depends on heuristics that V8 uses. These heuristics are slightly different in newer V8. As a result of these changes V8 hits inner loop instead of outer loop. This leads to worse code.
Code that benefits from OSR is the code that contains a loop which a) can be well optimized b) runs long b) is run only few times in total. The Sieve benchmark is opposite of this and as a result it doesn't benefit from OSR - you get bigger penalty from producing worse code and no benefit from optimizing slightly earlier.
Not using OSR for Sieve also hides the other issue with mortality of typed array's hidden classes. I say "hides" not "fixes" because one can easily construct a benchmark where the mortality would still be an observable performance issue even if benchmark itself is run without an OSR: https://gist.github.com/mraleph/2942a14ef2a480e2a7a9
Does the dramatic speed difference between the "non-conforming" implementation and V8 mean that current Node typed arrays are not memory-safe and you may get C-style buffer overflow vulnerabilities when using them?
I thought about that. But it would have diminished the point I was trying to make: Always test with different versions as performance may differ by a LOT.
He was talking about differences between point versions. 0.10 has dramatically different performance to 0.11. io.js is using 0.11, as is node:master, but older node was using 0.10.
I.e. the difference isn't necessarily node vs io, it's one point release of V8 to the next as used by node and io.
Yes I think it needs to be noted that V8 in node 0.10 is very very far behind when you take into account how quick the pace of development is. I would be interested to see these comparisons with bleeding edge node vs stable node.
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.
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.
Any numbers for node on ARM? I was told that recently v8 releases have had significant performance regressions for ARM devices by a JS dev at a meetup.
If you know that JS dev personally please ask him to file the bug (http://code.google.com/p/v8/issues/entry) or send any information he has about regressions to v8-users mailing list.
I don't think there were any bugs opened recently about perf regressions on ARM devices.
Whoa. That file contained the absolutely most naive string hash function I've ever seen:
static int get_string_hash(const char *s)
{
int val = 0;
if (s == NULL)
return val;
while (*s)
val += *s++;
return val & ALISP_OBJ_PAIR_HASH_MASK;
}
It seems to cleverly avoid everything that's supposed to go into a string hash function, and makes me quite wary of the rest of the file's code quality. I stopped reading after checking that this function is indeed used (it is).
Also, the file itself was last modified on 2011-10-18, which seems to be pretty recent for something that's not used. Perhaps they're gearing up to start using it, and if that's going to involve any kind of even remotely performance-sensitive, I hope they replace the hash function first. :)
I'm curios, what is (under normal circumstances) supposed to go into a string hash function?
The biggest problem I see with this hash function is that it will produce very many collisions (because most common strings will probably produce only small numbers).
I have seen other very simple string hash functions which just take the 4 first bytes (or 4 last or some sort of other pattern) of the string and use them (interpreted as 32bit integer) as the hash.
I'm no expert in hash function design, but one thing that seems bad is that it will generate colliding hashes for all permutations of the same characters. Also, it will not "spread" the bits very well, due to just using addition. Most "real" hash functions tend to multiply the hash by each new character, thus causing it to "churn" more.
That's probably still better than the string hash in really early versions of Java, which only looked at a relatively small number of characters at the start of the string.
> No. You can spin up multiple processes and handle the load with (for example) cluster[1].
Which is what I speculate they're doing, as they say they're running just four instances. Probably, they have servers capable of running 4 threads at the same time.
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.