Re:Java is better than C++ for high speed trading systems
by masklinn on Thursday November 26, 2020 @07:20AM
(#25219326)
What do you mean by “virtual object”, an object which has been broken up on the stack instead of a “real” object living as a single entity on the heap?
[ Parent
| on HN ]
Re:Java is better than C++ for high speed trading systems
by chrisseaton on Thursday November 26, 2020 @09:10AM
(#25220137)
> What do you mean by “virtual object”, an object which has been broken up on the stack instead of a “real” object living as a single entity on the heap?
Yes... but let's not say 'broken up on the stack' - the object's fields become dataflow edges. The object doesn't exist reifed on the stack - fields may exist on the stack, or in registers, or not at all.
Re:Java is better than C++ for high speed trading systems
by aweinstock on Thursday November 26, 2020 @12:58PM
(#25222173)
LLVM calls the process of breaking a struct/object into dataflow variables "Scalar Replacement of Aggregates".
Re:Java is better than C++ for high speed trading systems
by chrisseaton on Thursday November 26, 2020 @01:12PM
(#25222273)
Yes that's what the JVM calls it - and then the node the ties together the state is the virtual object.
Re:Java is better than C++ for high speed trading systems
by bluGill on Thursday November 26, 2020 @08:35AM
(#25219875)
Remember back in cs101 where you had class animal, with subclasses dog and cat. You can call speak() on animal and get either ruff or meow depending on what animal is. Animal is a virtual object. The system needs to do some work to figure out which speak to call every time, the work isn't too bad, but it turns out that cpus basically never have the right thing in the cache, so it ends up being very slow compared to most of what you are doing.
When we say devirtualize we mean that we know animal is always a cat so we don't have to look up which speak to use.
Re:Java is better than C++ for high speed trading systems
by masklinn on Thursday November 26, 2020 @12:07PM
(#25221742)
Please don't take others for complete morons.
And that makes literally no sense in-context, you're mapping those words directly to the concept of virtual methods but that's the opposite of the way chrisseaton uses them (and they're clearly familiar with the concept of virtual calls and it's not what they're using "virtual" for), hence asking them what they mean specifically by this terminology.