On Sun, Feb 16, 2003 at 12:28:57 +1100, Erik de Castro Lopo wrote: > As a C fan I was rather curious about this. I didn't want people getting the > wrong impression that C++ is automatically faster than C (it isn't) or that in > the long term improvements in the C++ compiler will make it faster than C > (it won't). So I asked Steve for more details and he pointed me at the code:
I was actually expecting c++ to be marginally faster, because it could understand that nature of the objects and might be able to do some optimisation around them - partial because the arangement in the code wasn't particularly realistic. > and suggested that further discussion of this issue should probably be moved > from the jackit-devel list to this one. So here we are. (Steve, please don't > take this as a slight on you, I simply want to get the facts right). Absolutely. The only reason I mentioned the results at all was that I had inspected the assembler outputs from the compilers I was testing on (2.95 and 2.96, the only commonly used compilers at the time), and knew it was reasonable. I didn't check it for 3.x. I was very keen to point out (and still am) that I dont think the code is representative of anything. I just wanted to be sure I wasn't missing any 5-10% efficiency gains by using OO-style C over C++. > I think that for applications like audio processing where speed is one of > the main goals benchmarking is extremely important. Personally I would > love to see more people do it properly and publish their results like I > did here: Agreed. If someone that knows c, c++ and objective c were to write up an audio focused benchmark that would be great. I've not realy used GObject, but I guess it should include that too. - Steve
