Multicores

CASTalk.com
Discussion of DSP, FPGA, storage and embedded system.

FAQ

Memberlist

Profile

Multicores Goto page Previous 1, 2

CASTalk.com Forum Index -> Computer Architecture

Author

Message

Anne & Lynn Wheeler
Guest

Posted: Wed Sep 07, 2005 10:58 pm Post subject: Re: Multicores

"robertwessel2@yahoo.com" <robertwessel2@yahoo.com> writes:

Quote:

Windows, like pretty much any other OS, will dole out CPU time in
time-slice increments to threads that run CPU bound, but only rarely
does a thread (in most systems) ever run out a time slice before
blocking on some event (and thus threads are rarely CPU bound).

i had done dynamic adaptive scheduling back in the 60s as an
undergraduate. this was sometimes referred to as fairshare (or
wheeler) scheduler ... because the default scheduling policy
was fairshare

basically light-weight interactive tasks got shorter quanta than more
heavy-weight longer running tasks. advistory deadline was calculated
proportional to size of the quanta and the recent resource
utilization. quanta could span certain short i/os (disk, etc) ... so
heavy utilization wasn't necessary restricted to absolutely pure cpu
bound (just reasonably high rate of cpu consumption).

light-weight interactive tasks would tend to have more frequent quanta
with shorter deadlines ... and heavy weight tasks would have less
frequent larger quanta. interactive tasks would appear to be more
responsive if they could complete within a few of the shorter quanta
and/or if they haven't been using a lot of resources recently.
basically the objective was to uniformally control of the overall rate
of resource consumption (regardless of the quanta size).

the other issue was that this was done as modifications to existing
cp67 system that had an extremely complex scheduler that wasn't
directly controlling resource utilization ... just moving priorities
up & done and itself could consumer 10-15 percent of total cpu
utilization. so a major objective of the scheduler change was to not
only implement effective resource consumption supporting a variety of
scheduling policies ... but do it with as close as possible to zero
pathlength.
http://www.garlic.com/~lynn/subtopic.html#fairshare

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

robertwessel2@yahoo.com
Guest

Posted: Thu Sep 08, 2005 12:15 am Post subject: Re: Multicores

Jan Vorbrüggen wrote:

Quote:

Different versions of Windows use different time-slice intervals. And
there are some semi-documented ways that you can change that. Windows
takes considerable effort to keep the system responsive (CPU bound
threads get a priority reduction, foreground applications get a boost,
etc.), but in the presence of multiple CPU bound threads attached to
message queues (which is an application design problem), there's not a
whole lot you can do.

I have never seen this work properly in W2K...once you have one compute-
bound thread running, the GUI becomes totally unresponsive. Nextstep, now
that is another matter.

Jan Vorbrüggen
Guest

Posted: Thu Sep 08, 2005 8:15 am Post subject: Re: Multicores

Quote:

Well, if changing window focus takes up to ten seconds, or typing means
that you get your visual feedback several seconds later all in one batch,
is that slowing down or being unresponsive? There was this IBM study some
decades ago about response lags in the sub-second range having a big impact
on productivity...

Jan

JJ
Guest

Posted: Thu Sep 08, 2005 8:15 am Post subject: Re: Multicores

Jan Vorbrüggen wrote:

Quote:

Unless the thread is running at high priority, or is holding a lock on
message processing or some common GDI item, I've never seen a CPU bound
thread make the GUI "totally unresponsive" in the NT line of Windows.
Slow it down, sure.

Well, if changing window focus takes up to ten seconds, or typing means
that you get your visual feedback several seconds later all in one batch,
is that slowing down or being unresponsive? There was this IBM study some
decades ago about response lags in the sub-second range having a big impact
on productivity...

Jan

I see multi second lags all the time, its not just infuriating, its
hair pulling ...

I have 2 large monitors, an nVidia AGP and an oldish Banshee PCI card
both run at or near 2k pixels. Dragging almost any large window from
PCI to AGP, wait precisely 7 secs for the mess to clear up (even plain
text). The obvious solutions are unpalatable. I don't think multicores
will help much either.

I get the distinct feeling that the increased workload being asked of
W2K by the bloated office desktop SW is far beyond Moores law of so
called improvement. The only thing PCs generally actually deliver on is
the media delivery, VLC good example. But actually try to do more
mundane stuff on larger docs, and they bog down. I suspect its got alot
to do with the poor data locality and the memory wall at play against
everything that doesn't look like cache friendly media codecs. BeOS,
now that is another matter.

johnjakson at usa ...

Skybuck Flying
Guest

Posted: Thu Sep 08, 2005 4:15 pm Post subject: Re: Multicores

"Ken Hagan" <K.Hagan@thermoteknix.co.uk> wrote in message
news:dfjnm8$rr0$1$8300dec7@news.demon.co.uk...

Quote:

Skybuck Flying wrote:

I would want a dual core processor, I would even want a 1000 core
processor.

The reason is simply because then I as a programmer can start writing
*serious* multi threaded software which can take adventage of multi core
processors.

A nit pick...

You can write such software now. Your customers will need to
wait until they have such a processor before they will benefit
from it.

Until then, there is no advantage to parallel software, only
overheads and cost. That's why we aren't all doing it already.

Exactly, So chicking and egg problem.

We dont write multi threaded software because it's overhead.

They don't make paralleler hardware because there is no multi threaded
software lol.

Ofcourse that's a slighty exaggerated there is some multi threaded software
out there ;)

Bye,
Skybuck.

Skybuck Flying
Guest

Posted: Thu Sep 08, 2005 4:15 pm Post subject: Re: Multicores

<robertwessel2@yahoo.com> wrote in message
news:1126047657.641045.230820@g14g2000cwa.googlegroups.com...

Quote:

Skybuck Flying wrote:
robertwessel2@yahoo.com> wrote in message
news:1125731066.086811.73210@z14g2000cwz.googlegroups.com...

The number of context switches is not typically reduced in any
significant way by going to a dual (or multi-) CPU system. The vast
majority of context switches occur because a thread blocks or calls on
another thread or context for a service (really the same thing), and
those are *not* impacted by the number of CPUs in the system. Context
switches due to time slice expirations *can* be reduced by a multiple
CPU configuration, but only if the number of threads tends to be close
to the number of CPUs. If there are many runnable thread, and the
time
slice interval does not change, even that can be slower on the dual
processor system, since slices will occur after only half the number
of
instructions. In any event, time slice triggered context switches are
*very* rare. At best a few tens to a few hundred per second.

As far as I can tell windows xp doesn't care how many threads are
running,
it will simply give each thread the same ammount of time slice thereby
lagging the whole system.

Windows, like pretty much any other OS, will dole out CPU time in
time-slice increments to threads that run CPU bound, but only rarely
does a thread (in most systems) ever run out a time slice before
blocking on some event (and thus threads are rarely CPU bound).

That's why the number of contex switches doesn't
increase as the number of threads increase.

This is perhaps true for a collection of CPU bound threads, but the
vast majority of threads in a system are (typically) not.

Windows xp makes absolutely no
attempt to keep the system responsive. To keep the system responsive
windows
xp would need to shorten each time slice and thereby creating more
contex
switches thus leaving less processing power to do anything usefull.

Different versions of Windows use different time-slice intervals. And
there are some semi-documented ways that you can change that. Windows
takes considerable effort to keep the system responsive (CPU bound
threads get a priority reduction, foreground applications get a boost,
etc.), but in the presence of multiple CPU bound threads attached to
message queues (which is an application design problem), there's not a
whole lot you can do.

In short, time slice intervals have only a little to do with system
responsiveness.

That's where you are 100% wrong, it has everything to do with system
responsiveness.

1. Give an application a higher priority and it's threads will get a longer
time slice.
2. Give an application a lower priority and it's threads will get a shorter
time slice.

That's why 1. lags the system when an application gets to much time.
That's why 2. makes an application take very long to complete it's task.

Bye,
Skybuck.

Skybuck Flying
Guest

Posted: Thu Sep 08, 2005 4:15 pm Post subject: Re: Multicores

"Ken Hagan" <K.Hagan@thermoteknix.co.uk> wrote in message
news:dfjnm8$rr0$1$8300dec7@news.demon.co.uk...

Quote:

Anyway besides from my previous post I wanted to add a point but in my
enthousiastic look up of a difficult word I pressed the post button a little
bit too quickly lol... Though my point should be obvious from previous
threads.

The point is ofcourse that at some point in time all software will be multi
threaded/parallel because it's a natural way to get more performance.

Thus being a parallel processor now will be more suited to execute the
software of the future =D

That's gotta be worth something =D

Bye,
Skybuck.

robertwessel2@yahoo.com
Guest

Posted: Thu Sep 08, 2005 10:01 pm Post subject: Re: Multicores

Skybuck Flying wrote:

Quote:

In short, time slice intervals have only a little to do with system
responsiveness.

That's where you are 100% wrong, it has everything to do with system
responsiveness.

1. Give an application a higher priority and it's threads will get a longer
time slice.
2. Give an application a lower priority and it's threads will get a shorter
time slice.

That's why 1. lags the system when an application gets to much time.
That's why 2. makes an application take very long to complete it's task.

Of course that's not anything like the way it actually works. If two
threads, one high and one low priority, are ready to run, the high
priority thread will be dispatched, and time slices have nothing to do
with it. In the basic case a runnable high priority thread will
prevent all low priority threads from running, period. If two threads
of equal priority are both runnable, then, and only then, will time
slices come into play to switch between those equal priority threads.
That being said, many OSs will apply a dynamic temporary priority boost
to lower priority threads if they've not been allowed to run for an
extended period of time so that they're not starved of CPU time
completely. And there are, of course, more complex schedulers that
work not just on thread priority, but take into account system policies
that say things like "guarantee at least 15 % of the CPU to job#3."
Those often work by watching the run history and adjusting a more
traditional priority scheme to meet the goals.

Anne & Lynn Wheeler
Guest

Posted: Thu Sep 08, 2005 11:56 pm Post subject: Re: Multicores

"robertwessel2@yahoo.com" <robertwessel2@yahoo.com> writes:

Quote:

Of course that's not anything like the way it actually works. If
two threads, one high and one low priority, are ready to run, the
high priority thread will be dispatched, and time slices have
nothing to do with it. In the basic case a runnable high priority
thread will prevent all low priority threads from running, period.
If two threads of equal priority are both runnable, then, and only
then, will time slices come into play to switch between those equal
priority threads. That being said, many OSs will apply a dynamic
temporary priority boost to lower priority threads if they've not
been allowed to run for an extended period of time so that they're
not starved of CPU time completely. And there are, of course, more
complex schedulers that work not just on thread priority, but take
into account system policies that say things like "guarantee at
least 15 % of the CPU to job#3." Those often work by watching the
run history and adjusting a more traditional priority scheme to meet
the goals.

dynamic adaptive resource management that i was doing in the 60s as
undergraduate ... used advisory deadlines for dispatching/scheduling
(effectively based on size of quanta and the amount of resources the
task was getting relative to its target resources).

priorities were an aspect of scheduling policy ... default policy was
fair share and default priority mechanism adjusted a tasks relative
portion of fair share (translated into more or less than overall
infrastructure fair share).

evolution of that infrastructure were things like partitioning
resources among departments and then making individual fair share a
portion of the related departments allication ... as opposed to
overall total system resources.

one of the reasons for doing the change ... was to drastically reduce
the pathlength of the then available implementation which was starting
to take 10-15 percent of elapsed time ... and used a priority scheme
more like that outlined above. previous post
http://www.garlic.com/~lynn/2005p.html#21 Multicores

the code that i had done as undergraduate was eventually picked up and
shipped in the cp67 product. Much of the code was then dropped in the
morphing from cp67 to vm370. however it was re-introduced when i did
the resource manager for vm370.
http://www.garlic.com/~lynn/subtopic.html#fairshare

one of the other distinctions of the resource manager was that it was
chosen to be the guinea pig for licensed/priced kernel software.

with the 6/23/69 unbundling announcement (large part motivated by
various litigation activities), there was a switch to start
charging/licensing application softwoare ... although kernel software
still was free.
http://www.garlic.com/~lynn/subtopic.html#unbundle

the resource manager got tapped to be priced/licensed kernel software.
I got the reward to spend time over period of several months with
various business groups working out the changes for pricing for kernel
software. the guidelines established with the resource manager was
that kernel software not directly involved with hardware support (like
device drivers) would still be free ... but other kernel software
could be priced separately.

this caused a problem for the next base kernel release where they were
going to ship SMP support (something else that didn't make the
transition from cp67 to vm370 ... even tho all the invention leading
up to the compare and swap instruction had been done on cp67). I had
includes a bunch of stuff in the resource manager that SMP support
needed. However the pricing policy wa that SMP support had to be free
(aka hardware support) ... so it was a violation of the policy with
you had to buy the resource manager in order for SMP support to work.
Eventually they moved stuff required by SMP support out of the
licensed/priced resource manager into the base (free) kernel.
http://www.garlic.com/~lynn/subtopic.html#smp

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

robertwessel2@yahoo.com
Guest

Posted: Fri Sep 09, 2005 12:15 am Post subject: Re: Multicores

Skybuck Flying wrote:

Quote:

Of course that's not anything like the way it actually works.

You are again 100% wrong. What I described above is *exactly* what happens.

The threads of the high priority application will get longer time slices.
The threads of the low priority application will get shorter time slices.

What you describe below is what happens inside a single application.

What I described above is what happens when multiple applications are
running.

See the difference ?

Some OS's schedule processes and then threads with processes, other
just schedule all the threads in the system (eg. Linux, Windows). Even
those with two level schemes don't generally do what you describe.
About the only CPUs that implement anything like you describe are the
ones that support CPU utilization policies, and even then the
adjustment is really happening between threads of essentially equal
priority.

*sigh* You are simply uneducable, aren't you?

Skybuck Flying
Guest

Posted: Fri Sep 09, 2005 12:15 am Post subject: Re: Multicores

<robertwessel2@yahoo.com> wrote in message
news:1126195798.401745.156050@g49g2000cwa.googlegroups.com...

Quote:

Skybuck Flying wrote:
In short, time slice intervals have only a little to do with system
responsiveness.

That's where you are 100% wrong, it has everything to do with system
responsiveness.

1. Give an application a higher priority and it's threads will get a
longer
time slice.
2. Give an application a lower priority and it's threads will get a
shorter
time slice.

That's why 1. lags the system when an application gets to much time.
That's why 2. makes an application take very long to complete it's task.

Of course that's not anything like the way it actually works.

You are again 100% wrong. What I described above is *exactly* what happens.

The threads of the high priority application will get longer time slices.
The threads of the low priority application will get shorter time slices.

What you describe below is what happens inside a single application.

What I described above is what happens when multiple applications are
running.

See the difference ?

Bye,
Skybuck.

Quote:

If two
threads, one high and one low priority, are ready to run, the high
priority thread will be dispatched, and time slices have nothing to do
with it. In the basic case a runnable high priority thread will
prevent all low priority threads from running, period. If two threads
of equal priority are both runnable, then, and only then, will time
slices come into play to switch between those equal priority threads.
That being said, many OSs will apply a dynamic temporary priority boost
to lower priority threads if they've not been allowed to run for an
extended period of time so that they're not starved of CPU time
completely. And there are, of course, more complex schedulers that
work not just on thread priority, but take into account system policies
that say things like "guarantee at least 15 % of the CPU to job#3."
Those often work by watching the run history and adjusting a more
traditional priority scheme to meet the goals.

Jeremy Linton
Guest

Posted: Fri Sep 09, 2005 12:15 am Post subject: Re: Multicores

Quote:

I have 2 large monitors, an nVidia AGP and an oldish Banshee PCI card
both run at or near 2k pixels. Dragging almost any large window from
PCI to AGP, wait precisely 7 secs for the mess to clear up (even plain
text). The obvious solutions are unpalatable. I don't think multicores
will help much either.

I've used a lot of dual head (or more) windows boxes with diffrent
configuration. I've seen similar problems before, and its not windows.
It was something in the video card drivers. Updating drivers has cleared
up the problem, and in the case of ATI making sure that there isn't more
than 1 ATI in the machine seems to help.

Skybuck Flying
Guest

Posted: Fri Sep 09, 2005 5:26 am Post subject: Re: Multicores

<robertwessel2@yahoo.com> wrote in message
news:1126223265.310158.20350@g44g2000cwa.googlegroups.com...

Quote:

Skybuck Flying wrote:
Of course that's not anything like the way it actually works.

You are again 100% wrong. What I described above is *exactly* what
happens.

The threads of the high priority application will get longer time
slices.
The threads of the low priority application will get shorter time
slices.

What you describe below is what happens inside a single application.

What I described above is what happens when multiple applications are
running.

See the difference ?

Some OS's schedule processes and then threads with processes, other
just schedule all the threads in the system (eg. Linux, Windows). Even
those with two level schemes don't generally do what you describe.
About the only CPUs that implement anything like you describe are the
ones that support CPU utilization policies, and even then the
adjustment is really happening between threads of essentially equal
priority.

*sigh* You are simply uneducable, aren't you?

See my other post ;)

Bye,
Skybuck =D

Emanual Kann
Guest

Posted: Sun Oct 30, 2005 9:15 am Post subject: Re: Multicores

On Fri, 02 Sep 2005 17:44:16 -0500, nutjob repukelican, Randy wrote:

Quote:

Raven8712 wrote:
Does anyone have any thoughts on whether dual processors are worth
building into a home computer or not?

- Raven

Yes. No.

Randy

Yes. Yes.

	CASTalk.com Forum Index -> Computer Architecture	All times are GMT Goto page Previous 1, 2
Page 2 of 2

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum