AFAIK, for avoids breaking change to existing applications that may not be ready for MT, if we want a Crystal application use maximum multi-core, we need added following source code manually.
or user must give a --threads options in linux, like this:
crystal build --threads $(nproc)
If I have misunderstood this part, please let me know.
My question is, is there a solution(can be used in Makefile), which can automatically use maximum core on current system, but no need change the source code, and not use the wired linux hack like $(nproc)?
Thanks
Alternatively, to rephrase the question: instead of “parallel context that defaults to a parallelism of 1”, is there an external command-line option for a “parallel context that defaults to a parallelism of Fiber::ExecutionContext.default_workers_count”?
There is currently no compile-time flag to change the default behaviour. Rescaling the default execution context to a parallelism > 1 is opt-in at the source code level.
This seems like the right place because it’s a property of the code whether (and what part of it) is capable of parallel execution.
You would also create an additional, parallel execution context in the source code.
What’s the use case for configuring that at compile time?
There is also a misconception in your question: crystal build --threads $(nproc) informs the parallelism of the compilation process. It has no effect on the produced executable.
The $CRYSTAL_WORKERS environment variable only works with the now deprecated legacy multi-threading model of -Dpreview_mt.
It’s not supported out-of-the box by execution contexts.
You can of course read that environment variable explicitly in you code.