Created attachment 219900 [details]
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.
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.