0

Recently I'm trying to learn vulkan, and I found that although nearly every tutorial or book I found teaches vulkan with C++, the API style of it is more C than C++. Naturally, I looked for its official C++ API, and that raised my question:

Is there a significant performance gap bewteen native VulkanSDK and its C++ binding? Or more generally, is there a significant performance gap bewteen C library and its C++ binding?

Rabbid76
  • 202,892
  • 27
  • 131
  • 174
Gasai Maple
  • 18
  • 4
  • C++ is pretty complicate, especially on how things get named (read up on name mangling). C doesn't have those issues so it is a very popular language to implement your API with. – NathanOliver Oct 31 '22 at 15:50
  • 2
    "Significant" is not well defined. But anyway I believe that the overhead is quite minimal. Surely it is OK for leaning vulkan. – wohlstad Oct 31 '22 at 15:50
  • 2
    cross-site dupe: https://softwareengineering.stackexchange.com/questions/281882/why-does-c-provide-language-bindings-where-c-falls-short – NathanOliver Oct 31 '22 at 15:51
  • If it's just a binding and not an abstraction layer I'd be surprised if there was much of a difference in terms of performance. C++ can call into C without any overhead. – tadman Oct 31 '22 at 15:54
  • @NathanOliver: That's not the same thing at all. This is asking about overhead with using a C++ binding over C. That question is about why C APIs are used at all. – Nicol Bolas Oct 31 '22 at 15:55
  • 1
    The asker's question stems from the asker noting a far more C-like interface than they were expecting. The way I read the question, they've assumed it's because a performance issue, when the reality is it's more likely to get a wider spread without having to recompile the library for pretty much every C++ compiler and many versions of each compiler. – user4581301 Oct 31 '22 at 16:10
  • @user4581301: That's got nothing to do with it. It's more about extensibility and not having the C++ API work fundamentally differently from what the specification (written against C) says. – Nicol Bolas Oct 31 '22 at 16:12
  • Bindings are usually done by wrapping, i.e. calling the native functions inside wrapper functions, with minimal argument marshalling. In some cases, good optimizers might probably undo the wrapper call. In any case, the overhead is only noticeable for very short functions such as getters/setters. –  Oct 31 '22 at 16:16
  • _"... the API style of it is more C than C++..."_ - Vulkan is a `C` interface from the __Vulkan® 1.3.232 - A Specification__ _"...Shared library implementations must use the default Application Binary Interface (ABI) of the standard C compiler for the platform, or provide customized API headers that cause application code to use the implementation’s non-default ABI...."_ https://registry.khronos.org/vulkan/specs/1.3/html/chap3.html#fundamentals-abi There has to be an ABI interface that many languages can use and the `C` ABI is the generally accepted one. – Richard Critten Oct 31 '22 at 17:22
  • I'm sorry that my question caused some understanding problems. Let me expalin this: Vulkan is a C interface, but there is also a Vulkan-Hpp repository by KhronosGroup. Since Vulkan is low level and should care more about performance, why does Vulkan-Hpp exists, is that because the C++ abstraction layer does not(at least not significantly) affect performance? By "significantly", I mean 5% more. – Gasai Maple Nov 01 '22 at 07:49

2 Answers2

0

Generally it is not about the performance but more about design paradigms. CPP API is obviously an OOP wrapper, which may force you to follow some non-desirable patterns you do not want. But in case if library architecture has object oriented design by nature, it may be quite seamless wrapper.

azis.mrazish
  • 99
  • 7
-2

No

C and C++ compilers and linkers are both well optimized at this point of life.

Generally speaking - performance of code is the result of the whole programming process - from the initial design, to the programmer that codes, to the last step in the CI for deployment. So in general - are C bindings faster than C++? No.

About Vulkan - It's a low level library, the bindings themselves have no much difference.
The usage is very important since Vulkan is considered more "Low level" than OpenGL - this results in more control of the buffers and overall program flow.
Memory,IO, CPU, Graphics RAM are all controlled by the developer which is the main concern for performance.

Standard libraries are important

C header files and C++ STD may differ in implementation which is the biggest point to consider when choosing a language - What does the ecosystem provide you as a programmer?.
Since you'll probably need some vectors and matrix structures and a good math library for game development.
This may affect your choices.

Benchmark and metrices

Nothing is written in stone.
If you are concerned with performance first thing you'll need is to measure it.
And that's a great exercise you can do - Are C bindings faster than C++?
Just use a benchmark in your application and test it yourself!

Best of luck.

SimplyCode
  • 318
  • 2
  • 9
  • 2
    IMO, this answer has little to do with the question. –  Oct 31 '22 at 16:17
  • @MSalters Untrue. I answered directly the question "Are there significant gaps..." "NO". Secondly - STL isn't 25 years out of date. C++ had few major versions recently, 11,14,17,20 and soon 23. I may agree that it is far from perfect, but it is what it is. Also he asked about **performance** which I considered as my main focus in this answer. The subject itself is very complex so I tried to stay on point without confusing. – SimplyCode Oct 31 '22 at 16:23
  • 2
    @SimplyCode: Just to clarify: STL is the Standard Template Library by Stepanov & Lee, which became mostly obsolete by 1998 when C++ included the major components in the Standard Library. Recent additions to C++ mostly come from Boost, not from the STL (since there's nobody working on that anymore). – MSalters Oct 31 '22 at 16:28
  • @MSalters Fixed that mistake, thanks. – SimplyCode Oct 31 '22 at 16:29
  • 1
    I'm not sure STD is the right thing to call it, if only to avoid confusion with gonorrhea. As an acronym the Standard Library would simply be SL, but I recommend spelling it out in full to avoid confusion. – user4581301 Oct 31 '22 at 16:36
  • @user4581301 As a developer and someone that tends to help a lot - Let's not hang on to these small subtleties. My header consists of "Standard Libraries" and that's enough. Thanks. I tend to write Answers where everyone else afraid, if you have a better answer. Just write it to OP. – SimplyCode Oct 31 '22 at 16:42