One thing I struggle with: how does one calibrate one's spidey sense? Reading comments in online forums is likely to bias one towards the people talking the most, which is not a good bet as a representative sample. It's not just systemd; it's any topic of heated discussion. All we hear from on many topics are the people with the strongest emotions. How can we compensate?
I find perf a very useful tool, and use it frequently.
At the same time, I don't see how your data supports your conclusion that perf is more effective than cachegrind here. The absolute cycle count is of limited interest. The most important thing these tools do is tell programmers where to look, and cachegrind seems to have done a good job of that here.
In my experience, perf and cachegrind are two tools in the toolbox. perf is stronger at optimizing for the particular CPU I'm on, and it runs faster. Cachegrind collects more detailed information, and while the model it uses isn't perfect for the CPU I'm on today, it's usually good enough to be useful, and it's good for optimizing things likely to matter on other CPUs too.
If you're going to argue against taxi licenses or anything else, please explain why you think the reasons why some people believe the good outweighs the bad are wrong, rather than just pointing out that there is bad.
No mention of PNaCL anywhere. Eventually they did change their public messaging away from x86 sandbox and towards PNaCl, though not before causing lots of external confusion and fear. And even then, with the time it took to get PNaCl released, some of the external confusion persisted.
The earlier poster does indeed seem to have misunderstood the history, but it's easy to see where such misunderstanding may come from.
This is not how it was introduced, the blog post was the introduction. We published earlier research papers because we publish papers.
The plan was always the same.
Before this, the project wasn't really real, it was just research.
If you consider this "public messaging", then I guess google should never release research papers or research SDK's without fear of being raked over the coals?
You're right that the first link I posted is a research paper, and that it should be interpreted accordingly. It is interesting though that in the paper, they compare NaCl to other systems, some of which include ISA virtualization, and they specifically say "we made a deliberate choice against virtualization". And this paper is just a small sample of what Google was saying about NaCl in 2009. But you're right, it is still a research project at that point.
However, you apparently missed the second link I posted, which is in fact a blog post and an introduction. NaCl is no longer a research project there. In fact, the post itself specifically describes the difference between research releases and the release it is announcing.
I'm suggesting in 2009, it was random cool research (I actually can't even remember whether it was being funded by chrome back then), not something with a real and true plan to become what it is now.
That really didn't happen until late 2010 or 2011, AFAIK.
I think I could debate this point with you, but I just clicked up the thread to see the context (I only found this subthread because I follow your comments) and can now see why we wouldn't want to perpetuate this subthread.
Your original point, that Portable Nacl is within the original charter of the Nacl project, was valid, even if we can quibble about the timelines. :)
I totally agree with this, I like seeing these posts and being aware of the ways in which Apple is twisting the truth to serve their marketing; it's interesting to see the process behind the presentation, but there seems to be a disproportionate amount of examination around Apple keynotes, and never say Google ones, and I'd love to see the spin others put on their presentations.
As the author of this piece, I'd be happy to look at doing something similar for Google I/O if the structure of the presentation lends itself to such an article.
Appreciate the kind words and nudge in the direction of doing more.
I'd love to see, as I say there seems to be a lot of work to show exactly how Apple is twisting things compared to others, I'd love to see if that was because Apple is a lot worse for that or if people just don't examine their competitors. I remember sitting in I/O quite interested, but feeling a few bits were not more than marketing.
This article does have aspects that could be reasonably criticized. But we can have some fun trading rhetorical devices too. I see your Dismissive Tone and raise you a Gentle Mock.
The article sites numerous non-XXX-droid sources too. Shall we dance?
There probably is close to zero overhead in a small benchmark. Hardware branch prediction is indeed good. However, it's a finite resource. In a large application, lots of needless branches everywhere translates into fewer branch prediction resources available for the branches that matter, which means more mispredictions. Also, they take up icache, itlb, etc. It's not at all obvious that the overhead would be close to zero in context.
Would it be possible to mark the JO instruction (jump-if-overflow) as unlikely, so that the CPU would always predict the branch to not be taken, without consuming one branch prediction slot?
> so that the CPU would always predict the branch to not be taken
AFAIK there isn't any notion of likely/unlikely in object code on most CPU architectures. I'm only really familiar with x86 and ARM though.
__builtin_expect() in GCC (the "likely()" and "unlikely()" macros in the Linux kernel use this) can do a lot of things to optimize branches, like prefetch instructions and decide whether or not the jump should be the usually taken or usually not taken side, but it can't actually emit instructions that directly tell the CPU "always predict this" AFAIK.
> It's not at all obvious that the overhead would be close to zero in context.
That's a fair point, although I think using a single function for all your checked addition like the one above would go a long way towards mitigating the resource waste you mention.
Maybe that's a naive assumption on my part: I suppose you could construct a branch predictor that maintains state based on the function call chain as opposed simply using the address of the branch... but that seems like it would be prohibitively complex.
Perhaps, but how important is DRM, with Chrome shipping it and even promoting it, to you, personally? Less important than having a nice startup time? Whatever floats your boat, but that seems to be a significant reason why we're here today.
It is generic, but the graphs on arewefastyet.com suggest that it isn't actually making most regular benchmarks go faster, just some of the asm.js-style ones.
It's unclear. Diversity helps innovation, but it also adds complexity to everyone who builds on top of it. If there's room for significant innovation, it can be worth the complexity. But if there isn't, and there are many signs that there's not much left to do in the traditional general-purpose ISA space, then we're just living with a bunch of complexity for no benefit.
• Growing interest in running entire OS in little-endian mode
– Ease porting of programs from other architectures
– Ease porting of programs which access files containing LE binary data
– Ease communication with GPUs
• New OpenPower Consortium
– IBM, Google, Tyan, Nvidia, Mellanox
