c++ love it or hate it?

personalty, i love c++ whats your opinion on it?

My biggest complaint is the performance of your average C++ Standard Library implementation. Most implementations are fucking garbage, where it seems like the main goal of the implementer is obfuscation rather than performance.

I've been writing my own containers. Here's some micro benchmarks against the MSVC++ 2010 Standard Library. Not currently on a Linux machine, but I've benchmarked it there and the GCC libstdc++ containers are even worse in performance than the MSVC++ ones. My containers are in the prog namespace and have the EXACT same interfaces--they're drop in replacements.

You'll notice up to factors of 10 and beyond in performance improvements with my containers (lower times are better). I've tried submitting patches to the GCC maintainers, but they won't accept them because it's too much code to look at and they don't want to risk breaking ABIs.

So instead, I've been submitting patches to Clang/LLVM's libc++ implementation and they're getting accepted. Fuck GCC.


Sequence Containers
----------------------------------------------------
  push_back_int... SUCCESS
    prog::deque : 0.000905s [9.048058E-001s / 1000]
    std::deque : 0.003104s [3.104420E+000s / 1000]
    prog::list : 0.007332s [7.332047E+000s / 1000]
    std::list : 0.009298s [9.297660E+000s / 1000]
    prog::vector : 0.000640s [6.396041E-001s / 1000]
    std::vector : 0.000686s [6.864044E-001s / 1000]
  push_back_string... SUCCESS
    prog::deque : 0.001903s [1.903212E+000s / 1000]
    std::deque : 0.003978s [3.978026E+000s / 1000]
    prog::list : 0.008174s [8.174452E+000s / 1000]
    std::list : 0.009828s [9.828063E+000s / 1000]
    prog::vector : 0.002496s [2.496016E+000s / 1000]
    std::vector : 0.002730s [2.730018E+000s / 1000]
  assign_int... SUCCESS
    prog::deque : 0.000187s [1.872012E-001s / 1000]
    std::deque : 0.003307s [3.307221E+000s / 1000]
    prog::list : 0.007285s [7.285247E+000s / 1000]
    std::list : 0.009017s [9.016858E+000s / 1000]
    prog::vector : 0.000031s [3.120020E-002s / 1000]
    std::vector : 0.000031s [3.120020E-002s / 1000]
  assign_string... SUCCESS
    prog::deque : 0.001732s [1.731611E+000s / 1000]
    std::deque : 0.004399s [4.399228E+000s / 1000]
    prog::list : 0.007972s [7.971651E+000s / 1000]
    std::list : 0.010218s [1.021807E+001s / 1000]
    prog::vector : 0.001591s [1.591210E+000s / 1000]
    std::vector : 0.001685s [1.684811E+000s / 1000]
  insert_int... SUCCESS
    prog::deque : 0.000156s [1.560010E-002s / 100]
    std::deque : 0.000624s [6.240040E-002s / 100]
    prog::list : 0.000624s [6.240040E-002s / 100]
    std::list : 0.000936s [9.360060E-002s / 100]
    prog::vector : 0.019500s [1.950013E+000s / 100]
    std::vector : 0.124177s [1.241768E+001s / 100]
  insert_string... SUCCESS
    prog::deque : 0.000312s [3.120020E-002s / 100]
    std::deque : 0.000624s [6.240040E-002s / 100]
    prog::list : 0.000780s [7.800050E-002s / 100]
    std::list : 0.000936s [9.360060E-002s / 100]
    prog::vector : 0.068952s [6.895244E+000s / 100]
    std::vector : 0.716825s [7.168246E+001s / 100]
  insert_multiple_int... SUCCESS
    prog::deque : 0.000312s [3.120020E-001s / 1000]
    std::deque : 0.003307s [3.307221E+000s / 1000]
    prog::list : 0.007176s [7.176046E+000s / 1000]
    std::list : 0.009110s [9.110458E+000s / 1000]
    prog::vector : 0.025038s [2.503816E+001s / 1000]
    std::vector : 0.153084s [1.530838E+002s / 1000]
  insert_multiple_string... SUCCESS
    prog::deque : 0.001934s [1.934412E+000s / 1000]
    std::deque : 0.004602s [4.602030E+000s / 1000]
    prog::list : 0.008221s [8.221253E+000s / 1000]
    std::list : 0.010608s [1.060807E+001s / 1000]
    prog::vector : 0.071916s [7.191646E+001s / 1000]
    std::vector : 0.155954s [1.559542E+002s / 1000]

>>38
Well, my point is that the standard library doesn't have to have shit performance. The performance isn't handicapped because of the design of the library facilities, but rather due to the skill of the implementor.

My containers, if used correctly, will at least meet the performance of equivalent hand-written C code, and will also often beet out naive hand-written variants that don't take advantage of hardware-specific instructions.