Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider using final on derived (component) classes #3038

Open
Kronos3 opened this issue Nov 21, 2024 · 3 comments
Open

Consider using final on derived (component) classes #3038

Kronos3 opened this issue Nov 21, 2024 · 3 comments

Comments

@Kronos3
Copy link
Contributor

Kronos3 commented Nov 21, 2024

F´ Version
Affected Component

Feature Description

Add final to component implementations to allow compiler to remove one layer of indirection to port calls.

Rationale

When calling a virtual function, the compiler will add an operation that checks the vtable for an override above it's own implementation. We can use final to "devirtualize" the CPP implementations at compile time.

For our use case final is perfect for our derived component classes. At the moment we are passing a virtual function pointer (input port call) to connect output -> input ports. This means that there are two levels of indirection in a port call:

  1. Load the target input port call address (function pointer)
  2. Check the vtable for an override (which does not exist)

Read more about it here https://llvm.org/devmtg/2016-11/Slides/Padlewski-DevirtualizationInLLVM.pdf

@Kronos3 Kronos3 changed the title Consider using final derived (component) classes Consider using final on derived (component) classes Nov 21, 2024
@LeStarch
Copy link
Collaborator

This makes sense to me! Our components function as final classes anyway.

@LeStarch
Copy link
Collaborator

At one time, this would not have been desired behavior as there was a concept of using inheritance to make similar components that derived from a common interface. However, we have converged on the concept of using FPP style interfaces as the preferred method resulting in distinct components that share the same shape.

All this is to say, from a development perspective and an F Prime/FPP assumption perspective, this is likely preferred regardless of the value performance improvement. @timcanham @bocchino do you concur?

@celskeggs
Copy link
Contributor

celskeggs commented Nov 25, 2024

I'll also second this request, not just because of performance, but because it helps the C compiler detect missing port handlers sooner. If I compile just a single component, the build can succeed even if the component is missing a handler. (I won't hit an error until I construct an instance of the component in my topology.) If we include the final keyword by default, the missing handler will be caught very quickly when compiling the component.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants