Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #4284 > unrolled thread
| Started by | timcaffrey@aol.com (Tim McCaffrey) |
|---|---|
| First post | 2011-10-20 19:51 +0000 |
| Last post | 2011-10-26 14:12 -0700 |
| Articles | 15 on this page of 175 — 34 participants |
Back to article view | Back to comp.arch
big-little timcaffrey@aol.com (Tim McCaffrey) - 2011-10-20 19:51 +0000
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-20 22:35 +0200
Re: big-little Mark Thorson <nospam@sonic.net> - 2011-10-20 14:18 -0800
Re: big-little nmm1@cam.ac.uk - 2011-10-21 07:54 +0100
Re: big-little David Kanter <dkanter@gmail.com> - 2011-11-09 01:06 -0800
Re: big-little nmm1@cam.ac.uk - 2011-11-09 11:07 +0000
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-21 09:25 +0200
Re: big-little EricP <ThatWouldBeTelling@thevillage.com> - 2011-10-21 11:07 -0400
Re: big-little timcaffrey@aol.com (Tim McCaffrey) - 2011-10-21 16:28 +0000
Re: big-little nmm1@cam.ac.uk - 2011-10-21 17:07 +0100
Re: big-little EricP <ThatWouldBeTelling@thevillage.com> - 2011-10-21 13:25 -0400
Re: big-little timcaffrey@aol.com (Tim McCaffrey) - 2011-10-21 19:45 +0000
Re: big-little EricP <ThatWouldBeTelling@thevillage.com> - 2011-10-22 14:44 -0400
Re: big-little ChrisQ <meru@devnull.com> - 2011-10-22 16:57 +0000
Re: big-little nmm1@cam.ac.uk - 2011-10-22 17:40 +0100
Re: big-little ChrisQ <meru@devnull.com> - 2011-10-23 14:39 +0000
Re: big-little nmm1@cam.ac.uk - 2011-10-23 16:11 +0100
Re: big-little ChrisQ <meru@devnull.com> - 2011-10-23 17:44 +0000
Re: big-little nmm1@cam.ac.uk - 2011-10-23 18:46 +0100
Re: big-little Thomas Womack <twomack@chiark.greenend.org.uk> - 2011-10-23 19:30 +0100
Re: big-little nmm1@cam.ac.uk - 2011-10-23 19:59 +0100
Re: big-little BGB <cr88192@hotmail.com> - 2011-10-23 13:21 -0700
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-23 20:38 +0200
Re: big-little nmm1@cam.ac.uk - 2011-10-23 22:38 +0100
Re: big-little BGB <cr88192@hotmail.com> - 2011-10-23 17:56 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-24 07:58 +0100
Re: big-little BGB <cr88192@hotmail.com> - 2011-10-24 16:34 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-25 08:09 +0100
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-25 14:52 +0200
Re: big-little nmm1@cam.ac.uk - 2011-10-25 17:28 +0100
Re: big-little BGB <cr88192@hotmail.com> - 2011-10-25 13:06 -0700
Re: big-little BGB <cr88192@hotmail.com> - 2011-10-25 15:22 -0700
Re: big-little "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-10-25 19:47 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-26 08:09 +0100
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-26 12:06 +0200
Re: big-little nmm1@cam.ac.uk - 2011-10-26 10:47 +0100
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-26 11:58 +0200
Re: big-little nmm1@cam.ac.uk - 2011-10-26 10:44 +0100
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-26 03:45 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-26 11:45 +0100
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-26 09:15 -0700
Re: big-little "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-10-26 12:51 -0700
Re: big-little Andrew Reilly <areilly---@bigpond.net.au> - 2011-10-26 11:45 +0000
Re: big-little nmm1@cam.ac.uk - 2011-10-26 15:42 +0100
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-26 09:07 -0700
Re: big-little "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-10-26 12:53 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-26 21:05 +0100
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-26 13:20 -0700
Re: big-little "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-10-26 17:55 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-27 09:10 +0100
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-27 01:34 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-27 10:29 +0100
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-27 04:28 -0700
Re: big-little EricP <ThatWouldBeTelling@thevillage.com> - 2011-10-27 12:22 -0400
Re: big-little timcaffrey@aol.com (Tim McCaffrey) - 2011-10-27 18:08 +0000
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-27 11:50 -0700
Re: big-little Jean-Marc Bourguet <jm@bourguet.org> - 2011-10-27 14:10 +0200
Re: big-little nmm1@cam.ac.uk - 2011-10-27 17:58 +0100
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-26 13:15 -0700
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-27 04:10 -0700
Re: big-little MitchAlsup <MitchAlsup@aol.com> - 2011-10-27 14:04 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-27 23:07 +0100
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-27 15:58 -0700
Re: big-little Rick Jones <rick.jones2@hp.com> - 2011-10-27 22:57 +0000
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-27 16:39 -0700
Re: big-little Rick Jones <rick.jones2@hp.com> - 2011-10-28 00:16 +0000
Re: big-little nmm1@cam.ac.uk - 2011-10-28 09:52 +0100
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-28 07:01 -0700
Re: big-little Rick Jones <rick.jones2@hp.com> - 2011-10-28 16:45 +0000
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-29 13:13 -0700
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-30 03:36 -0700
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-30 03:55 -0700
Re: big-little MitchAlsup <MitchAlsup@aol.com> - 2011-10-28 11:15 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-28 20:01 +0100
Re: big-little timcaffrey@aol.com (Tim McCaffrey) - 2011-10-29 17:46 +0000
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-29 11:30 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-29 20:02 +0100
Re: big-little MitchAlsup <MitchAlsup@aol.com> - 2011-10-29 13:09 -0700
Re: big-little "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-10-29 17:42 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-30 08:16 +0000
Re: big-little MitchAlsup <MitchAlsup@aol.com> - 2011-11-04 10:06 -0700
Re: big-little "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-11-04 15:19 -0700
Re: big-little nmm1@cam.ac.uk - 2011-11-05 09:13 +0000
Re: big-little "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-11-05 09:03 -0700
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-26 13:38 -0700
Re: big-little Robert Wessel <robertwessel2@yahoo.com> - 2011-10-26 18:44 -0500
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-26 17:05 -0700
Re: big-little Robert Wessel <robertwessel2@yahoo.com> - 2011-10-26 21:03 -0500
Re: big-little EricP <ThatWouldBeTelling@thevillage.com> - 2011-10-26 14:37 -0400
Re: big-little EricP <ThatWouldBeTelling@thevillage.com> - 2011-10-26 15:38 -0400
Re: big-little EricP <ThatWouldBeTelling@thevillage.com> - 2011-10-26 16:06 -0400
Re: big-little BGB <cr88192@hotmail.com> - 2011-10-27 00:15 -0700
Re: big-little Morten Reistad <first@last.name> - 2011-11-03 17:30 +0100
Re: big-little "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-11-03 20:45 -0700
Re: big-little Thomas Womack <twomack@chiark.greenend.org.uk> - 2011-11-04 11:13 +0000
Re: big-little MitchAlsup <MitchAlsup@aol.com> - 2011-11-04 10:12 -0700
Re: big-little BGB <cr88192@hotmail.com> - 2011-11-04 09:26 -0700
Re: big-little EricP <ThatWouldBeTelling@thevillage.com> - 2011-11-05 11:32 -0400
Re: big-little EricP <ThatWouldBeTelling@thevillage.com> - 2011-11-05 11:55 -0400
Re: big-little BGB <cr88192@hotmail.com> - 2011-11-05 09:58 -0700
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-11-05 18:39 +0100
Re: big-little BGB <cr88192@hotmail.com> - 2011-11-05 15:00 -0700
Re: big-little wclodius@lost-alamos.pet (William Clodius) - 2011-11-05 18:43 -0600
Re: big-little BGB <cr88192@hotmail.com> - 2011-11-05 19:46 -0700
Re: big-little ChrisQ <meru@devnull.com> - 2011-11-11 12:31 +0000
Re: big-little BGB <cr88192@hotmail.com> - 2011-11-11 12:39 -0700
Re: big-little Chris Gray <cg@GraySage.com> - 2011-11-11 13:28 -0700
Re: big-little BGB <cr88192@hotmail.com> - 2011-11-11 18:03 -0700
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-11-12 18:25 +0100
Re: big-little BGB <cr88192@hotmail.com> - 2011-11-12 12:02 -0700
cost of prolog/epilog (was: big-little) Kalle Olavi Niemitalo <kon@iki.fi> - 2011-11-12 22:57 +0200
Re: cost of prolog/epilog Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-11-12 22:47 +0100
Re: cost of prolog/epilog anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-11-14 09:45 +0000
Re: cost of prolog/epilog Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-11-14 12:28 +0100
Re: cost of prolog/epilog anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-11-15 16:48 +0000
Re: cost of prolog/epilog Stefan Monnier <monnier@iro.umontreal.ca> - 2011-11-15 21:35 -0500
Re: cost of prolog/epilog Bakul Shah <usenet@bitblocks.com> - 2011-11-16 02:41 -0800
Re: cost of prolog/epilog nmm1@cam.ac.uk - 2011-11-16 18:14 +0000
Re: cost of prolog/epilog BGB <cr88192@hotmail.com> - 2011-11-16 16:50 -0700
Re: cost of prolog/epilog BGB <cr88192@hotmail.com> - 2011-11-14 17:00 -0700
Re: cost of prolog/epilog torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-11-15 10:26 +0100
Re: cost of prolog/epilog BGB <cr88192@hotmail.com> - 2011-11-15 09:41 -0700
Re: cost of prolog/epilog anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-11-15 16:40 +0000
Re: cost of prolog/epilog Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-11-15 12:44 +0100
Re: cost of prolog/epilog BGB <cr88192@hotmail.com> - 2011-11-15 09:01 -0700
Re: cost of prolog/epilog Chris Gray <cg@GraySage.com> - 2011-11-15 15:18 -0700
Re: cost of prolog/epilog BGB <cr88192@hotmail.com> - 2011-11-15 21:56 -0700
Re: cost of prolog/epilog Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-11-16 09:21 +0100
Re: cost of prolog/epilog anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-11-16 09:30 +0000
Re: cost of prolog/epilog John Levine <johnl@iecc.com> - 2011-11-16 10:05 +0000
Re: cost of prolog/epilog Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-11-16 11:08 +0100
Re: cost of prolog/epilog Chris Gray <cg@GraySage.com> - 2011-11-16 16:29 -0700
Re: cost of prolog/epilog BGB <cr88192@hotmail.com> - 2011-11-16 11:22 -0700
Re: cost of prolog/epilog anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-11-17 13:27 +0000
Re: cost of prolog/epilog BGB <cr88192@hotmail.com> - 2011-11-17 10:30 -0700
Re: cost of prolog/epilog torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-11-17 11:21 +0100
Re: cost of prolog/epilog Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-11-17 11:56 +0100
Re: cost of prolog/epilog timcaffrey@aol.com (Tim McCaffrey) - 2011-11-17 20:27 +0000
Re: cost of prolog/epilog torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-11-18 10:57 +0100
Re: cost of prolog/epilog BGB <cr88192@hotmail.com> - 2011-11-17 10:42 -0700
Re: cost of prolog/epilog (was: big-little) "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-11-12 14:05 -0800
Re: cost of prolog/epilog (was: big-little) Bernd Paysan <bernd.paysan@gmx.de> - 2011-11-18 02:39 +0100
Re: cost of prolog/epilog torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-11-18 10:59 +0100
Re: cost of prolog/epilog Bernd Paysan <bernd.paysan@gmx.de> - 2011-11-18 22:06 +0100
Re: cost of prolog/epilog (was: big-little) mac <acolvin@efunct.com> - 2011-11-20 23:01 +0000
Re: cost of prolog/epilog Chris Gray <cg@GraySage.com> - 2011-11-13 13:35 -0700
Re: big-little wclodius@lost-alamos.pet (William Clodius) - 2011-11-11 22:13 -0700
Re: big-little BGB <cr88192@hotmail.com> - 2011-11-11 23:43 -0700
Re: big-little Chris Gray <cg@GraySage.com> - 2011-11-12 14:08 -0700
Re: big-little BGB <cr88192@hotmail.com> - 2011-11-12 19:10 -0700
Re: big-little Chris Gray <cg@GraySage.com> - 2011-11-13 13:40 -0700
Re: big-little Bakul Shah <usenet@bitblocks.com> - 2011-11-13 14:49 -0800
Re: big-little BGB <cr88192@hotmail.com> - 2011-11-13 18:51 -0700
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-24 10:12 +0200
Re: big-little Stefan Monnier <monnier@iro.umontreal.ca> - 2011-10-24 12:11 -0400
Re: big-little "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-10-24 10:28 -0700
Re: big-little nospam@ab-katrinedal.dk (Niels Jørgen Kruse) - 2011-10-24 19:38 +0200
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-24 21:02 +0200
Re: big-little "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-10-23 12:02 -0700
Re: big-little Morten Reistad <first@last.name> - 2011-11-03 00:51 +0100
Re: big-little "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-10-20 16:59 -0700
Re: big-little Anne & Lynn Wheeler <lynn@garlic.com> - 2011-10-20 21:13 -0400
Re: big-little nmm1@cam.ac.uk - 2011-10-21 08:01 +0100
Re: big-little "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-10-21 05:39 -0700
Re: big-little torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-10-24 10:18 +0200
Re: big-little Pedro Pereira <ppereira@grupopie.com> - 2011-10-21 10:40 +0100
Re: big-little Paul Gotch <paulg@at-cantab-dot.net> - 2011-10-21 12:42 +0100
Re: big-little nik Simpson <nik_s@knology.net> - 2011-10-21 11:00 -0500
Re: big-little Rick Jones <rick.jones2@hp.com> - 2011-10-20 21:13 +0000
Re: big-little timcaffrey@aol.com (Tim McCaffrey) - 2011-10-20 21:43 +0000
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-21 09:23 +0200
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-21 14:35 +0200
Re: big-little Rick Jones <rick.jones2@hp.com> - 2011-10-21 17:15 +0000
Re: big-little BGB <cr88192@hotmail.com> - 2011-10-21 16:41 -0700
Re: big-little jacko <jackokring@gmail.com> - 2011-10-26 14:12 -0700
Page 9 of 9 — ← Prev page 1 2 3 4 5 6 7 8 [9]
| From | "Paul A. Clayton" <paaronclayton@gmail.com> |
|---|---|
| Date | 2011-10-20 16:59 -0700 |
| Message-ID | <e30e404d-781f-4f60-87c1-df344dbc0a56@c25g2000yqn.googlegroups.com> |
| In reply to | #4285 |
On Oct 20, 3:35 pm, Terje Mathisen <"terje.mathisen at tmsw.no">
wrote:
[snip]
> We've discussed this several times, my stand is and has been that some
> form of asymmetric multiprocessing will turn up, but for x86 MS is
> probably the main impediment.
ARM is getting around this somewhat by using the DVFS interface
(power saving modes, I assume) to trigger migration. In this
configuration, it is similar to NVIDIA's "Companion Core".
(ARM has indicated that implementers would be able to expose
the extra core to the OS.)
> I.e. even if Linux will happily tweak it's scheduler to do core-affine
> mapping of os threads, MS might not be quite as willing to modify Windows.
As noted, using a simple core to handle interrupts could have
significant advantages: a simple core could probably wake-up
faster and with less energy use and would be more efficient for
code with less predictable branches and relatively frequent
reads and writes to I/O devices. Multithreading could enhance
the efficiency for such tasks even more.
Interestingly, I ran across a paper ("Multicore Performance
Optimization Using Partner Cores") that proposes using simple
cores to handle dynamic optimization (based on the abstract--I
have not yet read the paper even though it is only 9 pages long).
I also recently downloaded "Vote the OS off your Core" (also
from MIT) that seems to be indicating that OS activity should
be on a separate core ("best to run the OS close, but not too
close"). There is too much interesting-sounding research
being done (and I read too slowly and am too easily
distracted)!
[toc] | [prev] | [next] | [standalone]
| From | Anne & Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2011-10-20 21:13 -0400 |
| Message-ID | <m3pqhrf8pe.fsf@garlic.com> |
| In reply to | #4292 |
"Paul A. Clayton" <paaronclayton@gmail.com> writes: > As noted, using a simple core to handle interrupts could have > significant advantages: a simple core could probably wake-up > faster and with less energy use and would be more efficient for > code with less predictable branches and relatively frequent > reads and writes to I/O devices. Multithreading could enhance > the efficiency for such tasks even more. big mainframes found that taking asynchronous interrupts (and task switching) played havoc with cache hit ratios. also as disks were becoming more and more of bottleneck ... large complex operating systems had long pathlengths between asynchronous interrupts and latency before redriving device with next queued i/o ... was becoming significant factor in improving thruput. 811 architecture (for nov78) that showed up in the early 80s with 3081 ... provided for queued i/o redrive ... handled by dedicated hardware w/o requiring operating system (removing device redrive latency). in the late 70s, i did software rewrite of interrupt handler and device handling to come very close to redrive latency of dedicated hardware ... but that didn't alleviate the cache hit problem related to asynchronous interrupts. earlier in the mid-70s ... related to cache hit ratio and multiprocessor support ... i created mechanism that under high interrupts rate would switch to blocking asynchronous interrupts and peridically polling. the delays somewhat reduced i/o thruput ... but slightly delaying interrupts and then batch polling of all delayed/pending interrupts actually improved overall thruput ... because of the cache hit ratio of "batch" processing of the pending interrupts. -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-10-21 08:01 +0100 |
| Message-ID | <j7r5c9$7bv$1@gosset.csi.cam.ac.uk> |
| In reply to | #4292 |
In article <e30e404d-781f-4f60-87c1-df344dbc0a56@c25g2000yqn.googlegroups.com>, Paul A. Clayton <paaronclayton@gmail.com> wrote: > >As noted, using a simple core to handle interrupts could have >significant advantages: a simple core could probably wake-up >faster and with less energy use and would be more efficient for >code with less predictable branches and relatively frequent >reads and writes to I/O devices. Multithreading could enhance >the efficiency for such tasks even more. I can't remember when I started suggesting that it was the obvious strategy, but it was a good decade ago and I probably wasn't the first (as I regard it as very obvious). I might even live to see it happen, unlike most of my other ideas in this area :-) As I have posted, you can take that to the limit and design an interrupt-free architecture based on dedicated threads, queues and polling. Strictly, that would be free only of trap-recover- and-continue, and would still have trap-diagnose-and-terminate but, as everyone with experience knows, the latter is a hundred times easier to get right and efficient than the former. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | "Paul A. Clayton" <paaronclayton@gmail.com> |
|---|---|
| Date | 2011-10-21 05:39 -0700 |
| Message-ID | <bf1c0179-a8d6-4e1f-ae8e-eb1c38283e34@m4g2000yqm.googlegroups.com> |
| In reply to | #4300 |
On Oct 21, 2:01 am, n...@cam.ac.uk wrote: [snip] > I can't remember when I started suggesting that it was the obvious > strategy, but it was a good decade ago and I probably wasn't the > first (as I regard it as very obvious). I might even live to see > it happen, unlike most of my other ideas in this area :-) In a *very* limited sense you have: the earlier SPARC T series processors had short pipelines and multithreading; they just lacked the high performance application cores to sit along side them. :-) Also, as mentioned by Pedro Pereira and Paul Gotch, some embedded chips use a simple microcontroller core (or two [e.g., ARM Cortex-M series]) and an application core (or two [e.g., ARM Cortex-A series]) for similar offloading.
[toc] | [prev] | [next] | [standalone]
| From | torbenm@diku.dk (Torben Ægidius Mogensen) |
|---|---|
| Date | 2011-10-24 10:18 +0200 |
| Message-ID | <7z39ei950l.fsf@ask.diku.dk> |
| In reply to | #4300 |
nmm1@cam.ac.uk writes: > In article <e30e404d-781f-4f60-87c1-df344dbc0a56@c25g2000yqn.googlegroups.com>, > Paul A. Clayton <paaronclayton@gmail.com> wrote: >> >>As noted, using a simple core to handle interrupts could have >>significant advantages: a simple core could probably wake-up >>faster and with less energy use and would be more efficient for >>code with less predictable branches and relatively frequent >>reads and writes to I/O devices. > > I can't remember when I started suggesting that it was the obvious > strategy, but it was a good decade ago and I probably wasn't the > first (as I regard it as very obvious). Though not on a single chip, the idea was present in the BBC micro: You could add a second processor and let the first handle all i/o, graphics and so on, so the second processor would be almost purely for compute tasks. Torben
[toc] | [prev] | [next] | [standalone]
| From | Pedro Pereira <ppereira@grupopie.com> |
|---|---|
| Date | 2011-10-21 10:40 +0100 |
| Message-ID | <j7ren5$9p8$1@speranza.aioe.org> |
| In reply to | #4292 |
Some ARM processors have tiny companion cores for interrupt handling and soft-peripherals. The Texas AM1705, for example, have two cores (not ARM) with an Harvard load-store and in-order architecture with deterministic timing. They typically run at half the frequency of the main core and have very little code (4KB) and data spaces (512 bytes). For embedded devices this is great. See for example: http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit_Subsystem Pedro Pereira
[toc] | [prev] | [next] | [standalone]
| From | Paul Gotch <paulg@at-cantab-dot.net> |
|---|---|
| Date | 2011-10-21 12:42 +0100 |
| Message-ID | <Woz*JAfQt@news.chiark.greenend.org.uk> |
| In reply to | #4302 |
Pedro Pereira <ppereira@grupopie.com> wrote: > Some ARM processors have tiny companion cores for interrupt handling > and soft-peripherals. Many honking big A class things also have an M profile core in the corner of the SoC acting as a system management processor. -p -- Paul Gotch --------------------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | nik Simpson <nik_s@knology.net> |
|---|---|
| Date | 2011-10-21 11:00 -0500 |
| Message-ID | <c321c$4ea19740$182aedb1$21821@KNOLOGY.NET> |
| In reply to | #4285 |
On 10/20/2011 3:35 PM, Terje Mathisen wrote: > We've discussed this several times, my stand is and has been that some > form of asymmetric multiprocessing will turn up, but for x86 MS is > probably the main impediment. > > I.e. even if Linux will happily tweak it's scheduler to do core-affine > mapping of os threads, MS might not be quite as willing to modify Windows. > Well, the scheduler in W8 has been optimized to give Bulldozer a fighting chance, so it's not out of the question. Also since the main reason for doing this is to optimize power consumption on laptop/tablet type devices, MS would have to be insane to turn it's nose up. -- Nik Simpson
[toc] | [prev] | [next] | [standalone]
| From | Rick Jones <rick.jones2@hp.com> |
|---|---|
| Date | 2011-10-20 21:13 +0000 |
| Message-ID | <j7q2tk$9ak$1@usenet01.boi.hp.com> |
| In reply to | #4284 |
Tim McCaffrey <timcaffrey@aol.com> wrote:
> It might even make sense to let the low power processor always
> handle interrupts,
"Networking" at least is rather fond of good interrupt service
performance. Particularly in low-latency situations.
rick jones
--
denial, anger, bargaining, depression, acceptance, rebirth...
where do you want to be today?
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
[toc] | [prev] | [next] | [standalone]
| From | timcaffrey@aol.com (Tim McCaffrey) |
|---|---|
| Date | 2011-10-20 21:43 +0000 |
| Message-ID | <j7q4mn$pfs$1@USTR-NEWS.TR.UNISYS.COM> |
| In reply to | #4287 |
In article <j7q2tk$9ak$1@usenet01.boi.hp.com>, rick.jones2@hp.com says... > >Tim McCaffrey <timcaffrey@aol.com> wrote: >> It might even make sense to let the low power processor always >> handle interrupts, > >"Networking" at least is rather fond of good interrupt service >performance. Particularly in low-latency situations. > Yes, I agree. If you can avoid the task gate switch overhead you can save 1000s of cycles, which may more than offset the slightly reduced performance. - Tim (you don't know if it'll work until you try it).
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <"terje.mathisen at tmsw.no"> |
|---|---|
| Date | 2011-10-21 09:23 +0200 |
| Message-ID | <q8j7n8-3ra.ln1@ntp6.tmsw.no> |
| In reply to | #4287 |
Rick Jones wrote: > Tim McCaffrey<timcaffrey@aol.com> wrote: >> It might even make sense to let the low power processor always >> handle interrupts, > > "Networking" at least is rather fond of good interrupt service > performance. Particularly in low-latency situations. An in-order (Pentium-style) core running at 50% the main frequency has significantly less context, it is quite possible that it could handle interrupts just as well as (or even better than) the faster OoO cores. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <"terje.mathisen at tmsw.no"> |
|---|---|
| Date | 2011-10-21 14:35 +0200 |
| Message-ID | <th58n8-sgb.ln1@ntp6.tmsw.no> |
| In reply to | #4299 |
Terje Mathisen wrote: > Rick Jones wrote: >> Tim McCaffrey<timcaffrey@aol.com> wrote: >>> It might even make sense to let the low power processor always >>> handle interrupts, >> >> "Networking" at least is rather fond of good interrupt service >> performance. Particularly in low-latency situations. > > An in-order (Pentium-style) core running at 50% the main frequency has > significantly less context, it is quite possible that it could handle > interrupts just as well as (or even better than) the faster OoO cores. Since writing that I took a look at some of the big.LITTLE (yes, they really want us to call it that!) ARM info: The little core is in fact very similar to the original Pentium, with a single in-order pipeline with single/dual issue of instructions. The big core otoh look a lot more like a Pentium Pro. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Rick Jones <rick.jones2@hp.com> |
|---|---|
| Date | 2011-10-21 17:15 +0000 |
| Message-ID | <j7s9an$8d5$1@usenet01.boi.hp.com> |
| In reply to | #4305 |
Terje Mathisen <"terje.mathisen at tmsw.no"> wrote: > Terje Mathisen wrote: > > Rick Jones wrote: > >> Tim McCaffrey<timcaffrey@aol.com> wrote: > >>> It might even make sense to let the low power processor always > >>> handle interrupts, > >> > >> "Networking" at least is rather fond of good interrupt service > >> performance. Particularly in low-latency situations. > > > > An in-order (Pentium-style) core running at 50% the main frequency > > has significantly less context, it is quite possible that it could > > handle interrupts just as well as (or even better than) the faster > > OoO cores. > Since writing that I took a look at some of the big.LITTLE (yes, > they really want us to call it that!) ARM info: > The little core is in fact very similar to the original Pentium, > with a single in-order pipeline with single/dual issue of > instructions. > The big core otoh look a lot more like a Pentium Pro. One thought that struck me, though it took a while because I'm not in that camp :), is that NICs doing stateful offload could be thought of as an exampe of some particularly coarse grained asymmetric multi processing, though generally (?) non-coherent and at the far end of a fairly slow interconnect. At the same time though that makes me think about "NFS protocol offload" cards from the late 80's/early 90's and how they fell-out of favor as the host CPUs got more and more oomph. Though that is a rather different context than what ARM seem to be shooting for.... rick jones I suppose if ARM aren't all that successful with "big.LITTLE" it could be referred to as "Horn.big.LITTLE..." -- portable adj, code that compiles under more than one compiler these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-10-21 16:41 -0700 |
| Message-ID | <j7svup$g17$1@news.albasani.net> |
| In reply to | #4299 |
On 10/21/2011 12:23 AM, Terje Mathisen wrote: > Rick Jones wrote: >> Tim McCaffrey<timcaffrey@aol.com> wrote: >>> It might even make sense to let the low power processor always >>> handle interrupts, >> >> "Networking" at least is rather fond of good interrupt service >> performance. Particularly in low-latency situations. > > An in-order (Pentium-style) core running at 50% the main frequency has > significantly less context, it is quite possible that it could handle > interrupts just as well as (or even better than) the faster OoO cores. > yeah, I think it could work. rarely do ISRs contribute a large portion of running time (otherwise something is probably terribly wrong). an OS scheduler logic need not be all that complex, and could probably simply assume: if the thread is using more than 10% or 25% of the CPU time, put it on the fast core (or cores), otherwise leave it on the slow core (such as sleeping and low-activity threads). this would probably work out fairly well, as at least with a PC (and x86), most of the time the CPU is running idle or at low load anyways (and usually only really spikes briefly, or the user is running something CPU intensive such as a game or similar). also, the OS could possibly disable/power-down the fast core/cores on low-battery conditions. off-hand, I can't really think of any obvious reasons why application software would notice or care (after all, most software has migrated fairly cleanly from single-core systems to multi-core systems, and hasn't noticed, and so there is no major reason for why it would notice with asymmetric cores). granted, I have seen at least one app (initial versions of Borderlands) which didn't work correctly on multi-core systems (one had to manually set its processor affinity to only run on a single core or else it was prone to crash). a later version seemed to work correctly. much like, most software has survived some of the transition from 32 to 64 bit processors, even despite some of the "not strictly backwards compatible" changes AMD made to the architecture (when operating in long-mode). one could possibly even make the slow core make some "not strictly compatible" feature reductions, and simply "promote" the thread if/when it uses more advanced features (say, FPU or SIMD). say, the thread runs on the low-speed core, uses an FPU or SIMD instruction, and generates an interrupt (#UD or #NM), causing the OS to reschedule it to a fast core (or, worst case, potentially temporarily suspend the thread, or use emulation, in low-power mode). at least, this would apply for x86 or x86-64 chips. granted, an asymmetric feature-set would likely require OS support and/or funky boot-up behavior to make everything work (assuming the slow core is the boot-up processor). OTOH, maybe the missing features could partially faked in microcode or similar, and with an "aware" OS setting CR0.EM so that it can trap interrupts and transfer the threads to faster cores. or such...
[toc] | [prev] | [next] | [standalone]
| From | jacko <jackokring@gmail.com> |
|---|---|
| Date | 2011-10-26 14:12 -0700 |
| Message-ID | <11239114.825.1319663566604.JavaMail.geo-discussion-forums@yqgn17> |
| In reply to | #4284 |
Sounds fine. Maybe 16 cores, split over 8 memory banks, with 8 of the cores being bridge interrupt units accessing the upper or lower half of the memory of the processor to either side, with a priority contention based on half a memory bank locking. The idea of communication up and down memory being a <address> <channel> software co-process handling interrupt, and both I and O versions being available. The memory location would essentially be the remote address contents, delayed by communication time. A sequential communication channel would need 2 memory locations, per core skipped through. T400? I think the new idea would be making the communication an interrupt, just like any other packet driver, with onCommunicateOut power management. Lets face it, if no task is interested in the information, then it should be slowed. And power demand balancing could be effected by a migration interrupt. Cheers Jacko
[toc] | [prev] | [standalone]
Page 9 of 9 — ← Prev page 1 2 3 4 5 6 7 8 [9]
Back to top | Article view | comp.arch
csiph-web