7 ms·
One downside of the brute-force approach not mentioned is there's a pretty heavy penalty paid for dynamic_cast. You're going to be bringing in RTTI which for a
by vvanders 11y ago
One downside of the brute-force approach not mentioned is there's a pretty heavy penalty paid for dynamic_cast. You're going to be bringing in RTTI which for a lot of C++ domains can be a non-starter.
- jcoffland 11y agoIt used to be common for RTTI to require jumping through extra hoops (i.e. adding compiler options) but it's supported by default by most C++ compilers these days.
- chubot 11y agoThe problem isn't build time "cost" though; it's runtime cost.
- santaclaus 11y agoAnd binary size, if that is something you have to worry about.
- eliben 11y agoTrue. Alexandrescu touches upon this in his Modern C++ take on multimethods. He uses static per class integers to uniquely identify them instead of RTTI. This is not unlike the special home-cooked "RTTI" LLVM uses (http://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html http://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html) to avoid the large cost of typeid and dynamic_cast, so that it can be built with -fno-rtti but still provide runtime identification for types. Naturally, these approaches require intrusion (special field/static member in each class)
- twoodfin 11y agoGeneralized multimethods are an inherently costly abstraction. This paper[1] provides a good survey of the state-of-the-art—at least as of 20 years ago—in the context of Dylan. I'll have to re-read that section of Modern C++ to recall the runtime algorithm, but I'd be interested on any pointers to newer research or engineering on dispatch techniques. It's too bad that (AFAIK) no 'mainstream' high performance language has a multiple dispatch abstraction that could motivate more work. [1] http://www.eecs.berkeley.edu/~jrb/Projects/pd.pdf http://www.eecs.berkeley.edu/~jrb/Projects/pd.pdf
- eliben 11y agoStroustrup's paper (mentioned in the article) about implementing this in C++ is pretty comprehensive and deals with performance as well.
- gugagore 11y agoWhat about Julia? http://docs.julialang.org/en/release-0.4/manual/methods/ http://docs.julialang.org/en/release-0.4/manual/methods/
- deleted 11y ago[deleted]
- SolarNet 11y agoJulia does it right, but then also cheats. It uses high performance multi-methods, partially because it's a lisp and common lisp has been optimizing multi-methods for decades now. But also because Julia has a built in JIT with a very powerful type analyzer. Which means that while every function in Julia is a multi-method, you almost never pay the costs when writing high performance code. The cheating comes from the run-time compilation features being leveraged to inspect "already compiled" code and dodge around the dispatch. However this causes problems in larger systems (Julia has some serious shortcomings when it comes to large projects, and they ban people who talk about it too much) because if you add a method to the multiple dispatch already compiled functions won't make use of it without recompiling them too, this is basically the expression problem being displayed in a dynamic language (because they choose speed over true dynamicism; they leverage the dynamic features for a different purpose and loose the feature typically gained). This is a very bad form of cheating because multi-methods are often seen as a solution to the expression problem, but Julia still has the problem even though they use multi-methods. Try the following: # Library abstract bar ex(x) = println("dynamic") ex(x::bar) = println("bar") test(x::bar) = ex(x) type foo <: bar x :: Int end test(foo(5)) # Now our code ex(x::foo) = println("foo") test(foo(5)) It should print `bar\nfoo` it doesn't.
- deleted 11y ago[deleted]