cliffbean

Why are we measuring performance in MIPS?

Little-endian is generally better for compilers, to the extent that it matters. For example, with SIMD, it makes most sense to number the lanes in the same direction as addresses in memory, so that lane 0 is at offset 0 when doing a load or store. And if you want to reinterpret the bits of a SIMD value as a different type, little-endian is the only sane way to do it. And so on.

I've become fond of thinking about little-endian becoming known as a universal "CPU byte order", to complement "network byte order". Each order makes the most sense for its domain.

I take a pragmatic approach. I'm cool with BSD license for most of user-level application code, because if someone wants to make a binary-only application, I usually have options I can choose from. But in kernel space, a binary-only driver or kernel means that open source of any kind is locked out of the hardware, because it's hard to write drivers without specs. In that space, the GPL is one of our few tools for getting device makers to give us what we need.

They appear to be doing "take, modify, distribute as a compiled binary blob that no one else can modify and pass around". It's hard to reconcile that with the word "share".

Normal division by zero gives you Infinity. To get NaN, you have to do something as numerically confounding as divide zero by zero, which isn't any infinity, because the numerator is zero, and which isn't zero or any finite number, because the denominator is zero.

I distinguish between proprietary apps and proprietary kernel. The open source world can build its own apps. Mostly. However, it can't build its own kernel if the hardware is undocumented and/or only supported by OS-specific binary blobs. Drivers are key to a lot of things.

MS is a lot more open-source friendly, and smarter, but it's pretty clear that this is a strategy to get more people tied into ecosystems which favor proprietary Windows. MS is behind, so they're playing catch-up.

While most people don't hack kernel code themselves, there is still value in promoting open source operating systems. A future in which Windows becomes popular on mobile/embedded devices is likely a future with more binary blobs, more OS-locked hardware, and fewer opportunities for those people who do want to hack on kernel code.

The current leaders of the LLVM project intend to keep it open.

They have also traded away a way to encourage others to keep it open in return for wider adoption.

Interpret that as you will.

We don't need any networks. Self driving cars will always need to be able to share the road with normal cars. That mechanism will support the case of sharing the road with other self driving cars too. Networks can add fancy features, but they can happen on their own time, incrementally.

The argument is that self-driving cars would reuse existing roads, fuel, service, and manufacturing infrastructures that have been developed for existing cars. And, adoption can be incremental. Start with cars which drive themselves highway only, and require a capable driver to be at the wheel at all times. That may be soon. Gradually add more use cases at the speed of engineering, regulation, and social acceptance.

Some of the hard things to change in the world are hard because they require many people to change their behavior in coordination. Cars to self-driving cars doesn't. Email to Email with innovative clients doesn't. Introducing a new communication protocol does (though of course it's not impossible). Of course, this is only one aspect of a complex world.

SIGABRT (or similar) approach is similarly tempting. No checking for errors, no complicated control paths. If Unix systems let processes register (and unregister) files to be automatically deleted on abnormal exit, it'd be pretty convenient.

They're coming. The initial code for them is written; it's just waiting for a few other things to get checked in first.

Also, quite a lot of people use floats for every data value.

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.

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.

Your history omits an earlier chapter, which was the period during which Google introduced NaCl to the world.

http://research.google.com/pubs/archive/34913.pdf (2009)

http://blog.chromium.org/2010/05/sneak-peek-at-native-client... (2010)

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 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?

I don't understand this kind of sarcasm except as a way to insinuate an opinion without having to defend it. The article cites numerous sources.

[It's fine. And besides, everyone else is doing it.]

Fact-checking posts that cite their sources and speak calmly about relevant topics are useful.

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.

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.

This document lists some reasons [0]

• 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

Also, see [1].

[0] http://www.linux-kvm.org/wiki/images/7/70/Kvm-forum-2013-Mac... [1] https://www.ibm.com/developerworks/community/blogs/fe313521-...

Pretty much all of them do. Many of the big leaders in the C++ world, like Google, are pushing the idea that every last optimization technique is crucially vital. Google can bank on tenths-of-a-percent of performance, so why can't you? Google can devote armadas of armadas of test machines to run asan/tsan/space-alien-san and everything else continuously, and it works pretty well for them, so why can't you do this too?

To add to this, transpiling is a kind of compiling where the source code and target code have roughly the same level of abstraction. asm.js does appear to be more "low-level" than quake bytecode, so this is compiling, and not transpiling.

It's worth noting that Git's hashes guard against accidental corruption; they aren't widely thought to be strong against attack by an intelligent adversary.

Thanks for responding. Here's one additional suggestion:

The benchmarks you posted are extremely microscopic and artificial. They are so small, it's possible that LLVM is able to optimize them in ways that are less likely to be possible in any real application. If that's true, then their results don't predict anything about what the results of any real applications might be, and so they read like exaggerated claims. Consequently, while such benchmarks are often useful for development, they're inappropriate for high-level blog posts like this one.

If you don't have any better benchmark numbers to post at this time, that's not necessarily a problem. If you don't post any numbers, people will understand that it's a prototype and you haven't gotten there yet. That's ok.

But by posting these numbers without caveat, you give the appearance of making exaggerated claims.

There is some support for interfacing LLVM with a GC, but LLVM itself does not include a GC.