Android Question Multi core processing in Android

[incendio]

Today's, phones / tablets, is common to have more than 1 core.
When app doings some processing, is it using all cores or only 1 core used? And who's controlling how many cores used by app, Android OS, or developer?

 

[Informatix]

http://stackoverflow.com/questions/...ead-application-utilize-multi-core-in-android

 

[thedesolatesoul]

B4A code runs on a single thread. Some of the libraries do work in a background thread.
Developers can spawn threads, but the thread management onto the cores will be done by the OS.

 

[incendio]

http://stackoverflow.com/questions/...ead-application-utilize-multi-core-in-android

Thanks for your info

B4A code runs on a single thread. Some of the libraries do work in a background thread.

Thanks for your replied. It is a pity that B4A doesn't support running on multiple threads. Sometimes, there is a case that even with some of the libraries runs in background, still not enough.

 

[Erel]

You can use the Threading library to create additional threads.

Though in most cases it is not required. For example the SQL library supports both synchronous and asynchronous queries. So instead of creating additional threads and managing them yourself you can use the asynchronous method.

 

[incendio]

I am afraid, on my case although SQL library supports asynchronous queries, this may not enough.

Here is the sample case.

I have local sqlite table that need to update its values from web server on a periodically basis.
Table structure like this (this is just a sample, actual structure is more complex)
- Id int primary key
- Field1 int

Table has about 20000 records and growing.
The procedure is simple, get Field1 value on web server (via RDC) base on Id then update it to local sqlt table.

Since no multi thread supported, app must loop into 20000 records for download and update process.
If multi thread supported, I can create, may be 10 threads, each thread only need to handle 2000 records.

 

[Informatix]

I am afraid, on my case although SQL library supports asynchronous queries, this may not enough.

Here is the sample case.

I have local sqlite table that need to update its values from web server on a periodically basis.
Table structure like this (this is just a sample, actual structure is more complex)
- Id int primary key
- Field1 int

Table has about 20000 records and growing.
The procedure is simple, get Field1 value on web server (via RDC) base on Id then update it to local sqlt table.

Since no multi thread supported, app must loop into 20000 records for download and update process.
If multi thread supported, I can create, may be 10 threads, each thread only need to handle 2000 records.

You make a confusion between "multicore" and "multithreading". On all Android devices, many threads are run on the same core. That does not make things faster. That just gives the feeling that some things are run in parallel (but of course they're not). That won't change anything to your need. What you need is to run these threads in their own core for a true parallelism. In most cases, it's the OS or the CPU itself that decides the allocation. I don't know if you can force it on Android, but usually it's done in a very efficient way so you don't have to worry.

 

[Erel]

It is not correct that there is no multithreaded support.

RDC (which is based on HttpUtils2) is handled by a pool of background threads. The same is true for the asynchronous SQL methods.

You need to fetch all the data and then insert it with SQL.ExecNonQueryBatch.

 

[incendio]

You make a confusion between "multicore" and "multithreading". On all Android devices, many threads are run on the same core. That does not make things faster. That just gives the feeling that some things are run in parallel (but of course they're not). That won't change anything to your need. What you need is to run these threads in their own core for a true parallelism. In most cases, it's the OS or the CPU itself that decides the allocation. I don't know if you can force it on Android, but usually it's done in a very efficient way so you don't have to worry.

I thought, based on link you gave me, core allocation is done on Android OS, developer can only tried to do multi thread for better performance. May be I was misunderstood

About performance, in windows OS, when CPU is multi core, multi thread improved performance a lot. In my case, it was at least 6-7 times faster.

It is not correct that there is no multithreaded support.

RDC (which is based on HttpUtils2) is handled by a pool of background threads. The same is true for the asynchronous SQL methods.

You need to fetch all the data and then insert it with SQL.ExecNonQueryBatch.

Oh course there is multithreaded support, but in my case, not sure.

If I fetch all data, this background thread, waits until all data fetch then when insert with SQL.ExecNonQueryBatch, wait again until all insert operation finished.

What I have in mind, 20000 records, divided into 10 threads, each threads, handle 2000 records for download and insert operations, and if possible, do some analyzing downloaded data before inserted to local table.

 

[Informatix]

I thought, based on link you gave me, core allocation is done on Android OS, developer can only tried to do multi thread for better performance. May be I was misunderstood

??? It's what I said: "it's the OS or the CPU itself that decides the allocation [...] it's done in a very efficient way so you don't have to worry."

About performance, in windows OS, when CPU is multi core, multi thread improved performance a lot. In my case, it was at least 6-7 times faster.

On a single core, that improves nothing, whatever OS you have. The main interest for an app on a single core is to be able to do something while an IO operation is pending, e.g. computing something while a data is fetched from the web or written to the disk.

 

[Erel]

What I have in mind, 20000 records, divided into 10 threads, each threads, handle 2000 records for download and insert operations, and if possible, do some analyzing downloaded data before inserted to local table.

You can already do it. Create 10 requests and send them. They will be handled by 10 background threads.

 

[corwin42]

What I have in mind, 20000 records, divided into 10 threads, each threads, handle 2000 records for download and insert operations, and if possible, do some analyzing downloaded data before inserted to local table.

That is exactly what you can do with the threading library.

As Erel said you can even do this with HttpJob and asynchronous SQLite.

 

[incendio]

You can already do it. Create 10 requests and send them. They will be handled by 10 background threads.

Did you means, something like this

Sub GetData
   DBRequestManager.ExecuteQuery(cmd1, 0, 1)
   DBRequestManager.ExecuteQuery(cmd2, 0, 2)
   DBRequestManager.ExecuteQuery(cmd3, 0, 3)
End sub

Sub JobDone(Job As HttpJob)
   If Job.Success = true Then
      If Job.JobName = "DBRequest" Then
          Dim result As DBResult = DBRequestManager.HandleJob(Job)
          If result.Tag = "1" Then
              DoProc1
          else If result.Tag = "2" Then 
              DoProc2
          end if
      end if
   End if
End Sub

This is only for download and update/insert operation, and for analyzing before update/insert data, still need threading library, right?

 

[DonManfred]

Sub JobDone(Job As HttpJob)
If Job.Success = true Then
If Job.JobName = "DBRequest" Then
Dim result As DBResult = DBRequestManager.HandleJob(Job)
If result.Tag = "1" Then
DoProc1
else If result.Tag = "2" Then
DoProc2
end if
end if
End if
End Sub

You did forget a

Job.Release

at the end of the sub

 

[Erel]

This is only for download and update/insert operation, and for analyzing before update/insert data, still need threading library, right?

It depends the code you plan to run. Try it first without creating additional threads. It might be fast enough.

 

[incendio]

You did forget a

Job.Release

at the end of the sub

Haha, thanks for remind me. I did really forget about this code on my actual app.

It depends the code you plan to run. Try it first without creating additional threads. It might be fast enough.

Ok, I will try it.

 

[incendio]

I have tried to breakdown download and insert operation into 4 threads, log the time to finished the operation and compared the result with operation runs on 1 thread.

These are the result :
1) there was no different running DBRequestManager with 1 thread or multiple thread cause DBRequestManager runs in sequence, runs in background, but not runs in parallel. If 1 thread finished in 1 mins, then 4 thread, each one finished in 15 sec, but runs one by one, total time still 1 mins
2) ExecNonQueryBatch, runs in parallel. All threads will finished almost at the same time.

 

[incendio]

You make a confusion between "multicore" and "multithreading". On all Android devices, many threads are run on the same core. That does not make things faster. That just gives the feeling that some things are run in parallel (but of course they're not). That won't change anything to your need. What you need is to run these threads in their own core for a true parallelism. In most cases, it's the OS or the CPU itself that decides the allocation. I don't know if you can force it on Android, but usually it's done in a very efficient way so you don't have to worry.

I think there is an Android app that seem to able to runs threads in their own core.
The app is DroidFish+Stockfish engine, this is the chess program. It has a setting to let users to choose how many core to use for this app.
If users choose 3 cores, all these cores will run in max freq, other core will not. (Checked it via Trepn Profiler - only runs for Qualcom chipset)

As for app compile with B4A, it seem also runs in multicore, but not all core used at max freq. Only 1 core always run in max freq, even users do nothing / on idle. When users clicked or touch or do some task, others core get active, but not in max freq.

I don't what development tool to build DroidFish and maybe it is difficult to find tools (that has rapid development like B4A) that support multicore dev in Android.
My dev tool in Window OS also only support multithread.

 

[Informatix]

I think there is an Android app that seem to able to runs threads in their own core.
The app is DroidFish+Stockfish engine, this is the chess program. It has a setting to let users to choose how many core to use for this app.
If users choose 3 cores, all these cores will run in max freq, other core will not. (Checked it via Trepn Profiler - only runs for Qualcom chipset)

As for app compile with B4A, it seem also runs in multicore, but not all core used at max freq. Only 1 core always run in max freq, even users do nothing / on idle. When users clicked or touch or do some task, others core get active, but not in max freq.

I don't what development tool to build DroidFish and maybe it is difficult to find tools (that has rapid development like B4A) that support multicore dev in Android.
My dev tool in Window OS also only support multithread.

Unless you have a strong reason to think that the OS and the CPU do not do their job efficiently in allocating cores, I don't think you have to worry about that. In my ULV lib, I use concurrent threads to load images asynchronously and I do not force the allocation on different cores (I don't know how to do it in Java anyway) but it is obvious when running ULV on different devices that it benefits from multiple cores.

 

[Erel]

You can ask the OS to create threads for you. You don't have any control over the cores. The OS is responsible for that.

When you use the Threading library to create a thread you get the exact same threading behavior as Java written applications. The same is true for threads used internally by the libraries.

Note that tou need to be careful with SQLite database and multithreaded apps.

Have you encountered any performance issue?