Antti P Miettinen wrote:
Jose Manrique Lopez de la Fuente <[EMAIL PROTECTED]> 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
_______________________________________________
maemo-developers mailing list
[email protected]
https://maemo.org/mailman/listinfo/maemo-developers
