KVR Audio

Miles1981 · Post by **Miles1981** » Fri Apr 06, 2018 9:48 pm

It's not about that. Look at the presentations, vectors, even if resized (not too frequently, but that's the case for the usual implementation) is faster due to the low cache misses.
And if you re doing FIFOs, then deque is perhaps the best for the same reason.

syntonica · Post by **syntonica** » Sat Apr 07, 2018 4:01 am

I hadn't thought about cache misses, but I'm old school--we had 4K and punched 127 on a paper tape to strike it out.

I'm still learning about the modern architectures and optimization techniques, but right now, I'm quite happy with the speeds I'm getting with hand optimization and then running through the compiler with O2000!

My Windows version plug-in is now officially in Beta. I'll have to beat on it a bit, but it all looks good. Expect circles are jaggy... I know! Square knobs!

Chaotikmind · Post by **Chaotikmind** » Sat Apr 07, 2018 8:50 am

syntonica wrote:I hadn't thought about cache misses, but I'm old school--we had 4K and punched 127 on a paper tape to strike it out.

I'm still learning about the modern architectures and optimization techniques, but right now, I'm quite happy with the speeds I'm getting with hand optimization and then running through the compiler with O2000!

Cache misses have a terrible toll on the execution speed, any access to memory is ultra long compared to any instruction execution.

mystran · Post by **mystran** » Sat Apr 07, 2018 12:37 pm

syntonica wrote: Heh. I needed something arbitrarily expandable. I could have just thrown memory at the problem and used an array large enough to handle extreme cases, but the list was faster, simpler and more elegant, despite creating and destroying the items.

Most beginner programmers will run to linked lists when they realise they don't have a nice small upper bound for their data-set size, but usually when you need an "arbitrarily expandable array" the best thing to do is use std::vector, because this is precisely what std::vector is designed to do. Linked lists have so much overhead in practice that it's almost always faster to just copy your data into a larger array whenever you run out of space (which incidentally is exactly what std::vector will do for you). The only reason to really ever use linked lists is when you can prove that this gives your algorithm better worst-case complexity and in that case you usually want to use intrusive lists rather than a generic container.

edit: I realise some other people said essentially the same thing before me, but it's important enough point that it should be repeated as a sleeping mantra until your brain is unable to think about std::list at all.

edit2: in all fairness, std::list is handy for some situations where it simplifies your code and performance is unlikely to matter one way or another.. but whenever you are thinking about performance at all, there's usually a better choice

Chaotikmind · Post by **Chaotikmind** » Sat Apr 07, 2018 2:31 pm

Maybe it should also be pointed that all std container can have custom allocators, for edge cases when standard allocation/reallocation is too expensive

syntonica · Post by **syntonica** » Sat Apr 07, 2018 5:22 pm

I did a quick test with my list. I pre-allocated an array for them to live in vs new/delete for each node. As I suspected, the speed was identical. However, my array was only 100 elements, so I'd rather go with my original solution in the extremely rare case of more than 100. Like I stated before, I need FIFO AND the ability to delete random nodes. Walking the list and deleting some node when found is still faster than scanning an array, deleting the node and then moving any remaining nodes up. At least in my case.

I understand what you're all saying, but the scale or need to scale just isn't there. I find too many programmers want to use the sledgehammer for everything when just the flyswatter will do. I always start with the naive solution to get something running and then look at it and say, How can I make this bit faster or more elegant, as the case may be.

My next task is to a) figure out how to use the optimize on the VS compiler/linker and b) look at my heap usage and see where things can be improved, if needed, since I declare scads of arrays. Maybe vectors will speed things up, maybe not. ¯\_(ツ)_/¯

Miles1981 · Post by **Miles1981** » Sat Apr 07, 2018 10:04 pm

It all depend on how you measure things, and also how you write the code in the first place... Once again, you may not want to use a vector in your case, as it will move data when you pop the front element.

v1o · Post by **v1o** » Sun Apr 08, 2018 1:39 am

Swift is the future of programming languages. At least on iOS and Mac.

Dozius · Post by **Dozius** » Sun Apr 08, 2018 3:41 am

v1o wrote:Swift is the future of programming languages. At least on iOS and Mac.

When the other option is Objective-C, pretty much anything will look good.

syntonica · Post by **syntonica** » Sun Apr 08, 2018 5:27 am

Dozius wrote:
v1o wrote:Swift is the future of programming languages. At least on iOS and Mac.
When the other option is Objective-C, pretty much anything will look good.

ARC just ruined it for me... Now, what was my safe word again?

I've looked at Swift and it seems pretty straightforward. I'll give it a go when I have a Mac-only project, which will probably be like never...

stratum · Post by **stratum** » Sun Apr 08, 2018 8:57 am

v1o wrote:
Swift is the future of programming languages. At least on iOS and Mac.

Once upon a time BASIC was the future (or so it seemed), then there was the 4GL garbage, which literally meant that some database vendors were arrogant enough to tie your code to their database by offering an easy to use programming language, which had a not so hidden cost being that your code wouldn't ever work anywhere else. Just like Swift will never work well anywhere other than a Mac unless somebody manages to produce a bug-level compatible version of all related system libraries.

quikquak · Post by **quikquak** » Sun Apr 08, 2018 3:27 pm

So in summary, no it has no future. Use what ever the kids say is cool, and speed and efficiency is ALL LIES told by their fathers.
Just throw more resource at it if it's slow, right?

mystran · Post by **mystran** » Sun Apr 08, 2018 3:34 pm

Everyone also please keep in mind that you are not a real programmer if you write code in more than one language, because real programmers know that there is only one language worth using and it's the best language for every programming problem you might ever encounter.

syntonica · Post by **syntonica** » Sun Apr 08, 2018 4:52 pm

mystran wrote:Everyone also please keep in mind that you are not a real programmer if you write code in more than one language, because real programmers know that there is only one language worth using and it's the best language for every programming problem you might ever encounter.

Which is, of course, Forth.

nonnaci · Post by **nonnaci** » Sun Apr 08, 2018 9:30 pm

The high-end of performance optimization on general purpose CPUs falls into several buckets of avoiding cache misses (memory access patterns), vectorization (SIMD and instruction level parallelism), and the overall number of floating point operations per second (algorithm). C exposes enough of the metal for addressing all these points. C++ provides the abstractions for system building ontop of that skin.

"Does C++ Have a Future?"