5 ms·

I would have to find the exact example, but I tried counting words etc. Specifically, using the new built in abstractions is slower than not using the abstracti

by lqdc13 11y ago

I would have to find the exact example, but I tried counting words etc. Specifically, using the new built in abstractions is slower than not using the abstractions. For example, unordered_map was pretty slow. I just checked again though and it is much faster for counting words because they fixed a bug: http://www.mail-archive.com/gcc-bugs@gcc.gnu.org/msg368041.html http://www.mail-archive.com/gcc-bugs@gcc.gnu.org/msg368041.h... Edit: I know that example is a C++11 feature, but basically the idea is that you have to try things with different inputs before making conclusions.

pjmlp 11y ago
That has nothing to do with C++14. It was an gcc bug. Remember that languages based on standards are not defined by what a specific compiler does.
- lqdc13 11y ago
  So let's pretend we have a language ABC that is based on standards. It has one implementation and one standard library and the code can only be compiled with one compiler. If the standard library's string functions are slow, can you not say that the language is not very fast at string manipulations? I am pretty sure most people would say that.
  - pjmlp 11y ago
    >If the standard library's string functions are slow, can you not say that the language is not very fast at string manipulations? No, because it might still be an implementation issue. One needs to understand why the string functions are slow, what is causing it. Is the language semantic, the algorithm being used, the internal data representation,...? > I am pretty sure most people would say that. The ones without background in compiler design, surely yes. Also the point of standards is exactly to avoid compiler driven development and foster competition between implementations thus leading to a better language eco-system.
danieldk 11y ago
Thanks for the example. I was thinking of language features, which are mostly cheap (type inference, move constructors, constexpr, initializer lists, range-based for loops). But it may indeed be that some standard library extensions are not well-optimized yet.

by lqdc13 11y ago

pjmlp 11y ago

That has nothing to do with C++14. It was an gcc bug. Remember that languages based on standards are not defined by what a specific compiler does.

lqdc13 11y ago
So let's pretend we have a language ABC that is based on standards. It has one implementation and one standard library and the code can only be compiled with one compiler. If the standard library's string functions are slow, can you not say that the language is not very fast at string manipulations? I am pretty sure most people would say that.
- pjmlp 11y ago
  >If the standard library's string functions are slow, can you not say that the language is not very fast at string manipulations? No, because it might still be an implementation issue. One needs to understand why the string functions are slow, what is causing it. Is the language semantic, the algorithm being used, the internal data representation,...? > I am pretty sure most people would say that. The ones without background in compiler design, surely yes. Also the point of standards is exactly to avoid compiler driven development and foster competition between implementations thus leading to a better language eco-system.

danieldk 11y ago

Thanks for the example. I was thinking of language features, which are mostly cheap (type inference, move constructors, constexpr, initializer lists, range-based for loops). But it may indeed be that some standard library extensions are not well-optimized yet.