Out of curiosity, what do you do with either of these "pet" machines? I always have an idea to make a virtual machine cluster, or something similar, but I haven't taken the plunge yet.
I find them very useful for testing codes, as a sort of rapid-response travis. I run a script that pulls any new modification into each of my five "pets" (openbsd, slackware, freebsd, voidlinux+musl, dragonflybsd) and runs the tests. Since the systems are so different, it is very easy to break something. Since you notice it immediately (and not after waiting 1 minute for the travis answer) you develop a sense for avoiding non-portable things.
Slackware... they still active? No new stable builds in 4 years but seems to get security updates curiously. Their store leads to an error page in what looks like Chinese, confusingly.
We're around and it gained a bit more attention during a recent system wide change to many, more mainstream, distros that I'm sure most people here on HN don't really want to talk about (again).
I like it because it leans more closely to traditional BSD systems than System V variants like Red Hat.
Slackware still lives. I'm running it on my daily driver right now. I actually just started using Slackware a few months ago too, so it's gained at least one new user in the last 12 months.
Things definitely seem to move slower than on other OSes, but I much prefer it that way. I still run a supported LTS kernel and a supported LTS Firefox release; as long as security updates keep coming I don't feel the need to upgrade to newer software by and large.
The store thing is a sad state of affairs. Basically, as I understand it, the store was not run by Patrick Volkerding but by a third party that agreed to share profits with him from sales of Slackware branded merchandise. Patrick states that after a few years and much review he was basically being ripped off by them and withdrew permission for them to continue.
Although helped by many volunteers Slackware is mostly a one man show and Patrick's income from the project was basically drawing down to zero. It seems to be a long, drawn out affair and I'm trying to come across as neutral here as I'm sure I don't have all the information. But I'll admit some bias as I started my life with Linux using Slackware from a CD that came with a book about Linux, I think in 1994, maybe early 1995. I switched to more mainstream distros at some point based on me using them at various jobs but always liked the idea of Slackware (the most BSD like Linux!).
And I'm posting this from a laptop running -current. Yes, 15 has been a long time coming but Patrick continues to publish updates and the Slackware Security mailing list is alive and active.
I'm off topic here so I'll wind this up with a note that the GCC package for Slackware Current is gcc-9.2.0-i586-4.txz. So I'm sure 9.3 will be coming along soon, though not as quickly as with some other distros.
For those interested in more about the store I found the most relevant information here[1] when I last went looking for a way to contribute money to the project (i.e. to Patrick).
Yup. If you look at the end of the 'changes' link[1] you'll see individual bugzilla links for issues (or PRs as they call them) that were resolved in a given point release.
Honest question: what value does GCC have in 2020? It seems like llvm is the better designed compiler, more commercial support, more permissive license, etc. Pretty much everyone designing new languages today is using LLVM for backend codegen; and the people who aren't sure as hell are not using GCC.
It's still the "de facto" compiler on most flavors of Linux and still tends to produce faster binaries in practice than Clang. That gap, however, continues to narrow.
Clang has faster compilation, but (depending on the actual case) optimized binary built by gcc run faster; as mentioned above, both gaps are narrowing.
GCC has the same value that LLVM had when it was first released: healthy competition for the market leader. The need to compete with LLVM was the best thing that ever happened to the GCC project. A world with only LLVM could easily lead back to a stagnant monoculture.
Therefore, it's in everyone's selfish interest to promote and use both toolchains.
Right now, or last I checked, GCC supports more architectures. So while I realize that the Intel/ARM monoculture (or duoculture?) plus occasional emergence of things like risc-v will continue to absorb the world's new devices, there will probably be niche uses of GCC to target obscure hardware for a long time.
Competition and less permissive license (the license kind of ensures gcc can not be 'closed' and therefore ensure that llvm's license stays 'more permissive').
A few things off the top of my head, influenced by both trying to build Rust code for the Linux kernel as a hobby and maintaining compilers in my day job:
- GCC still supports more architectures/platforms than LLVM does. Apart from various rare/obscure/embedded platforms, one notable one (I think) is x86-16: .code16gcc pretty much works, LLVM only kinda supports it.
- GCC has its own plugin interface. If you already have GCC plugins, you probably want to stick with GCC.
- If you have a large legacy codebase that's probably got some UB somewhere because that's the nature of having large codebases written by fallible humans, it's probably less likely that a new versions of the same compiler will misinterpret your intentions than a new compiler would. (But this is a weak argument, since new versions could still change their interpretation/behavior.)
I think GCC often still outperforms LLVM for many people's workloads. Not sure why that is - haven't we gotten to the point where any missing optimisations can just be added to LLVM? Are some optimisations very hard to add given LLVM's architecture? There must be enough people and companies working on it by now to fix anything?
But if you're really serious about performance presumably you're using Intel.
Starting with GCC 9, you can stream gcov straight to stdout in json format, which allowed me to write a multi-core coverage aggregation/analysis tool[1] to replace lcov (and is over 100x faster than lcov, in my case - ymmv):
Aaaah if only I could do this to a runtime defined fd or pipe... Live coverage information! Have to use Intel PT for this but sometimes feels like a big hammer :-)
I use it because it outperforms both Intel and Clang on my code by significant margin. Open MP support in Clang on Windows comes and goes and no one cares (I don't blame them, it's a niche use case but still).
I don't see any reason to switch tbh. GCC does the job, is around for much longer, supports more stuff and generates more efficient code (at least in my case).
At the very least GCC is keeping llvm permissively licensed.
llvm is partly a product of Apple's dislike of copyleft licenses. Without gcc there is no reason for llvm's large proprietary contributors to stick to the "more permissive license" and simply close it down and distribute it as "value added" binaries.
I'm having trouble finding whether this is still true, but for a long time gcc was the only supported option for building Linux (the kernel). I know there's been work to make it build with clang, but it at least used to be that you needed some patches.
There's permissive and then there's exploitable. People who benefit (financially) from being able use other people's work without contributing their own changes would prefer us to call it "permissive" instead of "exploitive".
It's sad that the movement which originally democratized computing (by placing development tools into the hands of ordinary users) is slowly being changed into a pyramid scheme that fleeces volunteers.
So, to echo other comments in this thread; GCC keeps the corporate BSD crowd honest, and postpones the day when they lock up their code.
Going back to my initial reply, I did not say that everyone was using ICC, rather that desktop and game developers did not share the same opinion regarding ICC and Visual C++.
Specially given the lack of tooling that is only matched by C++ Builder, although I did not refer this point on my original reply.
So if you are reducing the world to just what Unreal, Source and CryEngine officially support, I wonder how many AAA games have been released on Windows using GCC or clang with those engines.
> I did not say that everyone was using ICC, rather that desktop and game developers did not share the same opinion regarding ICC and Visual C++
Yes, sure. MSVC is garbage clearly isn't right.
I presume (in the absence of any real data of course) that ICC doesn't result in significant performance advantages over MSVC, for games, or it would have been worth these developer's time to support it.
> if you are reducing the world to just what Unreal, Source and CryEngine officially support
It's a reduction sure enough, but I think that's a reasonable set of engines to consider.
> I wonder how many AAA games have been released on Windows using GCC or clang with those engines
I imagine it's none.
According to the (quite possibly stale) official wiki, Source does not support Clang, and only supports GCC for building Linux dedicated servers. [0]
It looks like Unreal Engine supports Clang for Linux builds [1], but for Windows it seems they really only support MSVC, although Clang can be made to work [2][3]
CryEngine supports Clang for Linux builds [4], but not for Windows where it seems to be MSVC-only [5][6]
Here's a key paragraph from Anandtech's recent article on ARM in AWS:
> Overall, I checked three different compiler setups: A freshly compiled GCC 9.2.0 release, Arm’s Allinea Studio Compiler 20 package which comes with both Arm’s closed source LLVM and Flang variants as well as a pre-compiled version of GCC 9.2.0, and Marvell’s branch of LLVM and Flang.
Note the phrases "ARM's closed source LLVM" and "Marvell's branch of LLVM". That's why GCC is still critical. Because LLVM is already suffering from the fragmentation and proprietary forks that BSD has always suffered from.
Definitely can be done with a little bit of impedance losses depending on what you care about. I once wrote it for block floating point on hardware that didn't support it. You can use custom literal suffixes too.
mratsim is right that the solution is to just improve the code-generation for the existing intrinsics. Given that the intrinsics already exist in GCC, optimising the code is the right way to handle it. (Intrinsics still have their usual obvious downsides, mainly non-portability.)
JIT seems a poor fit. JIT makes the most sense where the desired program behaviour is variable. Intrinsics fit perfectly here.
Templates don't help solve the problem, but they might be a good way to expose the functionality to C++ programmers.
Assembly is how you'd solve the problem efficiently in the absence of a compiler intrinsic. Intrinsics should be able to do an even better job.
57 comments
[ 0.27 ms ] story [ 121 ms ] threadThe changelog seems to be, uhh, changing, so that's good I guess. I'm not sure they have many users left though.
I like it because it leans more closely to traditional BSD systems than System V variants like Red Hat.
Many updates are pushed to https://slackbuilds.org/ every week.
Things definitely seem to move slower than on other OSes, but I much prefer it that way. I still run a supported LTS kernel and a supported LTS Firefox release; as long as security updates keep coming I don't feel the need to upgrade to newer software by and large.
Although helped by many volunteers Slackware is mostly a one man show and Patrick's income from the project was basically drawing down to zero. It seems to be a long, drawn out affair and I'm trying to come across as neutral here as I'm sure I don't have all the information. But I'll admit some bias as I started my life with Linux using Slackware from a CD that came with a book about Linux, I think in 1994, maybe early 1995. I switched to more mainstream distros at some point based on me using them at various jobs but always liked the idea of Slackware (the most BSD like Linux!).
And I'm posting this from a laptop running -current. Yes, 15 has been a long time coming but Patrick continues to publish updates and the Slackware Security mailing list is alive and active.
I'm off topic here so I'll wind this up with a note that the GCC package for Slackware Current is gcc-9.2.0-i586-4.txz. So I'm sure 9.3 will be coming along soon, though not as quickly as with some other distros.
For those interested in more about the store I found the most relevant information here[1] when I last went looking for a way to contribute money to the project (i.e. to Patrick).
[1]https://www.linuxquestions.org/questions/slackware-14/donati...
edit: grammar
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED...
[1] https://gcc.gnu.org/gcc-9/changes.html
We should expect them to both continue to improve. It's not a sure thing that Clang will end up the clear winner.
Example of GCC awful codegen on add with carry: https://gcc.godbolt.org/z/2h768y
Therefore, it's in everyone's selfish interest to promote and use both toolchains.
- firefox and chrome
- ios and android
- mysql and postgres
- C# and Java
More generally of course, healthy competition is good. There are more than 2 serious Java IDEs, for instance.
- GCC still supports more architectures/platforms than LLVM does. Apart from various rare/obscure/embedded platforms, one notable one (I think) is x86-16: .code16gcc pretty much works, LLVM only kinda supports it.
- GCC has its own plugin interface. If you already have GCC plugins, you probably want to stick with GCC.
- If you have a large legacy codebase that's probably got some UB somewhere because that's the nature of having large codebases written by fallible humans, it's probably less likely that a new versions of the same compiler will misinterpret your intentions than a new compiler would. (But this is a weak argument, since new versions could still change their interpretation/behavior.)
But if you're really serious about performance presumably you're using Intel.
Or a GPU?
Starting with GCC 9, you can stream gcov straight to stdout in json format, which allowed me to write a multi-core coverage aggregation/analysis tool[1] to replace lcov (and is over 100x faster than lcov, in my case - ymmv):
[1] https://github.com/RPGillespie6/fastcov
llvm is partly a product of Apple's dislike of copyleft licenses. Without gcc there is no reason for llvm's large proprietary contributors to stick to the "more permissive license" and simply close it down and distribute it as "value added" binaries.
Not everyone favors a more permissive license.
It's sad that the movement which originally democratized computing (by placing development tools into the hands of ordinary users) is slowly being changed into a pyramid scheme that fleeces volunteers.
So, to echo other comments in this thread; GCC keeps the corporate BSD crowd honest, and postpones the day when they lock up their code.
ICC produces faster binaries than GCC, but ICC is expensive and GCC is free.
MSVC is garbage.
Would the average Unreal-based game be built with ICC?
https://software.intel.com/en-us/gamedev/tools
Unreal Engine 4 doesn't officially support icc, for instance. Neither does the Source Engine. I believe the same goes for CryEngine.
Specially given the lack of tooling that is only matched by C++ Builder, although I did not refer this point on my original reply.
So if you are reducing the world to just what Unreal, Source and CryEngine officially support, I wonder how many AAA games have been released on Windows using GCC or clang with those engines.
Yes, sure. MSVC is garbage clearly isn't right.
I presume (in the absence of any real data of course) that ICC doesn't result in significant performance advantages over MSVC, for games, or it would have been worth these developer's time to support it.
> if you are reducing the world to just what Unreal, Source and CryEngine officially support
It's a reduction sure enough, but I think that's a reasonable set of engines to consider.
> I wonder how many AAA games have been released on Windows using GCC or clang with those engines
I imagine it's none.
According to the (quite possibly stale) official wiki, Source does not support Clang, and only supports GCC for building Linux dedicated servers. [0]
It looks like Unreal Engine supports Clang for Linux builds [1], but for Windows it seems they really only support MSVC, although Clang can be made to work [2][3]
CryEngine supports Clang for Linux builds [4], but not for Windows where it seems to be MSVC-only [5][6]
[0] https://developer.valvesoftware.com/wiki/Compiler_Choices
[1] https://wiki.unrealengine.com/Compiling_For_Linux
[2] https://docs.unrealengine.com/en-US/Programming/Development/...
[3] https://forums.unrealengine.com/development-discussion/engin...
[4] https://docs.cryengine.com/display/SDKDOC4/CRYENGINE+on+Linu...
[5] https://github.com/CRYTEK/CRYENGINE/issues/381
[6] https://docs.cryengine.com/display/CEPROG/Building+the+Engin...
> Overall, I checked three different compiler setups: A freshly compiled GCC 9.2.0 release, Arm’s Allinea Studio Compiler 20 package which comes with both Arm’s closed source LLVM and Flang variants as well as a pre-compiled version of GCC 9.2.0, and Marvell’s branch of LLVM and Flang.
Note the phrases "ARM's closed source LLVM" and "Marvell's branch of LLVM". That's why GCC is still critical. Because LLVM is already suffering from the fragmentation and proprietary forks that BSD has always suffered from.
GCC codegen for add with carry, even with the addcarry_u64 intrinsics is a disgrace[1].
[1]: https://gcc.godbolt.org/z/2h768y
JIT seems a poor fit. JIT makes the most sense where the desired program behaviour is variable. Intrinsics fit perfectly here.
Templates don't help solve the problem, but they might be a good way to expose the functionality to C++ programmers.
Assembly is how you'd solve the problem efficiently in the absence of a compiler intrinsic. Intrinsics should be able to do an even better job.