Disable parallel build by default #567
Conversation
|
Let's also add something to the build instructions in the guide. |
Disable the parallel build unless explicitly enabled, as it confuses some newbies to no end as the compilation semi-deterministically dies out of lack of memory as gerbil tries to spawn too many gcc's. In the future, somehow find a good estimate of how many processes to spawn, or better, learn to dynamically measure and calibrate.
| ;; Except we need to compute (available-memory) and calibrate (memory-per-compilation-cpu)... | ||
| ;; Until then, we disable the parallel build as it confuses a lot of beginners. | ||
| (cond | ||
| ((real? cpu-count-spec) cpu-count-spec) |
There was a problem hiding this comment.
probably fixnum? or integer? is a better test.
There was a problem hiding this comment.
All I do with the object is decrement and compare to zero, so as long as it's an archimedean ring... and actually, I suppose +inf.0 means no limit (or any real number greater than 2e53).
There was a problem hiding this comment.
> (integer? 2e53)
#t
> (= (+ 1 2e53) 2e53)
#t
Or do you mean exact-integer? ? But why prevent no limit?
There was a problem hiding this comment.
uhm, it would probably be a bad idea -- do we want to spawn a 1000 gccs?
There was a problem hiding this comment.
So 2**53-1 as a fixnum is A-OK, but 2**53-1 as a float isn't? Not that either will make much of a difference, unless you have that many processes.
There was a problem hiding this comment.
yeah well, I guess if the user wants to be silly and lock up their machine, it's up to them.
There was a problem hiding this comment.
feel free to merge, this is not blocking :)
Disable the parallel build unless explicitly enabled, as it confuses some
newbies to no end as the compilation semi-deterministically dies out of
lack of memory as gerbil tries to spawn too many gcc's. In the future,
somehow find a good estimate of how many processes to spawn, or better,
learn to dynamically measure and calibrate.