Created attachment 219900 [details] wrk-aarch64-fix.patch lang/luajit-openresty builds on ARM64 and wrk, whn built with it, runs just fine. Attached patch switches the dependency to luajit-openresty for aarch64.
Hi Oleksandr, thanks for the report and the patch. In case it isn't break any functionality it's probably better to completely switch to lang/luajit-openresty.
Functionality-wise it's the same, I ran my lua scripts using both implementations. openresty version seems a bit slower on the same machine: my scenario pre-generates a bunch of random numbers (offsets) for every worker thread and it takes visibly longer for openresty version: ~5sec vs ~25sec. I'd consider it a regression on x86, but for arm64 functional (if a bit slow app) is better than no app. Just out of curiosity I tried to isolate the logic from the script in an isolated benchmark and both LuaJIT implementations showed the same result. So it's probably multi-threaded code that causes a slow-down.
Ping, status on this one?
(In reply to Daniel Engberg from comment #3) The status is good. My suggestion is to implement three FLAVORs of this port: - depends on lang/luajit - depends on lang/luajit-openresty - depends on lang/luajit-devel
Wouldn't it be easier to use a menu to select what lib you want to use? While it's out of scope for this PR I think we should decide of one flavour (most distros seems to use -openresty and it also has best compatibility between archs) to use instead of having to shuffle between three different libraries.
(In reply to Daniel Engberg from comment #5) A menu adds a value for interactive work, when FLAVORs help to generate packages based on different dependencies. In case of the patch - that can be done in one if statement, so an additional work is required.