0

I have a big array, iterating and doing my work over it takes about 50ms. App i am developing will run on tegra3 or other fast cpu. I have divided my work for four threads, using pthread, i have taken width of my array, divided it by total core count found in system, and i am iterating for 1/fourth of array in each thread, everything is ok, but it now need 80ms to do the work. Any idea why multithread approach is slower than single thread? If i lower cpu count to 1 everything is back on 50ms.

for(int y = 0; y<height;y++)
{
    for(int x = 0; x<width; x++)
    {
        int index = (y*width)+x;
        int sourceIndex = source->getIndex(vertex_points[index].position[0]/ww, vertex_points[index].position[1]/hh);
        vertex_points[index].position[0]+=source->x[sourceIndex]*ww;
        vertex_points[index].position[1]+=source->y[sourceIndex]*hh;
    }   

};

i am dividing first for loop of above code into four parts based on cpu count. vertex_points is a vector with positions.

so it looks like

for(int y=start;y<end;y++)

and start/end vary on each thread

ZZZ
  • 678
  • 2
  • 10
  • 26
  • Why do you have 4 threads though? – Alexander Kulyakhtin Jul 14 '12 at 14:46
  • Android was not designed to be a multi-threading system, the entire GUI aspect is actually on a single thread. The additional complexity involved in having to keep track of events from a multi-threaded perspective would have RomainGuy, DianneHackborn, JBQ swearing like there's no tomorrow, considering how to keep track of refreshing screens, receiving broadcasts across on a multi-threaded architecture. That is why it is strongly advised to use threads on a background so as not to hog up the GUI's single thread. – t0mm13b Jul 14 '12 at 14:48
  • @t0mm13b Why are you throwing in some names that doesn't add to your answer (which is irrelevant to the question) – Alexander Kulyakhtin Jul 14 '12 at 14:52
  • @Alex - they are the engineers behind the AOSP source :) – t0mm13b Jul 14 '12 at 14:53
  • The point I am making is this, multi-core is not efficient because Android does not know how to take advantage of it. – t0mm13b Jul 14 '12 at 15:01
  • @t0mm13b Sure, but why are you throwing in their names (or any names)? – Alexander Kulyakhtin Jul 14 '12 at 15:02
  • @t0mm13b: if he's creating multiple threads to do his work, then he is, by definition, not doing any work from the GUI thread... – David Given Jul 14 '12 at 15:12
  • @DavidGiven Well, we really don't know how the OP's defining 'App' as in the question do we? And yes you do have a point there. – t0mm13b Jul 14 '12 at 15:16

1 Answers1

2

Thread startup time is typically on the order of milliseconds - that's what's eating your time.

With that in mind, 50 ms is not the kind of delay I'd worry about. If we were talking 5 seconds, that'd be a good candidate for paralellizing.

If the loop needs to be performed often, consider a solution with threads that are spun up early on and kept dormant, waiting for work to do. That'll run faster.

Also, is the CPU really 4-core? Honest cores or hyperthreading?

Seva Alekseyev
  • 59,826
  • 25
  • 160
  • 281
  • its nexus7 with tegra 3, so it looks like it have 4 of them :) So if thread startup is taking a lot of time, its a good idea to start them at begining and just call to do their job every frame as you said, i will try this approach, 50 ms is kind of delay because its an opengl app :) and i need to move a lot of objects in my simulation, its quite easy just add two values, but there is lot of them, so it takes some time, thats why i wanted to try to parralel it so i get bigger sim resolution and nicier results :) – ZZZ Jul 15 '12 at 17:59