object on stack/heap performance problems

[orobalage]

Hi!

I was developing some number-crunching algorithms for my university,
and I put the processor into a class.
While testing, I found a quite *severe performance problem* when the
object was created on the stack.

I uploaded a test archive here: http://digitus.itk.ppke.hu/~oroba/stack_test.zip

Inside you'll find the number cruncher class (CNN in cnn.h and
cnn.cpp), as well as two test files: test_slow.cpp and test_fast.cpp.
They differ ONLY in where the processor object is created. In one, it
is created on the stack, in the other, it is created on the heap. Yet,
when I call the member function process(), the performance difference
is 5x!!!

Can someone with a higher knowledge of object layout and whatsoever,
tell me why this is happening?

--
Thanks in advance,
B.

[Kai-Uwe Bux]

Martijn van Buul wrote:

* or*******@gmail .com:

>I wrote that code almost 2 years ago. Actually, you don't need to be
sure about what the algorithm does :)

I tend to disagree. It wouldn't surprise me if what you're seeing is the
result of uninitialised data. Most importantly, CNN::lower_limi t,
CNN::upper_limi t, CNN::Z and a few others never seem to be initialised,
but I could be wrong. Have you tried checking the outcome (whatever
that may be) of Process() in both cases?

Most of your calculations are done on the .data members of the various
rows. SInce these are always malloc-ed (in a nasty
premature-optimalisation way), the location of the instance of the CNN
class has little influence.

Uninitialised data (Along with subtle out-of-bounds errors) would also
explain why some people don't seem to be having this "problem", while
others do.

That is an interesting idea. This is what valgrind has to say:

==15156== by 0x414C825: (below main) (in /lib/libc-2.5.so)
==15156==
==15156== Conditional jump or move depends on uninitialised value(s)
==15156== at 0x8049328:
(within /home/bux/bux/todo/towrite/c++/experiments/news_group/cnn/stack_test/test_fast.exe)
==15156== by 0x8049AD6:
(within /home/bux/bux/todo/towrite/c++/experiments/news_group/cnn/stack_test/test_fast.exe)
==15156== by 0x414C825: (below main) (in /lib/libc-2.5.so)
==15156==
==15156== Conditional jump or move depends on uninitialised value(s)
==15156== at 0x80491EC:
(within /home/bux/bux/todo/towrite/c++/experiments/news_group/cnn/stack_test/test_fast.exe)
==15156== by 0x8049AD6:
(within /home/bux/bux/todo/towrite/c++/experiments/news_group/cnn/stack_test/test_fast.exe)
==15156== by 0x414C825: (below main) (in /lib/libc-2.5.so)
==15156==
==15156== Conditional jump or move depends on uninitialised value(s)

And it goes on like this forever. Similar output for test_slow.exe

Best

Kai-Uwe Bux

[orobalage]

Thanks Martijn!

Indeed, it was uninitialized data!
Problem is solved it seems, and another big experience in my bag,
thanks for it! :)

What made it somewhat obscure for me, is that if I rearranged the
members, it also became fast sometimes.

Anyway, we make mistakes, that I made a huge one, hope others will
learn from this too.

Good day to you, and thanks again everyone!

--
Greets,
B.

[Martijn van Buul]

* or*******@gmail .com:

Thanks Martijn!

Indeed, it was uninitialized data!
Problem is solved it seems, and another big experience in my bag,
thanks for it! :)

Glad I could help.

--
Martijn van Buul - pi**@dohd.org

[jmoy]

On Jul 1, 9:45 pm, Martijn van Buul <[e-mail] rote:

* orobal...@gmail .com:

I wrote that code almost 2 years ago. Actually, you don't need to be
sure about what the algorithm does :)

I tend to disagree. It wouldn't surprise me if what you're seeing is the
result of uninitialised data.

I wrote some functions to compare the structures member-by-member,
comparing the data arrays element by element.

The answers come out different when Process() is called with the same
initial data on a CNN allocated on the stack and a CNN allocated on
the heap. Also, the differences are in different places and the values
from each method itself are different on different runs.

So I would tend to agree that it is uninitialized data and/or maybe
some other bug which is the culprit.

Jyotirmoy