Comment by BooneJS | Hacker News Reader

Comment by BooneJS | Hacker News Reader

Parent Full thread

It's true that Intel (note, I'm a former employee) has had a mixed track record in creating new businesses outside of desktop and server chips. However, I'd like to point out a few things.

1. When Intel released HT as a way to recover 15% idleness in CPUs, the Linux scheduler took a while before it realized it should schedule work on all full cores before assigning something to a hyperthread.

2. Intel has been adding specialized SIMD vector operations, and wide vector operations, yet popular compilers like GCC were really slow to take advantage of them. One or two blog posts a month will hit the HN front page about inlining assembly or using specialized math APIs like the Intel MKL to extract performance from the cores you're running on.

Apple can add neat blocks like audio, low power video playback, always-on processor, and neural engine because they also release the software APIs for it. Maybe that's Intel's sin. They never realized how hands-off the white box industry needed to be to stay alive and relied too much on OSS developers to fuel general-purpose Linux performance outside of large HPC computers. Intel made add-on things, people didn't use them, and now Intel is perceived as the company that can't innovate.

> the Linux scheduler took a while before it realized it should schedule work on all full cores before assigning something to a hyperthread.

According to statistics maintained by LWN [1], Intel was the number #1 employer of Linux kernel developers in the latest kernel, and has been for a while. If you go back into previous years, Intel was not always as high up, but even back in 2007 (when LWN started tracking this) they were in the top 5-10 (depending on how you count it.)

Intel released HT way back in 2002. I don't know how active Intel was in Linux kernel development back then. But what Intel was or wasn't doing 18 years ago probably isn't very relevant to the question of Intel's current performance.

[1] https://kernelnewbies.org/DevelopmentStatistics

I’ll borrow the old BSD/linux saying about intel is a group cpu makers writing an OS Where Apple is and OS maker that designed a cpu

This is very interesting. I know Intel has their own compilers, but wouldn't seconding a couple engineers to the GCC/LLVM teams yield exactly the benefit you're describing here? It's a trivial cost to boost their own add-ons.

Intel's handling of ICC has always puzzled me. I'd bet Intel could live without any of the money it made them. Yet, they never open-sourced it so that GCC/LLVM could catch up faster with any tricks that gave ICC a performance edge. Knowing that Intel chips were fully supported by all major compilers would probably translate to more chip sale profits than the profits of selling ICC as a tool. The least they could have done was to release a stripped down version (e.g. without advanced profiling tools) as a no-nonsense free download.

Right. Because AMD had the same instructions (but presumably different pipeline timings?), they kept their secrets behind a bit of a wall which added friction for people who would have liked extra performance but not been willing to jump through the hoops required to get it.

So now Intel chips are limiting battery life because every application is executing unoptimized garbage that runs longer and therefore uses more energy. Meanwhile, Apple Xcode will produce optimized binaries for Apple Silicon and the press will go wild.

That would also have made it easy for a fork to remove the code which disabled optimizations on AMD processors. I suspect that their managers viewed this as an edge since they could post high benchmark scores even if most common software didn’t use icc.

It's actually easy to work around the AMD deoptimization by just pretending to be an Intel CPU when the check is made - no need to fork the code.

On the bigger point, it ends up hurting them because companies often use gcc to benchmark across systems, so the Intel performance comes out lower than it might be if Intel really invested heavily in gcc rather than icc.

Yes, you can bypass the check by editing the binary but that’s a non-trivial extra step and, more importantly, it means you can’t use the official binaries for anything. Far from insurmountable but it’s the kind of things sales guys are going to make sure every large customer‘s senior management hears.

Some people in the FOSS community don’t like proprietary vendor lock in and things like Intel MKL.

Standardise the features you add, work with AMD and I’m sure you’ll get more support.

It also makes building high-performance open source software challenging. Intel or AMD? If Intel, is the MKL library installed? The support matrix grows a bit out of hand.

This is especially important with vector instructions. I had to install Tensorflow 2 years ago and there were four packages available in the repositories:

- nVidia GPU with CUDA

- CPU with SSEv2 (or whatever the second version of vector was called) optimizations

- CPU with SSE optimizations

- CPU without vector optimizations

You mean AVX2? SSE was from the 90s

Yes

Although I'm not familiar with the specifics of (1) and (2), the characterization that Intel "took a while" or "were really slow" to enable features might be a bit unfair. (I am also a former employee)

Keep in mind that Intel's ability to properly light up new silicon features on your PC often relies upon your willingness to update your software. For instance, even if the SMT scheduler fix has been written and upstreamed, the next Ubuntu LTS to integrate the change may be 18 months away. The end user will believe that Intel is taking a long time to develop the fix.

Is Intel engaged in these communities?

My naive POV - It would seem worthwhile for Intel to participate in GCC/Linux to accelerate adoption of these innovations... PRs welcome, etc. (though I realize it’s often more complicated than that)

Reply on news.ycombinator.com