|
@javierguerragiraldez Cool. I am in favor of this API style since your benchmarking campaign and I like the idea of using it pervasively. I wonder whether it is better to do this piecemeal or in a "big bang" that defines a coherent API? I started that in #465 (Create a re: performance implications we really need a performance regression test suite that can quantify these matters so that we don't have to make guesses in pull requests. That is actually the idea behind the |
|
Pondering this very interesting topic a bit more... Overall I feel like it would be great to revise our core API and make it very efficient. Doing this well seems to require a fairly deep understanding of the limits of LuaJIT and the CPU. I am working on this in the background via my blogging, writing apps in assembler by hand (#603), improving the profiler to be able to compare our JIT'd code with the hand-written code (#611), and thinking about a unified facade for the API (#465). I hope the result of these explorations will be a simple API that is hard to misuse and also some practical optimization and profiling tips to make it easy to get good and predictable performance. There are a few specific issues that I want to address in the API:
This is all probably quite simple once you have a strong enough mental model of LuaJIT but I feel like I am only around half of the way there. Meanwhile it is hard to evaluate changes like this PR. On the one hand it makes sense to merge code quickly if it is really having a measurable impact on a benchmark that we care about e.g. NFV packet forwarding. Is that the case? If so it would be interesting to know. On the other hand I am cautious about merging piecemeal changes to the core API. Should everybody switch to the new syntax? Should all existing code be changed? Are we going to change this again in a short while when we understand LuaJIT better? These questions would all be easier to answer with a unified API update that comprehensively solves all the known problems of the existing API, rather than with individual extensions like adding a second way to call functions on packets and links. Does this make sense? Perhaps we need an Issue to start tracking the requirements for an updated API. I think that a bunch of us are making parallel investigations of LuaJIT behavior and coming up with theories of how the API and programming style should be adapted for better performance. |
|
I don't think that The trouble with the piecemeal approach is that in the short term it means more code, less consistency, and no more functionality. Could be that we need a |
Many moons ago it was shown that OOP-style
ffi.metatype()methods are just as fast as locally caching module functions likelocal l_empty = link.emptywithout the extra red tape and less risk of sub-par performance just because of wrongly guessing the impact of any given function.This PR includes the methods for packet and link structs, and converts the
basic_appsandkeyed_ipv6_tunnelas examples.