This makes me wonder if Guix is ready for the real world.
ML and GPUs are a smallish subset of the real world, and a subset that's particularly plagued by proprietary software (especially the GPU side); I don't think it's a good litmus test for "is guix useful for real work".
The stance on non-free stops me from using it. Amdgpu is open source down to and including the Linux kernel. But each card has a couple of kilobytes of binary firmware file, so no deal.
That firmware could literally ship on the card totally invisibly and that would be fine for guix, but because it can be patched in the field, no.
That's just.. so counterproductive. They are ok with proprietary software, but only if they come builtin.
But there are some spectre and meltdown mitigations that comes with CPU microcode, right? It's probably not a great idea to not apply microcode updates in this case
Ok, s/k/m. I remembered small and didn't check. Doesn't change the underlying point though - so what? The same guys who shipped the silicon also shipped some magic numbers with it. If you trust one, may as well trust the other, since they're equivalent.
There are a bunch of things that come up regularly on HN that aren’t particularly relevant to the real world so I don’t think this logic is good. Though I think you are correct that ML is relevant to the real world. However when you wrote ‘the real world’ you didn’t mean the thing for which ML is relevant but rather ‘being a general purpose operating system that is useful [to software developers]’ and for this I think the lack of hardware-accelerated PyTorch isn’t great but I don’t think training/running ML models is particularly relevant to being a general purpose OS (even for software developers). I’m not sure it’s even relevant to ML practitioners as I would expect they’d be farming out training to a dedicated compute cluster.
One needs to jump through a bunch of hoops to get hardware-accelerated PyTorch on Apple’s latest computers. Does that mean they aren’t ready for the real world?
I mean, to run the software developed by ML practitioners, you basically end up in dependency hell every time you try out something new. This is exactly where an autobuild/package system such as Guix is supposed to shine.
ML is also increasingly relevant for OSes, think OCR and speech recognition, but also painting programs. Image classification and segmentation are used in industrial systems; lots of ML happens on servers. And this is where Linux shines, and thus support from Guix would be great. Categorically excluding this group of GPU users is a mistake.
One needs to jump through a bunch of hoops to get hardware-accelerated PyTorch on Apple’s latest computers. Does that mean they aren’t ready for the real world?
I think Guix is more than ready for providing development environments, even for proprietary apps on open source technology stacks (but Nix will probably be easier to pitch). As an operating system much less so.
ld: /tmp/guix-build-python-pytorch-1.12.0.drv-0/source/build/lib/libtorch_cpu.so: undefined reference to `glslang::TShader::setNanMinMaxClamp(bool)'
ld: /tmp/guix-build-python-pytorch-1.12.0.drv-0/source/build/lib/libtorch_cpu.so: undefined reference to `spvtools::CreateCompactIdsPass()'
[...]
The reason is because pytorch 1.12.0 depends on shaderc-2020.4/lib/libshaderc_combined.a--and static libraries do not have automatic dependency resolution, so spirv, glsl etc is never linked.
There's a shaderc_combined.pc in shaderc, but it doesn't lists glslang or spirv as dependencies, even though shaderc uses glslang and spirv data structures and functions. Errrrr. How's that supposed to work?
If Guix uses Nix under the hood, is it "just" Nix with an S-expression syntax (admittedly much better than Nix syntax) and fewer packages? If so, is there a really compelling reason to prefer Guix over NixOS? The only substantive difference I'm aware of is the use of GNU Shepherd instead of systemd.
Same backend, but different frontend, so to speak. Hence, it used to be possible to have nix and guix share a store and local state directory. Not sure if that's still possible today, though...
Comments
Kind of disappointing that the Guix pytorch package has no GPU support:
https://guix.gnu.org/en/packages/python-pytorch-1.12.0/
This makes me wonder if Guix is ready for the real world.
ML and GPUs are a smallish subset of the real world, and a subset that's particularly plagued by proprietary software (especially the GPU side); I don't think it's a good litmus test for "is guix useful for real work".
The stance on non-free stops me from using it. Amdgpu is open source down to and including the Linux kernel. But each card has a couple of kilobytes of binary firmware file, so no deal.
That firmware could literally ship on the card totally invisibly and that would be fine for guix, but because it can be patched in the field, no.
I don't get it.
They shouldn't ship at all on any CPU arch that uses microcode since it's also just closed firmware blobs!
I'm a little confused how x64 gets away with this. Do they just stubbornly use whatever microcode was on it when the system switched on?
Unfortunately yes. The nonfree channel linked in this thread does/has microcode updates but mainline guix doesn't.
That's just.. so counterproductive. They are ok with proprietary software, but only if they come builtin.
But there are some spectre and meltdown mitigations that comes with CPU microcode, right? It's probably not a great idea to not apply microcode updates in this case
For the record, vega10 has almost 2 MiB worth of firmware after extracting:
# du -bs gpu/
2053094 gpu
Ok, s/k/m. I remembered small and didn't check. Doesn't change the underlying point though - so what? The same guys who shipped the silicon also shipped some magic numbers with it. If you trust one, may as well trust the other, since they're equivalent.
One is immutable, one isn't.
ML and GPUs are on HN's front page almost every day ...
There are a bunch of things that come up regularly on HN that aren’t particularly relevant to the real world so I don’t think this logic is good. Though I think you are correct that ML is relevant to the real world. However when you wrote ‘the real world’ you didn’t mean the thing for which ML is relevant but rather ‘being a general purpose operating system that is useful [to software developers]’ and for this I think the lack of hardware-accelerated PyTorch isn’t great but I don’t think training/running ML models is particularly relevant to being a general purpose OS (even for software developers). I’m not sure it’s even relevant to ML practitioners as I would expect they’d be farming out training to a dedicated compute cluster.
One needs to jump through a bunch of hoops to get hardware-accelerated PyTorch on Apple’s latest computers. Does that mean they aren’t ready for the real world?
I mean, to run the software developed by ML practitioners, you basically end up in dependency hell every time you try out something new. This is exactly where an autobuild/package system such as Guix is supposed to shine.
ML is also increasingly relevant for OSes, think OCR and speech recognition, but also painting programs. Image classification and segmentation are used in industrial systems; lots of ML happens on servers. And this is where Linux shines, and thus support from Guix would be great. Categorically excluding this group of GPU users is a mistake.
They are. But their packaging systems are not.
You can use this channel to get non-GNU sanctioned software, including kernels and drivers: https://gitlab.com/nonguix/nonguix
Furthermore, you can install Nix in Guix: https://guix.gnu.org/packages/nix-2.5.1
then why not just install Nix in the first place??
You prefer using guix but want a package Nix has already packaged and don't have the time and knowledge to package it yourself.
I use NixOS, but GuixSD users might find this option useful.
So aren't articles about developers and work-life balance.
Can't say the N word in Guix
I think Guix is more than ready for providing development environments, even for proprietary apps on open source technology stacks (but Nix will probably be easier to pitch). As an operating system much less so.
nVidia? Nix? Or Nonguix?
Yes.
Don't forget about non-GNU.
Also, Nonfree.
In the context of pytorch: nvidia
Guix already sees use in the 'real world' in a number of HPC environments.
I tried to change Guix to enable vulkan in pytorch and I get a build error. Since I don't use pytorch I didn't investigate further.
If you do know the build options to make this work, Guix will gladly consider your patch.
The in-progress diff would be,
Error messages: : && /gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/bin/c++ -Wno-deprecated -fvisibility-inlines-hidden -DUSE_PTHREADPOOL -fopenmp -DNDEBUG -DUSE_KINETO -DLIBKINETO_NOCUPTI -DUSE_QNNPACK -DUSE_PYTORCH_QN NPACK -DUSE_XNNPACK -DUSE_VULKAN -DUSE_VULKAN_API -DUSE_VULKAN_SHADERC_RUNTIME -DSYMBOLICATE_MOBILE_DEBUG_HANDLE -DEDGE_PROFILER_USE_KINETO -O2 -fPIC -Wno-narrowing -Wall -Wextra -Werror=return-type -Wno-missing -field-initializers -Wno-type-limits -Wno-array-bounds -Wno-unknown-pragmas -Wno-unused-parameter -Wno-unused-function -Wno-unused-result -Wno-unused-local-typedefs -Wno-strict-overflow -Wno-strict-aliasing -Wno -error=deprecated-declarations -Wno-stringop-overflow -Wno-psabi -Wno-error=pedantic -Wno-error=redundant-decls -Wno-error=old-style-cast -fdiagnostics-color=always -faligned-new -Wno-unused-but-set-variable -Wn o-maybe-uninitialized -fno-math-errno -fno-trapping-math -Werror=format -Werror=cast-function-type -Wno-stringop-overflow -DHAVE_AVX512_CPU_DEFINITION -DHAVE_AVX2_CPU_DEFINITION -O3 -DNDEBUG -DNDEBUG -rdynamic - pthread caffe2/CMakeFiles/scalar_test.dir/__/aten/src/ATen/test/scalar_test.cpp.o -o bin/scalar_test -Wl,-rpath,/tmp/guix-build-python-pytorch-1.12.0.drv-0/source/build/lib: -lgtest_main -lgtest /gnu/store/0 94bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/libgomp.so /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libpthread.so -Wl,--no-as-needed,"/tmp/guix-build-python-pytorch-1.12.0.drv-0/source/bui ld/lib/libtorch.so" -Wl,--as-needed -Wl,--no-as-needed,"/tmp/guix-build-python-pytorch-1.12.0.drv-0/source/build/lib/libtorch_cpu.so" -Wl,--as-needed /gnu/store/9pyydl5w9xnz1qm56sxn1zh4qny6fkxz-protobuf-3.17.3 /lib/libprotobuf.so lib/libc10.so -pthread && : The reason is because pytorch 1.12.0 depends on shaderc-2020.4/lib/libshaderc_combined.a--and static libraries do not have automatic dependency resolution, so spirv, glsl etc is never linked.Just tried--same problem with pytorch 1.12.1.
So that's why it's not enabled.
pytorch is using shaderc_combined.a.
There's a shaderc_combined.pc in shaderc, but it doesn't lists glslang or spirv as dependencies, even though shaderc uses glslang and spirv data structures and functions. Errrrr. How's that supposed to work?
If Guix uses Nix under the hood, is it "just" Nix with an S-expression syntax (admittedly much better than Nix syntax) and fewer packages? If so, is there a really compelling reason to prefer Guix over NixOS? The only substantive difference I'm aware of is the use of GNU Shepherd instead of systemd.
As far as I know it doesn't use nix under the hood, it's a reimplementation of nix in guile scheme.
Ah, my mistake. I was certain it wrapped around Nix for some reason.
Same backend, but different frontend, so to speak. Hence, it used to be possible to have nix and guix share a store and local state directory. Not sure if that's still possible today, though...
It isn't.