From: Marcin Rodzik on
Hello,

I'm trying to optimize my program. The basic idea of it is that it
consists of a few separate threads each of which performs another
operation on an object. The objects which are undergone these
operations are passed over from one thread to another. Operations on
each object are performed sequentially, however, all the threads work
concurrently. This is because some operations need additional
resources (one of threads simply sends data over the network, another
receives some data).

Now I'd like to know which thread is the most computation-intensive,
i.e. which takes the most of the CPU time. Is there any simple way to
check this? What I came up with is re-writing the program so that one
thread is used and simply check the time each operation takes with
double invocation of Calendar.getInstance().getTimeInMillis().
However, it's not so easy. Moreover, I'd like to check the time in a
"real environment", it means that I want to include the time the
threads are blocked waiting for I/O and so on.

Another question which is not clear to me: What really happens when a
thread waits for incoming data e.g. from a socket? To what extent can
the other threads use the CPU?

MR
From: Tom Anderson on
On Mon, 21 Jun 2010, Marcin Rodzik wrote:

> I'm trying to optimize my program. The basic idea of it is that it
> consists of a few separate threads each of which performs another
> operation on an object. The objects which are undergone these operations
> are passed over from one thread to another. Operations on each object
> are performed sequentially, however, all the threads work concurrently.

So each thread performs a set of operations disjoint from those of the
other threads?

> Now I'd like to know which thread is the most computation-intensive,
> i.e. which takes the most of the CPU time. Is there any simple way to
> check this?

A normal profiler will tell you which methods consume the most time. If
you know which threads run which methods, you can fairly easily work out
which threads consume the most time.

> What I came up with is re-writing the program so that one thread is used
> and simply check the time each operation takes with double invocation of
> Calendar.getInstance().getTimeInMillis().

I think you mean System.nanoTime().

> However, it's not so easy. Moreover, I'd like to check the time in a
> "real environment",

If your real environment is linux, run top and use the H command to list
threads. That will let you see which are using the most CPU time. What top
doesn't do (AFAIK) is let you record statistics over time to do a proper
analysis later. There are other tools for that, but you'd have to ask on a
sysadmin group.

Similar things probably exist for Windows, but i don't know the first
thing about that. Except that it has pinball!

> it means that I want to include the time the threads are blocked waiting
> for I/O and so on.
>
> Another question which is not clear to me: What really happens when a
> thread waits for incoming data e.g. from a socket? To what extent can
> the other threads use the CPU?

A very great extent. When a thread is waiting - for IO, to acquire a lock,
for a page of memory to be brought in from virtual memory on disk (which
is really IO by another name) - it isn't doing anything at all. The OS
essentially puts it to sleep, or freezes it in time, or however you want
to think of it. There's some overhead to freezing it, and some overhead to
thawing it out again, and it uses the same amount of memory when frozen as
when running, but it doesn't use CPU time between being put in the
carbonite and being broken out again.

Which means if you're concerned about getting the most work out of your
processor, you *don't* want to include the time they're blocked for IO.

You will want to know about it for a more complete picture of your
system, though. On many unix systems, the iostat tool will give you a
system-level picture of how much time is being spent waiting for IO. I
don't know (a) how to do it at the thread level or (b) how to do it on
non-unix platforms.

Bear in mind that in the time a thread is waiting for IO, another thread
or threads are typically running. That means it's a double-edged sword; as
long as you have enough computational work to do, the fact that some
threads spend a lot of time waiting for IO may not matter much.

tom

--
No hay banda
From: Roedy Green on
On Mon, 21 Jun 2010 13:12:09 -0700 (PDT), Marcin Rodzik
<marteno_rodia(a)o2.pl> wrote, quoted or indirectly quoted someone who
said :

>
>Another question which is not clear to me: What really happens when a
>thread waits for incoming data e.g. from a socket? To what extent can
>the other threads use the CPU?

see http://mindprod.com/jgloss/profiler.html
for tools you can use. You don't have to create them from scratch.
--
Roedy Green Canadian Mind Products
http://mindprod.com

There is no harm in being sometimes wrong especially if one is promptly found out.
~ John Maynard Keynes (born: 1883-06-05 died: 1946-04-21 at age: 62)