10 replies to this topic

[rouncer]

ive got this headache of a problem, i was wondering if its happened
to anyone else and they can help me.

ive checked through the code over and over and for some strange reason
me accessing an array is going slow.

i deallocated the entire program, except for just one working part, and it
seemed to make the array grab a little bit quicker... i totally stripped every
thing and the array grab looks like this:

*(cyclet+oscillatoroffset) -> instead of -> cyclet[oscillatoroffset]
which is the same thing isnt it.

its a music program, instead of drawing the oscillators with iterating
timers, im actually prestoring them in small samplets for a single cycle.

its just an add to a pointer to fetch out of an array?
but something has gone wrong and its going a lot slower than that.

or are arrays this slow? i dont think so, im really confused can you help
me out...

[Reedbeta]

How do you know the array access is slow? Did you do a profile? Have you made a small test program that just has the array and nothing else in it? How slow are we talking about?

It could be a cache problem, but array access obviously shouldn't be very slow.

[rouncer]

i figured it could be in virtual memory, and its fetching off the disk, the more
memory i released the quicker it went funnily enough.
ive chopped the program completely, i havent timed it with the computer clock
and it is DEFINITELY IT thats slowing it down, because ive taken it out and
it runs well without it.
im not allocating stuff all ram for the program, i took it all out...
so accessing an array shouldnt be any slower than accessing a variable?
at least clear me up there and ill get back to it, or ill dump the project, one of
the two.
the code might have a voodoo curse on it, but then again i could be wrong... so
its definitely NOT accessing an array that could possibly be slowing it down.
even though it definitely looks like it.

[rouncer]

i dont know whats wrong with it - i tested it out on a couple of other computers, and the faster newer computer could take it, but the other computer of equal speed died about the same time.

i can finish it now as it is fine i just have to limit the program a bit, but im just really dumbfounded...

i used to think using lookup tables was the best situation for avoiding calculations- but now this has come up i really feel i dont know what im doing and its getting to me. i dont how to optimize for peanuts.

accessing the lookup table is going slower than doing the calculation, does that sound completely wrong?

theres 2 arrays that are being used that slow it down, ones a lookuptable with a calculation in it, and anothers an lfos cycle shape,
but the actual sound oscillators seem to be working fine...

anyway, send this posting to hell, because i dont think anyone can help with something this stupid.

[geon]

You haven't told us what you store in the array. Could it be a bandwidth problem?

[Nick]

rouncer said:

the code might have a voodoo curse on it, but then again i could be wrong...

Voodoo works on people, not computers, so you're wrong. ;)

Quote

accessing the lookup table is going slower than doing the calculation, does that sound completely wrong?

No. The time it takes to access memory depends highly on the coherency between consecutive accesses. A computer typically has four types of 'memory': L1 cache, L2 cache, RAM, and hard disk. L1 cache is only a few kilobytes large, but very fast. L2 cache is about a megabyte, but a little slower than L1 cache. RAM is nowadays around a gigabyte, but it takes hundreds of clock cycles to access it. Disks are many gigabytes but extremely slow to access.

Where your array is located depends entirely on its size and the access pattern. The CPU attempts to keep what you previously accessed in cache memory as long as possible, but it's really quite small so you have to keep your array small. What might be happening in your application is that it's too big to fit in cache memory so accesses take a long time. Just doing some calculation is often faster than accessing a big lookup array.

Anyway, the most important lesson is: Premature optimization is the root of all evil. First implement things the straightforward way. Just get it working correctly, that's often already hard enough. Don't worry yet about optimizations, especially the low-level ones. It's likely that most of it will be fast enough anyway, so don't waste your time 'fixing' something that ain't broken. Only when your application is fully functional, and it doesn't reach the performance goals, you can start optimizing. But don't start randomly optimizing what you thing is slow. Use profiling techniques to locate exactly the slow code, and focus only on that.

Good luck!

[random task]

What compiler are you using? Did you do a release build, and did you make sure that runtime checks are switched off in the compile settings?
I've got the same problem using VS 2005, when using an STL vector. Accessing the data through the []-operator triggers some runtime range checking in debug builds. Using *(cyclet+oscillatoroffset) the way you described it avoids the checks.

[donBerto]

How about you show us some code - figuring out how fast/slow something based on a one-line code doesn't help much.

[rouncer]

id tried it in release random task but unfortunately it didnt improve, but
thanks for reminding me.

nick, thanks for telling me that i didnt know, i was running an offset wrapping
its index across the array and its about 250 kbytes. so that would be enough to
kill my small computer over just doing the calculation.

ah yeh, so optimization isnt just an easy thing to do, i went straight for
lookuptables all over it, geeze what a mistake, i then just went back through
it all removing them.

in one case, the lookup table worked, but the rest didnt.

it ended up going nowhere near as fast as i thought it would.
im not going to dump the project, i just cut a heap of stuff it didnt need
out of the poll. going to make it a smaller more specific use type thing.

hey thanks, ill watch out next time i need to do it.

[rouncer]

your right, i dropped it to 655 members, at it worked fine.
cool.

[Rubicon]

> accessing the lookup table is going slower than doing the calculation, does that sound completely wrong?

Possibly. It once was the case that CPU's were so slow that you did all you could using tables to speed it all up. In the modern world, fitting your data into the L2 cache and keeping it there is far more relevant as a general principle and LUT's and tree graphs are about as un-cache-friendly as you can get. Use them with care and only when you really need to.

On certain consoles I can't mention, this is so important that a serious recomendation is to compress vectors into 6 byte compressed versions and un/repack them when you need to use them, just to keep memory access down. It's that important. PC's aren't *that* bad, but it's only a question of scale.