Quote:Original post by Codeka
Are you telling me you don't use a profiler when doing performance analysis? If not a profiler then what? How do you know "Implementation A" is faster or slower than "Implementation B" if you don't profile?

It depends where one is standing. It is also the crux of this "Foo is slow". Also the basis for engineering, and the reason why Linux will not become desktop OS and why Twitter made it big and all other absurdities that seem to permeate the computing world.

It is not code that matters, and it is not code that is slow.

Slowness is in the domain of users - they tell you something is slow. Profiler lets you pinpoint down certain limited causes as to why it is slow.

This is why vector is good enough most of the time. Since development time is limited, after solving all the other causes, the application will, at some point, become fast enough.

A common fallacy of benchmarking is benchmarking in isolation.

Here's a more practical example, I deal in visualizations from time to time. And there was this graph handling tool. I used all the best practices, memory layouts, algorithms, etc, until it was able to handle 100,000 nodes in real time. As Borat would say "Great Success!".

Except it wasn't. The biggest graph that any user would ever load would be no more than 500 nodes. Which could be handled by a linked list of nodes using an n^2 algorithm.

I made the wrong assumption about what "fast" means. And second fallacy: "future-proof". Sure, my version is "future-proof". Except that future versions which actually do handle large graphs of hundreds of millions of nodes run on cluster of CUDA machines.

This is just one example of why constant factor optimizations are dangerous. Sure, 200% percent may sound a lot, but unless it is achievable with minimal effort, there's likely a million% improvement in using a different approach altogether.

Especially with multi-core being old news, TBB and similar tools abundant, it has gotten almost impossible to allocate any budget into constant overhead.

Instead, improving development practices by automating performance tests and either accurately getting user expectations, as well as accurate budget estimates will go much further, even if at smaller increments.

So I agree with that - profiler, while indispensable tool - is not where one should focus attention. Users are, for any arbitrary definition of user. They tell you which profiler to use, and where to point it.

Quote:Original post by thatguyfromthething
Profiler is another misconception, it's like saying you need a debugger to figure out bugs. It's just raw data, it catches things that amount to mistakes but it really tells you very little. Like the debugger, it is easy to misuse as a crutch that negates actual thought - it's not there to debug logic, but to catch simple mistakes and that's it.

Well, there's a big difference. When you're debugging you already know you have a bug and the general area based on what isn't working. When you're profiling, you're often looking for that initial glimpse into where your bottlenecks are, because frankly, even though you may think you have an idea, oftentimes, you won't really know until you profile.

Can tools be too heavily relied upon? Of course. But, the fact is that your avoidance of using these tools is part of the reason why you may feel like you do. If you think a debugger and a profiler are two tools that tell you very little, I don't know what to say, other than I couldn't disagree more. I can't foresee creating a large software project without both in my arsenal, and that is with some very good software engineering practices to surround it.

Quote:Original post by thatguyfromthething
Most programs don't need to worry a lot about code size or performance, but most programs don't need to be written in C++. It's easy to get gigabytes of object files in C++, though.

Well, it's simply about picking the best tool for the job. If the only thing C++ had going for it is performance, I don't think it would consistently be one of the top three or four most widely used programming languages. It's hard to fathom that 10% of all applications are truly performance critical.

Quote:Original post by thatguyfromthething
The point of macros is metaprogramming, too. Templates were introduced as a replacement, because they work ok for little stuff but they are hard to deal with when making something large. I don't say anyone who uses macros is incompetent, but a template library programmed almost entirely in macros is pretty ironic and shows that it's probably not someone who should be listened to much. But, free has a big appeal.

A template library programmed almost entirely in macros? Well, I don't agree with that statement at all. That's a grandiose exaggeration.

Quote:Original post by thatguyfromthething
Yes, other languages did learn from C++ mistakes. That's why they don't use C++ templates at all, but what does that have to do with anything? My point is not to bash on anybody, just to point out reality. The fact C++ has been left in the dust should say a lot about many of C++'s features.

Actually, other languages started out with no templates, then people were writing a lot of type-unsafe and dangerous code, so it revealed the need for generics. These languages later added support for generics and were often limited by their earlier choices. Most languages don't have a template or generic mechanism as powerful as C++ templates, but that often has to do with the history of those programming languages.

Anyway, you were saying STL is horrible; I was just curious what you were comparing it to that you might like better.

Quote:Original post by thatguyfromthething
I know templates are not OO, I'm the one who said it. Most people who talk about stl, design patterns, and OOP in C++ are pretty vague on what OOP is and how templates work. Or more likely, simply dead wrong. But, it's unsurprising because the way templates and C++ in general work is beyond mindboggling if you really look at it in detail.

Well, I think beyond mindboggling is a bit of an overstatement. Template meta-programming can be ugly. The true power wasn't really envisioned when C++ templates were designed and it has evolved through creative exploit after exploit into a very powerful, but somewhat confusing paradigm. That being said, there is an effort to simplify it with C++ concepts, though we're years away from getting that.

Quote:Original post by thatguyfromthething
People drop to c array because of performance, not size. I said nothing about resizing. You can also preallocate a vector, but that's not the real issue.

If you're saying a vector is still slower even after preallocating, I'll have to disagree. Memory allocations aside, an STL vector tends to operate as fast or faster, especially when looping, due to locality of reference.

Quote:Original post by thatguyfromthething
Sure you can trace through anything, but good luck with that using stlport or dinkumware, or probably any other big template library. But more important, what assembly gets generated? The point is not to look for mistakes but to find out why things slow down. This is possible but much harder with templates, almost impossible when you have complicated things going on (which almost anything in the stl qualifies as).

I don't see why the assembly generated classifies as "more importantly". But if you need to know, you can certainly see the generated assembly. There is nothing preventing you from looking at it. As for complexity, I find the complexity of my application itself is much more critical than the complexity of the STL.

Quote:Original post by thatguyfromthething
Who said I microoptimized anything? How would ten years passing have changed how stl works? Most of stlport was written 15+ years ago and has not changed a whit as far as I can tell in that time, whereas what qualifies as optimal code today has changed dramatically because hardware has changed dramatically. Sure computers can perform most tasks faster than ever, but again it comes to why are you using C++ if you don't care about performance? For some things you basically get paid in direct proportion to how much of x you can do, or even in exponential proportion. If Modo could handle 20 billion poly models would they be languishing in obscurity while zbrush has a dozen times the customers? Modo is certainly easier to use and it has all the same basic features, but bottom line is it's useless for most of what zbrush does so well simply due to not having the raw firepower.

Well, for one thing, many STL implementations were non-standard. In fact, the standard that we're referring to was C++98. Before that, the STL wasn't even exception-safe. I can't speak for STLport 15 years ago, because I've only needed STLport on two separate occasions, when there were performance reasons, because the STLport implementation was more performant. However, I'm quite confident that STLport has changed quite a bit in 15 years.

More to the point, Microsoft did not actually have a standards-compliant version of the STL until Visual Studio .Net 2003, IIRC. The VS6 one was terrible, buggy and leaky. This is why programmers with a heavy background in Windows tended to stick to MFC or ATL collections, rather than STL.

However, it's been a long time past, these issues are no longer true. Then, factor in that compilers have, in the past 5-7 years made tremendous leaps. Visual Studio 2008 optimizes considerably better than VS6 ever did. The inline keyword or lack there of is taken merely as a suggestion to modern compilers, where on many older compilers, it was blindly followed, even when it degraded performance. There's a lot that changed.

I still have vague memories of leaky strstream implementations, of old GCC environments where STL didn't work quite right, of a 1996 implementation of STL on an old version of VxWorks, where half the methods of vector weren't implemented, because it was pre-standard. Yes, these times existed. They are long past.

Quote:Original post by thatguyfromthething
How does stl solve almost anything?

I never said the STL solves almost anything. Your comment was "STL is a joke".

Quote:Original post by thatguyfromthething
This came up as a discussion about data structures, if you remember. You (and I) are only talking about vectors because that's about all there is worth noting in stl.

Not at all. We're talking about vectors because you brought up vectors. I'd be happy to apply any of the discussion to list, set, multiset, map, multimap, unordered_set, unordered_map, etc...

Quote:Original post by thatguyfromthething
If that's all you need for data structures, you probably are mistaken to use C++ at all.

If you read my earlier post, you'll notice I also mentioned using Boost and other third party libraries. If you need a list, I'll give you a list.

Quote:Original post by thatguyfromthething
I'd almost say the entire reason to use C++ at all compared to say Java is to be able to make specialized APIs. Of course if there is some API you need that's only in C++ then you are stuck with C++, but the real point is so that the people writing the API can have performance and flexibility and in turn use other low level APIs. Say you want to make something akin to Oracle or a game engine. Do you really think STL will cover your data structure needs? Well, it won't even scratch the surface. However if you are just some guy who uses Oracle or a game engine's built in stuff and make GUIs on top of it, by all means don't worry about data structures they use at all, because it's out of your hands anyway. If that's the case, drop C++ completely if you can and use C# or mono or python or Java to call on their API to do the actual work. But you can be pretty sure that somewhere in those programs there's a lot of work that went into various data structures.

Again, you're writing things that I never said. STL is far from covering all my data structure needs. But it's powerful and flexible enough to build new data structures ontop. STL absolutely isn't perfect (especially with the design of allocators), but it's definitely better than you've given it credit for.

Quote:
If you want to convince yourself stl is a joke, just make a class with a vector of ints and a couple other primitive members, basically a typical object of some kind. Then make a vector of these classes, each with a dozen ints in the child vector. Add about a million to the vector, then sort it and see how long that takes to complete(for comparison, I can run the same code with my own implementation in about 150ms). Also note how awkward this is, syntactically speaking. Sure, you can blame the implementation, but the implementation is going to be different on each platform and yet tend to universally suck because. Also check the difference between what you get with a static array and a vector, I know that put a sad frown on my face.

Ok, all you're saying is you don't like the sort implementation. STL certainly provides you the flexibility to create an algorithm with a different sort implementation. If you're saying blindly using STL sort is a bad idea, I agree. In fact, I find that 99% of the time if I need something sorted, a vector is the wrong container to start with. Regardless, if you have code that proves that your mechanism is 150ms and the STL version is ridiculously slow, then post it, and I'm sure we can analyze it and tell you what you're doing differently and how to use STL more efficiently.

Quote:Original post by thatguyfromthething
If you want to convince yourself stl is a joke, just make a class with a vector of ints and a couple other primitive members, basically a typical object of some kind. Then make a vector of these classes, each with a dozen ints in the child vector. Add about a million to the vector, then sort it and see how long that takes to complete(for comparison, I can run the same code with my own implementation in about 150ms). Also note how awkward this is, syntactically speaking. Sure, you can blame the implementation, but the implementation is going to be different on each platform and yet tend to universally suck because. Also check the difference between what you get with a static array and a vector, I know that put a sad frown on my face.

Then run the same thing on a compiler supporting r-value references and an appropriate standard library implementation and watch the *one* performance problem that vectors suffer from be completely squashed.

Quote:Original post by Telastyn

init: 110sort: 125array init: 375array sort: 828

Yeah, those arrays are super awesome.


I don't have access to your code to test of course, but I suspect that any benefits you might gain in 'add a bunch of data and sort' tests will be offset by losses in 'remove entries from middle' or 'random access something near the end' or any of the other common collection behaviors. The STL has withstood years of analysis by people far better than you or I, and nobody has made a better performing general purpose vector. Period.

If you think that you or someone else has, prove it. Post some code or quit spreading disinformation.

He's trying to create a hypothetical example where the vector is going to do a lot of copying due to having to re-arrange lots of stuff. This is a pathological example of poor performance given the right circumstances and a sufficiently expensive-to-copy object. Regardless, the problem is non-existant with r-value references so there's no point in even discussing it IMO.

Even if you want to say "well I'm talking about *old* code on compilers that didn't have that support", it's still arguably an invalid comparison because you aren't comparing the same things. A C-array is not a dynamically sized array. If you want a real comparison to a C-array then replace "vector" with boost::array<> and let's talk.

Quote:The STL has withstood years of analysis by people far better than you or I, and nobody has made a better performing general purpose vector.

This is what it comes down to right here. *General purpose* containers. You can create a structure that performs better than the STL in your particular situation, provided you know what you're doing. But it always involves sacrificing generality. The STL is designed to work with all container types without assuming certain traits which break certain objects. For example, if it's okay to move an object around without invoking it's copy constructor/destructor then you can reallocate or shift a vector of these objects faster than the STL would. But then you've sacrificed generality and made your code more dangerous too. If the object is later modified to contain a pointer to it's own memory, you're in big trouble.
Fortunately the commercial compilers actually take notice of what types you store in the vector and they will perform shallow copies on objects which are known to be safe. e.g. a vector of other vectors.

So if you think the STL isn't a satisfactory solution to your problem, you might want to:

1) Profile your code to see if it really matters
2) Switch to a different container as you're probably just using the wrong one
3) Understand why the STL container is slower than a customised solution and which constraints your own method drops in order to outperform it.
4) Determine if the expected performance increase is worth the time you're about to invest
5) Write your own container, profile it, get frustrated when it's somehow slower than the STL, do some research, discover that your compiler's STL implementation is using optimisations you've never heard of, then incorporate those optimisations into your own code and hopefully receive a payoff for all your time spent!