pouët.net

Go to bottom

Android Multithreading agains OSX or WIN32 multithreading.

category: code [glöplog]
 
Is somebody tried multithread with Android ?
The real question is why my multithread physics is slower with mutithread (pthread) on Android while multithreading with pthread again, run faster on MacOSX or WIN32 ?
Is somebody experienced the same issue ?
added on the 2015-09-18 05:20:50 by Barti Barti
note: I've tried to change priority of the threads that execute on demand a processing throught an external variable.
added on the 2015-09-18 06:01:25 by Barti Barti
If only there were some profiling tools out there....

And of course, we all know that the only diff between a PC and a mobile device is the OS, so it's got to be that.
what slummy said..
bandwidth limitations / cache trashing would be an obviously place to start looking.
added on the 2015-09-18 09:54:37 by Psycho Psycho
Quote:
on demand a processing throught an external variable.

external variable? using some synchronisation protection.. how does it check for "on demand processing, is it using mutex/semaphores?
added on the 2015-09-18 10:21:48 by Canopy Canopy
void * threadfn(void *data)
{
while (running)
{
if (act)
{
do(act);
usleep(0);
}
else usleep(0);
}
return 0;
}
added on the 2015-09-18 16:11:02 by Barti Barti
it's thread safe, but on android it runs slower than single threaded.
added on the 2015-09-18 16:15:03 by Barti Barti
Have you measured how long the sleep actually sleeps?
added on the 2015-09-18 17:28:22 by yzi yzi
usleep(0) is for change threads focus.
added on the 2015-09-18 18:28:10 by Barti Barti
Have you messured how long it takes.
added on the 2015-09-18 19:36:19 by yzi yzi
not exaclty, I did not look at this, but why so many différences between (linux) android native code and win32 or OSX ?
added on the 2015-09-18 19:56:00 by Barti Barti
Because one of them is meant for mobile devices, perhaps?

Can you measure the time it takes? On Android you can use clock_gettime(), which should be pretty accurate, at least enough to see if the program is regularly sleeping considerably longer than "zero" time units. On Win32, use QueryPerformanceCounter().

Try tracking the accurate "working" vs. "not working" start and end times for every thread, on your various platforms, and plot them on a timeline side by side. You might be surprised at what you'll see.
added on the 2015-09-18 21:43:27 by yzi yzi
Without answering your question: If you want to yield control back to the OS, use sched_yield(), not usleep(0) (the OS can choose to make a short usleep into a spin loop).

Also, you should definitely not busy-poll for a shared variable to change in a thread; it's likely both to be very inefficient and plain-out wrong (memory models are very complicated beasts). You should have a shared variable under a mutex, and set a condition variable when it's updated.
added on the 2015-09-18 22:59:40 by Sesse Sesse
with sched_yield() to switch processing threads, it works !
added on the 2015-09-19 03:13:19 by Barti Barti
If you had plotted the working/not working blocks on timelines across all your threads, you might have discovered that yourself. :) Or if you had googled for a couple minutes, you might have noticed pages suggesting not to usleep(0). If you type "usleep(0)" in the search box, it will suggest searching for "usleep(0) sched_yield()".

I'd still recommend doing the graphical plotting / profiling, because you might notice many things about what's happening, and you can compare it across platforms.
added on the 2015-09-19 10:03:27 by yzi yzi
indeed. thats why i asked about how the checked was done before the code was posted. i've done a lot of time critical multithreading work and if you did that kind of code on windows it would burn the cpu up and eat resources, on mobile i'd assume it would also annihilate battery life, but i'm not sure how other platforms like android would behave.

for example, on windows i'd do waitformultiobjects, using 2 mutexes a "kill event" and a "do stuff" event.. then signal those from the other threads.

i guess as well as profiling, once simple thing would be to see if the removal of the calls to usleep(0) actually make a difference at all. if they don't, that explains why performance is degraded.
added on the 2015-09-19 12:43:50 by Canopy Canopy
Canopy: Android is stricter than regular Linux in that it can put the CPU to sleep even if badly behaved code like this is running (unless you are holding a wakelock, which requires extra permissions). So it would be mitigated somewhat; definitely not recommended, though, as it'd still burn battery while the CPU was awake. Using the OS' primitives instead of rolling your own is the only way to go here.
added on the 2015-09-19 13:01:24 by Sesse Sesse
#include <sched.h>
sched_yield();

instead of usleep(0) or nanosleep(~0)

is the solution of the problem.
added on the 2016-01-19 17:27:44 by Barti Barti
A note to kids: never ever do what Barti does in that horrible yielding busy loop, look up "job queue" and "condition variables" instead :)
added on the 2016-01-20 23:27:47 by reptile reptile
I've just seen I have posted already the stuff.
added on the 2016-01-21 04:19:12 by Barti Barti

login

Go to top