malloc vs new -> speed of access, virtual memory

[Lost Bits]

Hello there C++ pros..

Well, I have recently redesigned an already existing piece of code
that someone else designed - its just a search algorithm they
developed, and has to perfomr millions of loops depending on the data
input..

My problem is that my code can be upto 10 times slower than the
previous persons - and speed is very critical. (and I dont mean
setting up the arrays takes long, I'm more concernted about the speed
of the search algorithm itself..)

The only difference between my code and the other persons code is that
I am
using subscirpt math to represent 2D arrays using 1D arrays, (so every
access to an array has to do that extra math), also my code is more
object oriented, so more levels of indirection - but I try passing my
classes by reference so that it doesnt have to sepnd extra time
actually copying the data, only time to dereference the address..
ANd finally, I use the new/delete operators instead of malloc/free

I tried mashing my classes together to remove levels of indirection,
but by doing that I had to create more arrays using 'new', and my code
got even slower!!??

Then I decided to get rid of the subscritp math and i created dynamic
2D arrays instead of 1D arrays, and still no difference.

So the algorithm is the same, same number of loops etc, so this is not
the problem,
now the only difference left is that I'm using the new/delete
operators. DO you think this will affect my virtual memory or
something lets say and this is causing the search to slow down?

I've hit a roadblock!
I even profiled using gprof, and the only confuins thing is that its
telling me that 'internal_mcount' takes alot of time, i dont know what
the heck this is

this is wat it says:
called/total parents
index %time self descendents called+self name index
called/total children

<spontaneous>
[1] 60.1 198.18 0.00 internal_mcount [1]
0.00 0.00 1/3 atexit [112]

-----------------------------------------------



but yeah anyways, so do you think its the malloc/free new/delete
thing?
your hlep is very apprecieated
htanks!

lost bits =(

 

[Jack Klein]

Hello there C++ pros..

Well, I have recently redesigned an already existing piece of code
that someone else designed - its just a search algorithm they
developed, and has to perfomr millions of loops depending on the data
input..

My problem is that my code can be upto 10 times slower than the
previous persons - and speed is very critical. (and I dont mean
setting up the arrays takes long, I'm more concernted about the speed
of the search algorithm itself..)

The only difference between my code and the other persons code is that
I am
using subscirpt math to represent 2D arrays using 1D arrays, (so every
access to an array has to do that extra math), also my code is more
object oriented, so more levels of indirection - but I try passing my
classes by reference so that it doesnt have to sepnd extra time
actually copying the data, only time to dereference the address..
ANd finally, I use the new/delete operators instead of malloc/free

I tried mashing my classes together to remove levels of indirection,
but by doing that I had to create more arrays using 'new', and my code
got even slower!!??

Then I decided to get rid of the subscritp math and i created dynamic
2D arrays instead of 1D arrays, and still no difference.

So the algorithm is the same, same number of loops etc, so this is not
the problem,
now the only difference left is that I'm using the new/delete
operators. DO you think this will affect my virtual memory or
something lets say and this is causing the search to slow down?

I've hit a roadblock!
I even profiled using gprof, and the only confuins thing is that its
telling me that 'internal_mcount' takes alot of time, i dont know what
the heck this is

this is wat it says:
called/total parents
index %time self descendents called+self name index
called/total children

<spontaneous>
[1] 60.1 198.18 0.00 internal_mcount [1]
0.00 0.00 1/3 atexit [112]

-----------------------------------------------



but yeah anyways, so do you think its the malloc/free new/delete
thing?
your hlep is very apprecieated
htanks!

lost bits =(

The C++ standard does not address the relative speed of any
operations.

If you want to find out what causes the difference in your versions of
your program with your compiler for your operating system with your
compiler options, either use a profiler or create a few test versions.
One that uses 2D arrays with malloc/free and one that uses 1D arrays
with new/delete. That should tell you quickly which change is making
what part of the timing difference under your set up.

 

[Jonathan Turkanis]

Hello there C++ pros..

Well, I have recently redesigned an already existing piece of code
that someone else designed - its just a search algorithm they
developed, and has to perfomr millions of loops depending on the data
input..

My problem is that my code can be upto 10 times slower than the
previous persons - and speed is very critical. (and I dont mean
setting up the arrays takes long, I'm more concernted about the speed
of the search algorithm itself..)

The only difference between my code and the other persons code is that
I am
using subscirpt math to represent 2D arrays using 1D arrays, (so every
access to an array has to do that extra math), also my code is more
object oriented, so more levels of indirection - but I try passing my
classes by reference so that it doesnt have to sepnd extra time
actually copying the data, only time to dereference the address..
ANd finally, I use the new/delete operators instead of malloc/free

I tried mashing my classes together to remove levels of indirection,
but by doing that I had to create more arrays using 'new', and my code
got even slower!!??

Then I decided to get rid of the subscritp math and i created dynamic
2D arrays instead of 1D arrays, and still no difference.

So the algorithm is the same, same number of loops etc, so this is not
the problem,
now the only difference left is that I'm using the new/delete
operators. DO you think this will affect my virtual memory or
something lets say and this is causing the search to slow down?

I've hit a roadblock!
I even profiled using gprof, and the only confuins thing is that its
telling me that 'internal_mcount' takes alot of time, i dont know what
the heck this is

As Jack Klein says, the standard doesn't guarantee anything about the
relative speed of malloc and global operator new. In practice,
however, you should not see such a difference. The problem could be
that the C++ uses new much more than the C version used malloc. This
would be fairly typical. Or there may be a lot of temporary objects
created that you are not aware of. There is no way to diagnose the
problem without seeing more of your code.

Jonathan

 

[Amith]

I've hit a roadblock!
I even profiled using gprof, and the only confuins thing is that its
telling me that 'internal_mcount' takes alot of time, i dont know what
the heck this is

ignore 'internal_mcount'. It is the function inserted(by the compiler)
for gprof when you tell the compiler that you want to prepare the
executable for profiling(e.g -G option in HPUX). So it won't be present
otherwise.

-Amith
C++ Compiler Team
Hewlett Packard

this is wat it says:
called/total parents
index %time self descendents called+self name index
called/total children

<spontaneous>
[1] 60.1 198.18 0.00 internal_mcount [1]
0.00 0.00 1/3 atexit [112]

-----------------------------------------------



but yeah anyways, so do you think its the malloc/free new/delete
thing?
your hlep is very apprecieated
htanks!

lost bits =(

 

[Gianni Mariani]

Hello there C++ pros.. ....
I've hit a roadblock!
I even profiled using gprof, and the only confuins thing is that its
telling me that 'internal_mcount' takes alot of time, i dont know what
the heck this is

this is wat it says:
called/total parents
index %time self descendents called+self name index
called/total children

<spontaneous>
[1] 60.1 198.18 0.00 internal_mcount [1]
0.00 0.00 1/3 atexit [112]

-----------------------------------------------



but yeah anyways, so do you think its the malloc/free new/delete
thing?
your hlep is very apprecieated

It'd nearly impossible to help you. Suggestions of profiling are good.

My experience is that C++ code runs just as fast as (usually faster
than) C code if you steer away from std::i/o streams. But you do need
to know up front what is important to optimize for.

Is this code somthing you can post ?