Defining interfaces in C++ with ‘concepts’ (C++20)
1–10 of 77 posts
Re: Defining interfaces in C++ with ‘concepts’ (C++20)
#2> In Go, I found that using an interface was not free: it can make the code slower. In C++, if you implement the following type and call count on it, you find that optimizing compilers are able to just figure out that they need to return the size of the inner vector.
I'm surprised at this, do Go interfaces really introduce much overhead? Of course this depends on the level of performance you care about but surely, being a statically typed language, lots of the same optimisations are available.
Re: Defining interfaces in C++ with ‘concepts’ (C++20)
#3> In Go, I found that using an interface was not free: it can make the code slower. In C++, if you implement the following type and call count on it, you find that optimizing compilers are able to just figure out that they need to return the size of the inner vector. I'm surprised at this, do Go interfaces really introduce much overhead? Of course this depends on the level of performance you care about but surely, be…
[deleted]
Re: Defining interfaces in C++ with ‘concepts’ (C++20)
#4> In Go, I found that using an interface was not free: it can make the code slower. In C++, if you implement the following type and call count on it, you find that optimizing compilers are able to just figure out that they need to return the size of the inner vector. I'm surprised at this, do Go interfaces really introduce much overhead? Of course this depends on the level of performance you care about but surely, be…
Go generally is pretty conservative about that kind of thing (namely, compiler optimizations). Go generally abides by a “what you write is what you get” kind of thing, especially when it comes to “non-local” optimizations. It’s generally opposed to anything that’s “clever.” (Just my feeling as someone who uses Go pretty often and who respects the choice they’ve made on that spectrum).
Re: Defining interfaces in C++ with ‘concepts’ (C++20)
#5> In Go, I found that using an interface was not free: it can make the code slower. In C++, if you implement the following type and call count on it, you find that optimizing compilers are able to just figure out that they need to return the size of the inner vector. I'm surprised at this, do Go interfaces really introduce much overhead? Of course this depends on the level of performance you care about but surely, be…
Interfaces always go to the heap in go, so yes, you can take some simple code that could easily live on the stack and make it slower by wrapping it in interfaces with go.
Re: Defining interfaces in C++ with ‘concepts’ (C++20)
#6> In Go, I found that using an interface was not free: it can make the code slower. In C++, if you implement the following type and call count on it, you find that optimizing compilers are able to just figure out that they need to return the size of the inner vector. I'm surprised at this, do Go interfaces really introduce much overhead? Of course this depends on the level of performance you care about but surely, be…
Go generally is pretty conservative about that kind of thing (namely, compiler optimizations). Go generally abides by a “what you write is what you get” kind of thing, especially when it comes to “non-local” optimizations. It’s generally opposed to anything that’s “clever.” (Just my feeling as someone who uses Go pretty often and who respects the choice they’ve made on that spectrum).
[deleted]
Re: Defining interfaces in C++ with ‘concepts’ (C++20)
#7> In Go, I found that using an interface was not free: it can make the code slower. In C++, if you implement the following type and call count on it, you find that optimizing compilers are able to just figure out that they need to return the size of the inner vector. I'm surprised at this, do Go interfaces really introduce much overhead? Of course this depends on the level of performance you care about but surely, be…
Interface methods in Go are like virtual methods in C++. In principle C++ compilers when statically compiling everything can often remove virtual method indirection for some objects, but I think in general this optimization is still uncommon and difficult to coax out a compiler. Go definitely does not do this, even though in principle it should be easier.
Basically, "interfaces" in Go and C++ actually refer to quite different language features. (Or at least, the author is using the term to describe quite different language features.)
Re: Defining interfaces in C++ with ‘concepts’ (C++20)
#8> In Go, I found that using an interface was not free: it can make the code slower. In C++, if you implement the following type and call count on it, you find that optimizing compilers are able to just figure out that they need to return the size of the inner vector. I'm surprised at this, do Go interfaces really introduce much overhead? Of course this depends on the level of performance you care about but surely, be…
There is overhead in interface indirection because the Go runtime needs to perform dynamic dispatch to determine which method to call at runtime.
C++ can optimize interface indirection away because it supports static polymorphism, which allows the compiler to generate specialized code for each concrete type used with a generic interface, eliminating the need for dynamic dispatch.
Re: Defining interfaces in C++ with ‘concepts’ (C++20)
#9> In Go, I found that using an interface was not free: it can make the code slower. In C++, if you implement the following type and call count on it, you find that optimizing compilers are able to just figure out that they need to return the size of the inner vector. I'm surprised at this, do Go interfaces really introduce much overhead? Of course this depends on the level of performance you care about but surely, be…
Go generally is pretty conservative about that kind of thing (namely, compiler optimizations). Go generally abides by a “what you write is what you get” kind of thing, especially when it comes to “non-local” optimizations. It’s generally opposed to anything that’s “clever.” (Just my feeling as someone who uses Go pretty often and who respects the choice they’ve made on that spectrum).
it’s actually to keep compile times fast
and for the implementation of the compiler to remain simple
Re: Defining interfaces in C++ with ‘concepts’ (C++20)
#10Earlier quoted context omitted.
Go generally is pretty conservative about that kind of thing (namely, compiler optimizations). Go generally abides by a “what you write is what you get” kind of thing, especially when it comes to “non-local” optimizations. It’s generally opposed to anything that’s “clever.” (Just my feeling as someone who uses Go pretty often and who respects the choice they’ve made on that spectrum).
it’s actually to keep compile times fast and for the implementation of the compiler to remain simple
Yep, I think those things are all related.