[maemo-developers] [maemo-developers] Re: Optimized software

[From: Karoliina Salminen]

Antti P Miettinen wrote:

>Jose Manrique Lopez de la Fuente <jsmanrique at gmail.com> writes:
>  
>
>>* Wherever possible, use multi-threading to push latency into the background.
>>    
>>
>
>Umm.. 770 is uP, so heavy multithreading could just hurt performance
>by introducing unnecessary context switching. I guess moving
>synchronous I/O to a separate thread could be seen as latency
>reduction via multithreading. But in general, if there is heavy
>communication need between threads, use of a single thread and
>non-blocking I/O would save context switches.
>  
>
Just some little thoughts and humble opinions about multithreading in 
general:
Indeed, if there is heavy communication between threads. And it is also
true that the hardware in N770 is quite reduced if compared to
desktop computers or servers and that ARM is said to get more penalty than
others from context switching. It depends on the situation if the 
context swithing
is causing a visible performance penalty. It has to be remembered 
however, that
the OMAP is not that incapable if we think that supercomputers were
less capable not so long time ago, I have been using in the past for 
example VAX
systems for developing software, there were some hundred users per node
and it is a lesser capable hardware than N770 :).
But usually threads are used in UI when there is no such thing
than heavy communication between them. One common example
of multithreading in UI is downloading a file in browser. The
user can continue browsing while the browser downloads
the file on background. The downloading can also happen in
a separate process, but anyway, if that would not be distributed at all but
single threaded and synchronous and all in one process, the user would 
have to wait for
e.g. the 600 MB ISO image to download before going to the next web page.
That has been dealt with in the N770 fortunately and the download 
happens on the background.

In Linux multithreading has similar overhead than having multiple
processes so because of that, in Linux the only gain from using 
multithreading
over separate processes is having the global data shared which requires
_proper_ synchronization. There are many ways to mess up a multithreaded 
application
to slow down or even lock because of wrong use of mutexes and it seems
to be common to use them in a wrong way so that the program at least
slows down. However, it is possible to use them in a way that the 
overhead is minimal
or at least insignificant. I have done several multithreaded 
applications in the past (allthough they were
not GUI applications but server application e.g. in network elements) and
unlike usually seems to be believed, doing multithreading and 
synchronization
is not so hard, the only thing which is hard after multithreading a 
program, is debugging
with a debugger - but who needs a debugger to debug? ;)
There are ways to improve threading performance by limiting the
amount of invoked threads and potentially starting them to a pool 
beforehands
and not starting and stopping them dynamically. Pools need to have queues of
work that is taken into the pool when a thread finishes some job. In user
interface threading helps when the user is doing something with some 
software
which invokes some action which takes a long time (long time means from
several seconds via several minutes to several hours - in a device like N770
it is rare that there would be tasks that take hours, but for example in 
desktop
computing world for example a 3D animation program can be an example where
it can be rendering a movie (which rendering can take from minutes to 
days) while the user can
continue editing the model, scene, etc. allthough many programs still don't
allow this, at least the version of 3dsmax I tried didn't allow a such 
thing). A dialog pops up and still
the user is able to continue his/her work. However, in our platform, the 
dialogs
are usually modal which takes away the benefit from multithreading in a 
situation
like that.

A situation when multithreading should be considered is usually a such where
otherwise would be needed to code some hack that kind of emulates the 
multithreading.
I have also seen programs like that, one was doing goto from place to 
another a weird
cycle around to kind of do things asynchronously even if they weren't. 
For that reason
transferring some hundred kilobytes of data took a much longer than it 
would have taken
if it would have been multithreaded and the scheduler would have done 
the time division
between the simultaneously running workers instead of emulating that 
inefficiently
and poorly and made maintaining the program a nightmare.

Best Regards,
Karoliina Salminen