Rework field code to avoid functions calls

[go2sh]

Hi all,

I really like your library and it helps us developing new apps very fast.

One problem I faced with it, especially on IFX tricore devices is, that every field get/set API is a function call. This adds a huge overhead:

• The instruction cache is poisoned
• Adds at least 4 additional cycles for the call it self
• Increases the code size, because most field getters/setter can be render into a single instruction if the data is loaded.

This could be fixed relatively easy by making all getters setters inline.

BR,
go2sh

[SebastianSchildt]

It makes sense, as the actual code that needs to be executed is small, so function call overhead is visible. I am just wondering, as the set/gets are really simple abstractions over the field setting Macros, I would have assumed the compiler might inline it in terms of optimization?
Did you check whether that has any effect, or is the issue that you build with -Os or some equivalent for code size and still want to force inlining?

I am wondering we should "just inline" and consider it an improvement for any user (like we did when we "const" more), or whether we still should hide it behind a #define, because it might have unintended consequences?

[go2sh]

Inlining doesn't necessarily depend on the inline keyword, but on the availability of the function body during compilation. Since the library has a strict header/source split, no inlining is possible.

Maybe LTO can do something here, but in general: the optimizations the front-end and back-end can do with inline functions are much greater than with LTO. (e.g. merge adjacent changes into one)

[adriaan-niess]

@go2sh thanks for the hint. We didn't do any performance optimizations yet, because so far the bottlenecks have been elsewhere. There are definitely a few things that can be improved. Coincidentally I wanted to start doing some "load tests" starting in the next 1-2 weeks using Infineon TriCore (also the reason why I contacted you). So a good reason for me to have a look at this.

Theoretically it would also be possible to transform the library (or parts of it) into a header-only library. But inlining the functions seems to be a low hanging fruit and does not break anything

[go2sh]

I was also creating some stress tests comparing tc3 and tc4. And I realized that the IPC was very low with the library code. For can Brief, i did a Prototype and i got a 20-30% IPC increase.

[nayakned]

Hi all,

I really like your library and it helps us developing new apps very fast.

One problem I faced with it, especially on IFX tricore devices is, that every field get/set API is a function call. This adds a huge overhead:

• The instruction cache is poisoned
• Adds at least 4 additional cycles for the call it self
• Increases the code size, because most field getters/setter can be render into a single instruction if the data is loaded.

This could be fixed relatively easy by making all getters setters inline.

BR, go2sh

@go2sh Thanks for your suggestions. As you already noted, Open1722 has a header/source split due to which we cant simply inline functions. We are thinking about moving the definitions of the getter/setter functions to the header file and inline it. The utility functions (Avtp_GetField()/Avtp_SetField()) invoked by the getter/setter functions will remain in the source files and be compiled into the shared library. This will hopefully help.

I am wondering though how the getters and setters are rendered into single instruction. In the current implementation, the Avtp_GetField()/Avtp_SetField() are rather large functions.

[go2sh]

With inline Avtp_GetField, the compiler looks through all code with a high optimization level and removes everything, that can be evaluated at compile time.
In the end, when a field is in the same quadlet only another "extract operation" is required, the rest is optimized away.

In general, the Avtp_GetField is very verbose. For most fields (except 64 bit), I would expect a load, (an optional shuffle aka be to le) and an extract instruction.