BTW, this explains why the DD overhead is observed at EACH level of "Call Parent method".
No, it doesn't. The overheads are different between the CPN and a regular DD node. They may benchmark as similar performance hits, but they are different issues.
@Intaris wrote: Why would it be such a massive change? Just because we don't allow dynamic loading of classes? Have I misunderstood how FPGA handles this? It boils down to knowing "This is the exact set of classes which will be active in this hierarchy, no more, no less" when compiling so that type-checking could be done at compile-time as opposed to at run-time.
Isn't this similar to "finalizing" a hierarchy? or "sealing" or whatever any given language calls it.
No. Sealing a class or method is something we could add to the language. We still wouldn't be anywhere near the performance of FPGA that we would get from whole-hierarchy compilation.
When you seal a given override, it means no more overrides below this point. So if you have on your diagram a direct call to that method -- i.e. the wire is of the child class type and it is wired to the method call -- then we could eliminate all the DD overhead. But you would still have overhead when you call into a parent class method that has a nested DD call even though we know where that call will go and even if everywhere in your whole application the function is only ever called with your child class. In FPGA, we can eliminate all the DD overhead everywhere completely (indeed, we're broken if we can't eliminate it entirely). Whole hierarchy compilation on RT and Desktop would let us eliminate in many many more places than just sealing a class or method would, bringing us much closer to FPGA.
Debugging FPGA is easy! You write your code, deploy it. If it doesn't work as expected, delete it and write it again from scratch. Eventually, you'll get it right! The process is long, but it isn't *hard*! 🙂
As I heard it, it isn't a linear quantity... it varies based on call site and conditions, so there's no way to pin a percentage on it. I didn't work on it myself.
As I heard it, it isn't a linear quantity... it varies based on call site and conditions, so there's no way to pin a percentage on it. I didn't work on it myself.
Oh, I see, I just had another flash of enlightenment.
