Hellow everybody

If any other efficient / (purpose of speed up) way to move 0,10,20,30....end values into another dynamic array:


Thanks advance

Although some compilers will reorder expressions which never vary in a loop as an optimization, you may want to perform the optimization manually:
If this code was to be maintained by anyone else, manually pulling the unchanging expression out of the loop will point out to the next person that you understood that recomputing the upper limit never changes throughout the life of the loop.

Furthermore it is possible (but not at all certain) that for some compilers and some CPUs, incrementing an integer is faster than dividing by 10, so you could even try something like

To vmthiru:

Note that I have seen it stated as a certitude that using pointer notation is faster than array notation. That may or may not be true for some cases, but I have never seen it. I mean, I checked it out a couple of times, but I never saw any difference in performance. Not even with BDS C running under CP/M on my homebrew Z80 system in 1981). I have absolutely zero interest in pursuing this particular fable. (Your Mileage May Vary, but see Footnote.)

Now, in my experience, trying to outguess the compiler with regards to optimization may be an amusing divertissement, but it is rarely productive. Even if it proves to give some advantage for a particular compiler on a particular CPU with a particular set of optimization switches, it may very well be counter-productive for other compilers (and even for later versions of the same compiler).

For example I remember a case on an older machine with an older version of a particular compiler (and an older language), multiplication took seven times as many machine cycles as addition, and division took 14 times as many.

So, first of all, we would never divide if it were possible to perform the same arithmetic with multiplication.

Secondly, if we could add instead of multiply, we would do it.

So instead of

We would write

Nowadays, for integers, typical C compilers may recognize that multiplication of an integer by a power of 2 can be accomplished with a single shift instruction. At least that's what gcc does, even without turning on any optimization.

If the compiler is really good, it might even take our hand-optimized sequence and give code that is as good as just writing y=4*x in the first place. (Or, maybe not.)

Furthermore, to belabor the point, instead of multiplying by 10, we would do something like "multiply by four, add the original and then multiply by 2":
As a matter of fact, I have used this little trick on embedded systems for processors that don't have a multiply instruction, so the actual multiplication takes many, many machine cycles.

I think a compiler for a more-capable CPU might be hard-pressed to make good optimization sense of my little "multiply by 10" sequence. (Of course, I could be wrong, maybe it could make it as efficient as if I had simply written y=10*x.)

Even if the compiler didn't optimize it for us, it is entirely likely that with instruction and data caching in modern CPUs, the actual machine time might not be favorably affected by any manual optimization efforts.

And, so it goes...

Bottom line (however, see Footnote): If someone shows you something on paper that is supposed to be faster, you can think about it and you can try it, but you don't have to believe it. If someone shows you some actual machine measurements, you should keep in mind that that only applies to the exact environment under which the tests were run (compiler, CPU, operating sytem, etc.)

Regards,

Dave

Footnote (the real bottom line): If you are actually trying to improve performance in a program (rather than just thinking, in general, about ways to speed things up), I think it's a good idea to find out where the real bottleneck is (by using a code profiler, for example). The real bottom line is that I have seen, time and time again, where people have spent resources (time==money) to optimize something that has a miniscule (at best) effect on overall performance. In other words, they often optimize the wrong thing.