Kernel developers appear to be eager to debate the merits of potentially allowing Rust code within the Linux kernel. Linus Torvalds himself has made some initial remarks on the topic ahead of the Linux Plumbers 2020 conference where the matter will be discussed at length.
[...] Linus Torvalds chimed in though with his own opinion on the matter. Linus commented that he would like it to be effectively enabled by default to ensure there is widespread testing and not any isolated usage where developers then may do "crazy" things. He isn't calling for Rust to be a requirement for the kernel but rather if the Rust compiler is detected on the system, Kconfig would enable the Rust support and go ahead in building any hypothetical Rust kernel code in order to see it's properly built at least.
According to a mailing list post spotted by Phoronix, Linux creator Linus Torvalds has shared his strong views on the AVX-512 instruction set. The discussion arose as a result of recent news that Intel's upcoming Alder Lake processors reportedly lack support for AVX-512.
Torvalds' advice to Intel is to focus on things that matter instead of wasting resources on new instruction sets, like AVX-512, that he feels aren't beneficial outside the HPC market.
After many years of waiting, version 1.0 of the Rust programming language has finally been released. The Rust home page describes Rust as "a systems programming language that runs blazingly fast, prevents nearly all segfaults, and guarantees thread safety."
Thanks to the hard work of noted Rust core team members Yehuda Katz and Steve Klabnik, Rust is now poised to become a serious competitor to established systems programming languages like C and C++.
The announcement has brought much jubilation to the followers of Rust, who have been eagerly awaiting this milestone release for so long. With only 1,940 open issues and over 11,500 issues already closed, Rust is finally ready for users to build fantastically reliable software systems using it.
[Ed. Note: The first link seems to have been pulled from the web after this story was accepted. We apologize that we have been unable to find a link to replace it.]
"The Results are in! Thank you to all 3103 of you who responded to our first Rust community survey. We were overwhelmed by your responses, and as we read your comments we were struck by the amount of time and thought you put into them. It's feedback like this that will help us focus our energy and make sure Rust continues to grow the best way. A big reason for having the survey was to make the results available publically so that we can talk about it and learn from it together. In this blog post, we'll take a first look at the survey responses, including themes in the comments, demographics, and quantitative feedback.
Do You Use Rust?
We wanted to make sure the survey was open to both users of Rust as well as people who didn't use Rust. Rust users help us get a sense of how the current language and tools are working and where we need to improve. Rust non-users give us another perspective, and help shed light on the kinds of things that get in the way of someone using Rust. I'm happy to report that more than a third of the responses were from people not using Rust. This gave us a lot of great feedback on those roadblocks, which we'll talk about in this (and upcoming) blog posts.
But first, let's look into the feedback from Rust users.
How long have you been using Rust?
Almost 2000 people responded saying they were Rust users. Of these, almost 24% were new users. This is encouraging to see. We're still growing, and we're seeing more people playing with Rust now that could become long-term users. Equally encouraging is seeing that once someone has become a Rust user, they tend to stick around and continue using it. One might expect a sharp drop-off if users became quickly disenchanted and moved onto other technologies. Instead, we see the opposite. Users that come in and stay past their initial experiences tend to stay long-term, with a fairly even spread between 3 months to 12 months (when we first went 1.0).
There is much more to be found in the full story for Rust aficionados.
Imagine if we could use vector processing on something other than just floating point problems. Today, GPUs and CPUs work tirelessly to accelerate algorithms based on floating point (FP) numbers. Algorithms can definitely benefit from basing their mathematics on bits and integers (bytes, words) if we could just accelerate them too. FPGAs can do this, but the hardware and software costs remain very high. GPUs aren't designed to operate on non-FP data. Intel AVX introduced some support, and now Intel AVX-512 is bringing a great deal of flexibility to processors. I will share why I'm convinced that the "AVX512VL" capability in particular is a hidden gem that will let AVX-512 be much more useful for compilers and developers alike.
Fortunately for software developers, Intel has done a poor job keeping the "secret" that AVX-512 is coming to Intel's recently announced Xeon Scalable processor line very soon. Amazon Web Services has publically touted AVX-512 on Skylake as coming soon!
It is timely to examine the new AVX-512 capabilities and their ability to impact beyond the more regular HPC needs for floating point only workloads. The hidden gem in all this, which enables shifting to AVX-512 more easily, is the "VL" (vector length) extensions which allow AVX-512 instructions to behave like SSE or AVX/AVX2 instructions when that suits us. This is a clever and powerful addition to enable its adoption in a wider assortment of software more quickly. The VL extensions mean that programmers (and compilers) do not need to shift immediately from 256-bits (AVX/AVX2) to 512-bits to use the new bit/byte/word manipulations. This transitional benefit is useful not only for an interim, but also for applications which find 256-bits more natural (perhaps a small, but important, subset of problems).
Will it be enough to stave off "Epyc"?
Linux kernel head Linus Torvalds has trashed a patch from Amazon Web Services (AWS) engineers that was aimed at mitigating the Snoop attack on Intel CPUs discovered by an AWS engineer earlier this year. [...] AWS engineer Pawel Wieczorkiewicz discovered a way to leak data from an Intel CPU's memory via its L1D cache, which sits in CPU cores, through 'bus snooping' – the cache updating operation that happens when data is modified in L1D.
In the wake of the disclosure, AWS engineer Balbir Singh proposed a patch for the Linux kernel for applications to be able to opt in to flush the L1D cache when a task is switched out. [...] The feature would allow applications on an opt-in basis to call prctl(2) to flush the L1D cache for a task once it leaves the CPU, assuming the hardware supports it.
But, as spotted by Phoronix, Torvalds believes the patch will allow applications that opt in to the patch to degrade CPU performance for other applications.
"Because it looks to me like this basically exports cache flushing instructions to user space, and gives processes a way to just say 'slow down anybody else I schedule with too'," wrote Torvalds yesterday. "In other words, from what I can tell, this takes the crazy 'Intel ships buggy CPU's and it causes problems for virtualization' code (which I didn't much care about), and turns it into 'anybody can opt in to this disease, and now it affects even people and CPU's that don't need it and configurations where it's completely pointless'."
Rust's core team and Mozilla are announcing plans to create a Rust foundation with the hopes of establishing this legal entity by year's end. The trademarks and related assets of Rust, Cargo, and Crates.io will belong to this foundation. Work is well underway on establishing this foundation with originally coming to the idea of possibly creating an independent Rust foundation last year, now pushed along by the recent Mozilla layoffs and the global pandemic. This should allow the Rust community more safety rather than being reliant upon a sole organization (Mozilla) and help foster growth and open up new possibilities.
There's nothing quite like some fun holiday-weekend reading as a fiery mailing list post by Linus Torvalds. The Linux creator is out with one of his classical messages, which this time is arguing over the importance of ECC memory and his opinion on how Intel's "bad policies" and market segmentation have made ECC memory less widespread.
Linus argues that error-correcting code (ECC) memory "absolutely matters" but that "Intel has been instrumental in killing the whole ECC industry with it's horribly bad market segmentation... Intel has been detrimental to the whole industry and to users because of their bad and misguided policies wrt ECC. Seriously...The arguments against ECC were always complete and utter garbage... Now even the memory manufacturers are starting [to] do ECC internally because they finally owned up to the fact that they absolutely have to. And the memory manufacturers claim it's because of economics and lower power. And they are lying bastards - let me once again point to row-hammer about how those problems have existed for several generations already, but these f*ckers happily sold broken hardware to consumers and claimed it was an "attack", when it always was "we're cutting corners"."
Ian Cutress from AnandTech points out in a reply that AMD's Ryzen ECC support is not as solid as believed.
Related: Linus Torvalds: 'I'm Not a Programmer Anymore'
Linus Torvalds Rejects "Beyond Stupid" Intel Security Patch From Amazon Web Services
Linus Torvalds: Don't Hide Rust in Linux Kernel; Death to AVX-512
Linus Torvalds Doubts Linux will Get Ported to Apple M1 Hardware
Intel's next-generation "Rocket Lake" CPUs will be some of Intel's last desktop models on a "14nm" node, and include "backported" Willow Cove cores (referred to as "Cypress Cove") from "10nm" Tiger Lake mobile CPUs, with improved instructions per clock. Notably, the lineup only goes up to 8 cores, instead of 10 cores for the previous Core i9. The review embargo ends on the launch date, March 30th, but some retailers have been selling the CPUs early. AnandTech obtained an 8-core i7-11700K and wrote a review of it. The results were not great.
Power consumption of the 125 W TDP chip peaked at 224.56 W when running an AVX2 workload, compared to 204.79 W for its i7-10700K "Comet Lake" predecessor and 141.45 W for AMD's Ryzen 7 5800X. The i7-11700K reached 291.68 W with an AVX-512 workload.
The i7-11700K not only failed to beat the 5800X in many benchmarks, but trailed the previous-gen i7-10700K in some cases. The major exception is performance in AVX-512 workloads. Gaming performance of the i7-11700K was particularly bad, in part due to an increase in L3 cache and core-to-core latency.
It's possible that there will be some improvements from a final microcode update before launch. There's also models like the Core i9-11900K, which have the same 8 cores but can clock up to 300 MHz higher.
In a blunt video posted late Thursday evening, outspoken former Intel principal engineer Francois Pidnoel offered his advice on how to "fix" Intel CPUs, criticized current leadership for not being engineers, said AVX512 was a misadventure, and declared that it's only luck AMD hasn't grabbed more market share.
"First, Intel is really out of focus," Piednoel said in the nearly hour-long video presentation. "The leaders of Intel today are not engineers, they are not people who understand what to design to the market."
[...] Pidnoel flat-out dismissed including AVX512 in consumer chips as a mistake. "You had Skylake and Skylake X for a reason," Piednoel said. "AVX512 is designed for a race of throughput that is lost to the GPU already. There's two ways to get throughput. One is to get the throughput is by having larger vectors to your core, and the other way is to have more cores."
[...] "Intel is very lucky AMD cannot get the volume, to be able to compete," Piednoel. "If they were getting volume, the price difference would definitely cost Intel market share a lot more than what they are losing right now."
Related: AVX-512: A "Hidden Gem"?
Intel CEO Blames "10nm" Delays on Aggressive Density Target, Promises "7nm" for 2021
Intel's Process Nodes Will Trail Behind Competitors Until at Least Late 2021
Linus Torvalds: Don't Hide Rust in Linux Kernel; Death to AVX-512
Intel Engineering Chief Out After 7nm Product Delays
Intel Faces Class-Action Lawsuit Over "7nm" Delays
The Internet Security Research Group (ISRG)—parent organization of the better-known Let's Encrypt project—has provided prominent developer Miguel Ojeda with a one-year contract to work on Rust in Linux and other security efforts on a full-time basis.
As we covered in March, Rust is a low-level programming language offering most of the flexibility and performance of C—the language used for kernels in Unix and Unix-like operating systems since the 1970s—in a safer way.
Efforts to make Rust a viable language for Linux kernel development began at the 2020 Linux Plumbers conference, with acceptance for the idea coming from Linus Torvalds himself. Torvalds specifically requested Rust compiler availability in the default kernel build environment to support such efforts—not to replace the entire source code of the Linux kernel with Rust-developed equivalents, but to make it possible for new development to work properly.
Using Rust for new code in the kernel—which might mean new hardware drivers or even replacement of GNU Coreutils—potentially decreases the number of bugs lurking in the kernel. Rust simply won't allow a developer to leak memory or create the potential for buffer overflows—significant sources of performance and security issues in complex C-language code.