It sounds like we want the same behavior as hush3.git build.sh where you can do build.sh -j4 or any custom number of cores for compiling. I will work on this.
It sounds like we want the same behavior as hush3.git `build.sh` where you can do `build.sh -j4` or any custom number of cores for compiling. I will work on this.
On a system I tested this new code on, with 8 CPU threads, using build.sh -j9 was about 25% faster than the default of build.sh when doing a fresh compile after a make clean . The reason we don't see a larger speedup is because libsodium was already hardcoded to use 8 threads and compiling that dependency takes a lot of time.
If you only modify SDL code and then recompile with build.sh -jN there will be a larger speedup.
On a system I tested this new code on, with 8 CPU threads, using `build.sh -j9` was about 25% faster than the default of `build.sh` when doing a fresh compile after a `make clean` . The reason we don't see a larger speedup is because libsodium was already hardcoded to use 8 threads and compiling that dependency takes a lot of time.
If you only modify SDL code and then recompile with `build.sh -jN` there will be a larger speedup.
Change build.sh to enable building on more than 2 cores on Linux, as seen here https://git.hush.is/hush/SilentDragonLite/src/branch/master/build.sh#L8
It sounds like we want the same behavior as hush3.git
build.sh
where you can dobuild.sh -j4
or any custom number of cores for compiling. I will work on this.On a system I tested this new code on, with 8 CPU threads, using
build.sh -j9
was about 25% faster than the default ofbuild.sh
when doing a fresh compile after amake clean
. The reason we don't see a larger speedup is because libsodium was already hardcoded to use 8 threads and compiling that dependency takes a lot of time.If you only modify SDL code and then recompile with
build.sh -jN
there will be a larger speedup.Slightly related: Compiling libsodium on macs was hardcoded to 4 jobs which is now changed to 8, so compiling on macs will be faster now.