New CLBlast 1.6.0 Release is 3x previous library size
LostRuins opened this issue · comments
Hi, I noticed that the new CLBlast 1.6.0 Windows 64 bit Release is 3x previous library size (5mb to 14.5mb), just wondering what was significantly changed that results in such a massive file size increase, and whether it's possible to keep the library smaller. Thanks!
That's a good question. The thing that changed is that the new release files are built using a new GitHub Actions script rather than the older AppVeyor script.
However, the AppVeyor script still exists and also still produces releases (on every run even), e.g.:
https://ci.appveyor.com/project/CNugteren/clblast/builds/47114621/artifacts (indeed, the library size here is 5.5MB)
For reference, here is the new GtitHub Actions release build log:
https://github.com/CNugteren/CLBlast/actions/runs/5049126014/jobs/9058176523 (indeed, here the library size is 15MB)
In both cases the compiler is MSVC 19, although the exact version is different (19.0.24241.7 versus 19.29.30148.0). Also the way the release build is configured is different: in the AppVeyor case this is at CMake makefile generation time, in the GitHub Actions case it is at compilation time.
Not sure what the cause would be. Anyone more familiar with Windows builds any ideas?
Also the assets of the Linux build grew from 990 KB for CLBlast-1.5.3-Linux-x64.tar.gz to 14.5MB for CLBlast-1.6.0-linux-x86_64.tar.gz
The main difference seems to be in the included binaries. In 1.5.3 only 10 sample applications were bundled, in 1.6.0 also 14 tuner applications are packaged. The Windows zip file from appveyor adds more client applications making it even larger.
Probably (didn't test) adding -DTUNERS=OFF in the GitHub action for both Linux and Windows would prevent the tuners from being build and packaged.
Well I am thankful to know it's just a CI/CD issue haha. I will use the AppVeyor build for now as file size is important for my use case. Thanks!
@gjvdbraak thanks for your input, but including the tuners in the release was intentional: this way it is easier for users to tune on their device, they won't have to compile from source. Note that the original issue is not so much about the .zip/tar.gz file, it is about the library itself, in particular the Windows .dll file.
In #481 I explicitly asked the GitHub Actions release to use NMake and made a test run here. And indeed, for whatever reason that resulted in the smaller release. I'll go ahead and merge that branch and (after another fix to the build) I'll update the Windows release.