5 ms·
With energy efficiency as a primary goal I was expecting way more use of explicit SIMD instructions. The InfoQ post mentions xcodebuild, but there is also a Ma
by svckr 10y ago
With energy efficiency as a primary goal I was expecting way more use of explicit SIMD instructions.
The InfoQ post mentions xcodebuild, but there is also a Makefile. I really appreciate the presence of a no-nonsense Makefile. No autoconf, no pkgconfig, just plain and simple make. Also, because nobody mentioned it: yes, it compiles on Linux out of the box.
- sjwright 10y agoIt's entirely possible that Apple have a SIMD-optimised version targeting their in-house CPUs but have chosen only to open source their reference implementation.
- gsnedders 10y ago> With energy efficiency as a primary goal I was expecting way more use of explicit SIMD instructions. I remember reading one paper whose conclusion was running SIMD instructions can be bad for power consumption: while you need the processor in a higher power state for longer without, you can keep the SIMD unit powered off. [Edit: That said, I have no idea how true this is for the modern Intel CPUs yet alone Apple's custom SoCs.]
- astrange 10y agoThis can be true if it's the only time it's used, but when memcpy and everything use the SIMD operations, it's a lost cause. Instead you just want to go as fast as possible, so you can go back to sleep. They call it "race to idle".
- eln1 10y agoIt is poorly optimized for 32bits - some benchmarks: http://encode.ru/threads/2221-LZFSE-New-Apple-Data-Compression?p=48519&viewfull=1#post48519 http://encode.ru/threads/2221-LZFSE-New-Apple-Data-Compressi...
- talideon 10y agoI don't mind pkg-config that much: if anything, it's one of the more sensible portability mechanisms out there.
- vog 10y ago> I really appreciate the presence of a no-nonsense Makefile. Indeed, the current version of their Makefile is a great example of how to write a simple yet portable Makefile: https://github.com/lzfse/lzfse/blob/33629bc65f4b356072c9a7d5b6321d3b360ed5ec/Makefile https://github.com/lzfse/lzfse/blob/33629bc65f4b356072c9a7d5... > No autoconf, no pkgconfig, just plain and simple make. While I agree with your sentiment, I believe that your statement about pkg-config goes a bit over the top. Yes, the LZFSE project doesn't use pkg-config, but it also doesn't have any library dependencies. There's not a single "-l" argument in the linker flags. If it had, I would prefer pkg-config over any other mechanism, as that is right now the best "simple yet portable" method of defining library dependencies. Pkg-config is especially handy when it comes to cross-compiling, or when you have a special need for a static build instead of shared libraries.
- mschuster91 10y ago> Indeed, the current version of their Makefile is a great example of how to write a simple yet portable Makefile: Yet it forgets the MOST important thing: make uninstall. Nothing worse than software where I have to reverse engineer a makefile in order to uninstall!
- vog 10y agoI don't trust "make uninstall" anyway. Instead, I usually put self-compiled packages into separate directories, such as: make install INSTALL_PREFIX=/opt/lzfse or make install INSTALL_PREFIX=$HOME/.../lzfse Uninstalling is then as simple as: rm -r /opt/lzfse For convenience, I either add /opt/lzfse/bin to $PATH, or create a symlink from /opt/lzfse/bin/lzfse to /usr/bin/lzfse. More generally, I believe that uninstalling, upgrading and related operations are the task of a package manager, not a build script.
- michel-slm 10y agoI do that, and then use GNU Stow to manage the symlinks. That way I only need to add a single directory to PATH and to library paths
- technion 10y ago> I really appreciate the presence of a no-nonsense Makefile As expected whenever a project does this, there's already a PR from someone trying to change that.[0] [0] https://github.com/lzfse/lzfse/pull/15 https://github.com/lzfse/lzfse/pull/15