对在aarch64 Linux环境编译安装的CinderX补充测试

前文最后说CinderX报错不能用这不对我在其github存储库上提了这个issuealexmalyshev回复I think that’s actually just a warning that you’re getting but things should be working after that?Right, this is just a logged warning that CinderX tried to enable huge pages but wasn’t able to. It falls back to using normal pages.我认为那实际上只是一个警告在那之后一切应该仍能正常运行是的这只是一个记录在案的警告表示 CinderX 尝试启用大页但未能成功因此它会回退到使用普通页面。下面是测试结果nbskylin-pc:~/par$ sudo docker start gcc142 输入密码 gcc142 nbskylin-pc:~/par$ sudo docker exec -it gcc142 bash rootkylin-pc:/# cd /par/uv314 rootkylin-pc:/par/uv314# source .venv/bin/activate cinderx.jit.compile_after_n_calls(1) (uv314) rootkylin-pc:/par/uv314# time python ../pe932e.py JIT: /par/cinderx-2026.3.30.0/cinderx/Jit/code_allocator.cpp:62 -- Failed to madvise [0x7fa1ffc000, 0x7fa21fc000) with MADV_HUGEPAGE, errno22 T(16) 72673459417881349.time18.62825632095337 T(16) 72673459417881349.time9.188195705413818 real 0m27.987s user 0m27.694s sys 0m0.047s -- cinderx.jit.compile_after_n_calls(0) (uv314) rootkylin-pc:/par/uv314# time python ../pe932e.py JIT: /par/cinderx-2026.3.30.0/cinderx/Jit/code_allocator.cpp:62 -- Failed to madvise [0x7fa0cdc000, 0x7fa0edc000) with MADV_HUGEPAGE, errno22 T(16) 72673459417881349.time11.874915599822998 T(16) 72673459417881349.time12.66346549987793 real 0m24.587s user 0m24.465s sys 0m0.012s可见不管是cinderx.jit.compile_after_n_calls(1)还是cinderx.jit.compile_after_n_calls(0)JIT后都比原始版本提速了。关于这个问题我也发issue提问了。alexmalyshev回复There could be a number of reasons for this, but most likely it’s because letting functions run through the interpreter once allows the CPython adaptive interpreter to emit specialized opcodes (e.g. BINARY_OP_ADD_INT instead of BINARY_OP) and CinderX can make use of that to generate faster code. Feel free to run with PYTHONJITDUMPFINALHIR1 in your environment to compare CinderX’s internal representation for each function between the two runs.In general we don’t recommend compile_after_n_calls(0) for general usage as it’s not meant to be performant. It’s primarily helpful to test CinderX compatibility for your code.出现这种情况可能有多种原因但最有可能的是让函数通过解释器运行一次能使 CPython 的自适应解释器发出特化的操作码例如BINARY_OP_ADD_INT而非BINARY_OP而 CinderX 可以利用这一点来生成更快的代码。你可以在环境中设置PYTHONJITDUMPFINALHIR1来比较两次运行之间 CinderX 对每个函数的内部表示差异。一般来说我们不建议在日常使用中设置compile_after_n_calls(0)因为这样做的目的并不是为了追求性能。它主要用于帮助你测试代码与 CinderX 的兼容性。我也用他建议的PYTHONJITDUMPFINALHIR1参数测试了确实两者输出的内部表示差别很大。compile_after_n_calls(0)的输出非常冗长不像认真优化过的。还有两个方法cinderx.jit.force_compile(fun)和cinderx.jit.lazy_compile(fun), 分别是立即编译和延迟编译它们俩的效果没太大区别都和compile_after_n_calls(1)的加速比一致。(uv314) rootkylin-pc:/par/uv314# time python ../pe932d.py N2499500025000000, a24995000, b25000000, k8, s49995000 T(16) 72673459417881349,time14.928523063659668 real 0m14.948s user 0m14.871s sys 0m0.004s (uv314) rootkylin-pc:/par/uv314# (uv314) rootkylin-pc:/par/uv314# time python ../pe932e.py JIT: /par/cinderx-2026.3.30.0/cinderx/Jit/code_allocator.cpp:62 -- Failed to madvise [0x7fbbb7c000, 0x7fbbd7c000) with MADV_HUGEPAGE, errno22 T(16) 72673459417881349.time14.70127558708191 cinderx.jit.force_compile(solve_T16) T(16) 72673459417881349.time8.867673873901367 real 0m23.639s user 0m23.529s sys 0m0.012s (uv314) rootkylin-pc:/par/uv314# time python ../pe932e.py JIT: /par/cinderx-2026.3.30.0/cinderx/Jit/code_allocator.cpp:62 -- Failed to madvise [0x7fa909c000, 0x7fa929c000) with MADV_HUGEPAGE, errno22 T(16) 72673459417881349.time14.878132820129395 cinderx.jit.lazy_compile(solve_T16) T(16) 72673459417881349.time9.286654710769653 real 0m24.211s user 0m24.080s sys 0m0.024s