Bug 251324 - benchmarks/wrk: Add support for ARM64
Summary: benchmarks/wrk: Add support for ARM64
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Sergey A. Osokin
Depends on:
Reported: 2020-11-23 07:24 UTC by Oleksandr Tymoshenko
Modified: 2022-08-09 19:35 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (osa)

wrk-aarch64-fix.patch (841 bytes, patch)
2020-11-23 07:24 UTC, Oleksandr Tymoshenko
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Oleksandr Tymoshenko freebsd_committer freebsd_triage 2020-11-23 07:24:34 UTC
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.
Comment 1 Sergey A. Osokin freebsd_committer 2020-11-23 16:28:25 UTC
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.
Comment 2 Oleksandr Tymoshenko freebsd_committer freebsd_triage 2020-12-04 21:20:04 UTC
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.
Comment 3 Daniel Engberg freebsd_committer 2022-08-09 07:28:38 UTC
Ping, status on this one?
Comment 4 Sergey A. Osokin freebsd_committer 2022-08-09 14:09:27 UTC
(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
Comment 5 Daniel Engberg freebsd_committer 2022-08-09 16:10:48 UTC
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.
Comment 6 Sergey A. Osokin freebsd_committer 2022-08-09 19:35:36 UTC
(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.