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.