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 | 20 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 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
| From | timcaffrey@aol.com (Tim McCaffrey) |
|---|---|
| Date | 2011-10-20 19:51 +0000 |
| Subject | big-little |
| Message-ID | <j7pu4q$ndv$1@USTR-NEWS.TR.UNISYS.COM> |
There appears to be a new trend in the ARM camp: 1 smaller, lower performance processor and 1 or more larger/faster processors. Run the smaller processor until it gets "busy enough" to switch to the faster processor. It occurs to me this approach would work with x86 as well, especially with Mitch Alsup's comments about the possibilities of building 1/2 performance @ 1/12 die area processors. It might even make sense to let the low power processor always handle interrupts, (if all it did in "high performance" mode was wait for an interrupt to happen, it doesn't necessarily have to save context). Comments? - Tim
[toc] | [next] | [standalone]
| From | Terje Mathisen <"terje.mathisen at tmsw.no"> |
|---|---|
| Date | 2011-10-20 22:35 +0200 |
| Message-ID | <b9d6n8-t49.ln1@ntp6.tmsw.no> |
| In reply to | #4284 |
Tim McCaffrey wrote: > There appears to be a new trend in the ARM camp: 1 smaller, lower performance > processor and 1 or more larger/faster processors. Run the smaller processor > until it gets "busy enough" to switch to the faster processor. > > It occurs to me this approach would work with x86 as well, especially with > Mitch Alsup's comments about the possibilities of building 1/2 performance @ > 1/12 die area processors. It might even make sense to let the low power > processor always handle interrupts, (if all it did in "high performance" mode > was wait for an interrupt to happen, it doesn't necessarily have to save > context). > > Comments? 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. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Mark Thorson <nospam@sonic.net> |
|---|---|
| Date | 2011-10-20 14:18 -0800 |
| Message-ID | <4EA09E50.30B8F94@sonic.net> |
| In reply to | #4285 |
Terje Mathisen wrote: > > 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. If MS did that, what breaks?
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-10-21 07:54 +0100 |
| Message-ID | <j7r4uh$79t$1@gosset.csi.cam.ac.uk> |
| In reply to | #4286 |
In article <4EA09E50.30B8F94@sonic.net>, Mark Thorson <nospam@sonic.net> wrote: >Terje Mathisen wrote: >> >> 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. > >If MS did that, what breaks? Modern software of that nature is best thought of as in biological terms, as the complexity is comparable to a human genome and its expression and it is not all that much better structured. If you make a change of that nature to either, it is quite impossible to predict the consequences. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | David Kanter <dkanter@gmail.com> |
|---|---|
| Date | 2011-11-09 01:06 -0800 |
| Message-ID | <5bd3db9e-fc05-48a8-b3c0-6708d4eac954@q35g2000prh.googlegroups.com> |
| In reply to | #4298 |
On Oct 20, 10:54 pm, n...@cam.ac.uk wrote: > In article <4EA09E50.30B8...@sonic.net>, > Mark Thorson <nos...@sonic.net> wrote: > > >Terje Mathisen wrote: > > >> 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. > > >If MS did that, what breaks? > > Modern software of that nature is best thought of as in biological > terms, as the complexity is comparable to a human genome and its > expression and it is not all that much better structured. If you > make a change of that nature to either, it is quite impossible to > predict the consequences. S I M U L A T O R S. David
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-11-09 11:07 +0000 |
| Message-ID | <j9dmsp$mje$1@gosset.csi.cam.ac.uk> |
| In reply to | #4702 |
In article <5bd3db9e-fc05-48a8-b3c0-6708d4eac954@q35g2000prh.googlegroups.com>, David Kanter <dkanter@gmail.com> wrote: >On Oct 20, 10:54=A0pm, n...@cam.ac.uk wrote: >> In article <4EA09E50.30B8...@sonic.net>, >> Mark Thorson =A0<nos...@sonic.net> wrote: >> >> >Terje Mathisen wrote: >> >> >> 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 Wind= >ows. >> >> >If MS did that, what breaks? >> >> Modern software of that nature is best thought of as in biological >> terms, as the complexity is comparable to a human genome and its >> expression and it is not all that much better structured. =A0If you >> make a change of that nature to either, it is quite impossible to >> predict the consequences. > >S I M U L A T O R S. C H A O T I C S Y S T E M S . Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <"terje.mathisen at tmsw.no"> |
|---|---|
| Date | 2011-10-21 09:25 +0200 |
| Message-ID | <ubj7n8-3ra.ln1@ntp6.tmsw.no> |
| In reply to | #4286 |
Mark Thorson wrote: > Terje Mathisen wrote: >> >> 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. > > If MS did that, what breaks? Nothing, for a new OS version. They just will not want to backport it to the installed base of 1-7 year old existing os copies. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2011-10-21 11:07 -0400 |
| Message-ID | <GUfoq.10299$El.1356@newsfe19.iad> |
| In reply to | #4286 |
Mark Thorson wrote: > Terje Mathisen wrote: >> 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. > > If MS did that, what breaks? Do you mean if they did a proper job of it, or ...? It's one thing to stuff an asymmetric scheduler into your OS. It is something else to completely review all your apps and see how they work and play in the new environment. Various kinds of priority inversions could cause performance issues. Which threads or interrupts are time critical and what are those timings? How do you convey that knowledge to the OS for older apps (maybe some lookup database hack)? Or were you planning to rewrite everything? When should your kernel network stack switch to the fast processor? Maybe when packets arrive faster than you can process them, reroute the network interrupts to the fast cpu. When it catches up, reroute back to slow cpu. Eric
[toc] | [prev] | [next] | [standalone]
| From | timcaffrey@aol.com (Tim McCaffrey) |
|---|---|
| Date | 2011-10-21 16:28 +0000 |
| Message-ID | <j7s6js$bk3$1@USTR-NEWS.TR.UNISYS.COM> |
| In reply to | #4307 |
In article <GUfoq.10299$El.1356@newsfe19.iad>, ThatWouldBeTelling@thevillage.com says... > >Mark Thorson wrote: >> Terje Mathisen wrote: >>> 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. >> >> If MS did that, what breaks? > >Do you mean if they did a proper job of it, or ...? >It's one thing to stuff an asymmetric scheduler into your OS. >It is something else to completely review all your apps >and see how they work and play in the new environment. > >Various kinds of priority inversions could cause performance issues. >Which threads or interrupts are time critical and what are those timings? >How do you convey that knowledge to the OS for older apps >(maybe some lookup database hack)? > >Or were you planning to rewrite everything? > >When should your kernel network stack switch to the fast processor? >Maybe when packets arrive faster than you can process them, >reroute the network interrupts to the fast cpu. >When it catches up, reroute back to slow cpu. > >Eric > Oh, give me a break. If hyperthreading didn't break stuff, this won't either. - Tim
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-10-21 17:07 +0100 |
| Message-ID | <j7s5be$cj9$1@gosset.csi.cam.ac.uk> |
| In reply to | #4309 |
In article <j7s6js$bk3$1@USTR-NEWS.TR.UNISYS.COM>, Tim McCaffrey <timcaffrey@aol.com> wrote: > >Oh, give me a break. If hyperthreading didn't break stuff, this won't >either. That is probably true. Unfortunately, the condition is false, so the statement is vacuuous. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2011-10-21 13:25 -0400 |
| Message-ID | <BYhoq.6201$UK6.594@newsfe06.iad> |
| In reply to | #4309 |
Tim McCaffrey wrote: > In article <GUfoq.10299$El.1356@newsfe19.iad>, > ThatWouldBeTelling@thevillage.com says... >> Mark Thorson wrote: >>> Terje Mathisen wrote: >>>> 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. >>> If MS did that, what breaks? >> Do you mean if they did a proper job of it, or ...? >> It's one thing to stuff an asymmetric scheduler into your OS. >> It is something else to completely review all your apps >> and see how they work and play in the new environment. >> >> Various kinds of priority inversions could cause performance issues. >> Which threads or interrupts are time critical and what are those timings? >> How do you convey that knowledge to the OS for older apps >> (maybe some lookup database hack)? >> >> Or were you planning to rewrite everything? >> >> When should your kernel network stack switch to the fast processor? >> Maybe when packets arrive faster than you can process them, >> reroute the network interrupts to the fast cpu. >> When it catches up, reroute back to slow cpu. >> >> Eric >> > > Oh, give me a break. If hyperthreading didn't break stuff, this won't > either. > > - Tim > Hyperthreading is not attempting to lower power usage (if anything, just the opposite) and acts as just another SMP cpu. While asymmetry may not break (crash), you will not necessarily derive any benefit from it without other OS and app mods. WRT priority inversion, here I'm thinking of shared OS data structures like the event state table or the thread scheduling table that are guarded by spinlocks. Also shared service threads like for the file system that manage critical resources. I'm just pointing out that one could easily find that the system throughput was throttled to the speed of the slowest cpu, and at the same time does not minimize power. To address this would require quite a thorough examination and adding new interrupt, driver, and thread information that lets the system know where each is best processed. Eric
[toc] | [prev] | [next] | [standalone]
| From | timcaffrey@aol.com (Tim McCaffrey) |
|---|---|
| Date | 2011-10-21 19:45 +0000 |
| Message-ID | <j7si4b$jbt$1@USTR-NEWS.TR.UNISYS.COM> |
| In reply to | #4313 |
In article <BYhoq.6201$UK6.594@newsfe06.iad>, ThatWouldBeTelling@thevillage.com says... > >Tim McCaffrey wrote: >> In article <GUfoq.10299$El.1356@newsfe19.iad>, >> ThatWouldBeTelling@thevillage.com says... >>> Mark Thorson wrote: >>>> Terje Mathisen wrote: >>>>> 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. >>>> If MS did that, what breaks? >>> Do you mean if they did a proper job of it, or ...? >>> It's one thing to stuff an asymmetric scheduler into your OS. >>> It is something else to completely review all your apps >>> and see how they work and play in the new environment. >>> >>> Various kinds of priority inversions could cause performance issues. >>> Which threads or interrupts are time critical and what are those timings? >>> How do you convey that knowledge to the OS for older apps >>> (maybe some lookup database hack)? >>> >>> Or were you planning to rewrite everything? >>> >>> When should your kernel network stack switch to the fast processor? >>> Maybe when packets arrive faster than you can process them, >>> reroute the network interrupts to the fast cpu. >>> When it catches up, reroute back to slow cpu. >>> >>> Eric >>> >> >> Oh, give me a break. If hyperthreading didn't break stuff, this won't >> either. >> >> - Tim >> > >Hyperthreading is not attempting to lower power usage >(if anything, just the opposite) and acts as just another SMP cpu. > >While asymmetry may not break (crash), you will not necessarily >derive any benefit from it without other OS and app mods. > >WRT priority inversion, here I'm thinking of shared OS >data structures like the event state table or the thread >scheduling table that are guarded by spinlocks. >Also shared service threads like for the file system >that manage critical resources. > >I'm just pointing out that one could easily find that the >system throughput was throttled to the speed of the slowest cpu, >and at the same time does not minimize power. >To address this would require quite a thorough examination >and adding new interrupt, driver, and thread information that >lets the system know where each is best processed. > Ok, you've got multiple arguements going on here, and I don't necessarily disagree with everything you say, but let me focus down a bit: Priority inversions, slower CPUs, etc. When you are running on a CPU that supports hyperthreading your performance can vary by up to 50% (when the "other" CPU thread activates/deactivates). And, what is worse, it can be caused by a thread with much lower priority! (one of the ways I think hyperthreading is broken). So, what is different if one of your threads happens to be running on a CPU that is only 1/2 (or maybe less) of the performance of the "main" CPU? Well, in comparison to, say, a Core i7 system, nothing really if your running more than 4 threads (assuming your OS gets it "right" as far as scheduling). The same priority inversion, waiting on a "slow" CPU for a spinlock, and all the rest HAPPENS TODAY, and has been happening since the Pentium 4 was unleashed. Should the OS be fixed to handle this case? Sure, but lots of stuff still works (I haven't run into cases where stuff doesn't work, but I have noticed flaky performance). And in many cases pathological thrashing on cache misses due to improper cache line sharing can cause a bigger performance impact. That is not going to be fixed soon either. Follow-up EE Times article: http://www.eetimes.com/electronics-news/4229926/ARM-unleashes-L ittle-Dog-on-Intel-s-tail - Tim
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2011-10-22 14:44 -0400 |
| Message-ID | <GbEoq.6047$Pz6.4987@newsfe22.iad> |
| In reply to | #4315 |
Tim McCaffrey wrote: > > Ok, you've got multiple arguements going on here, and I don't > necessarily disagree with everything you say, but let me focus > down a bit: > > Priority inversions, slower CPUs, etc. When you are running on > a CPU that supports hyperthreading your performance can vary by > up to 50% (when the "other" CPU thread activates/deactivates). > And, what is worse, it can be caused by a thread with much > lower priority! (one of the ways I think hyperthreading is > broken). > > So, what is different if one of your threads happens to be > running on a CPU that is only 1/2 (or maybe less) of the > performance of the "main" CPU? Well, in comparison to, say, a > Core i7 system, nothing really if your running more than 4 > threads (assuming your OS gets it "right" as far as > scheduling). The same priority inversion, waiting on a "slow" > CPU for a spinlock, and all the rest HAPPENS TODAY, and has > been happening since the Pentium 4 was unleashed. Ok I see how you are looking at that. Yes I suppose a hyper-threaded cpu could appear to a third cpu as a pair of half speed processors. And within the critical sections, yeah it could take twice as long to finish and that doesn't seem produce noticeable problems. Actually for spinlocks on Hyper-threaded cpu Intel added the MONITOR & MWAIT instructions. They watch a memory location and put the hyper-thread to sleep until there is a change so the spinning doesn't swamp the execution queue. > Should the OS be fixed to handle this case? Sure, but lots of > stuff still works (I haven't run into cases where stuff doesn't > work, but I have noticed flaky performance). And in many cases > pathological thrashing on cache misses due to improper cache > line sharing can cause a bigger performance impact. That is > not going to be fixed soon either. Even with Windows thread priority model I'm not sure there is sufficient information to make good power handling decisions. Many threads are in timer polling loops, so just because there are 5 computable threads queued to run doesn't mean there is a backlog as most will just do a little and sleep. (One might reasonably question why someone was using a timed polling loop on a power sensitive platform.) I was thinking about the cache thrashing too. The scheduler would need to be aware there is a cost to moving threads from one cpu to another. In my hobby OS scheduler I am using a capacitive charge-discharge model. As a thread runs it "charges" its own cache and discharges prior threads, and this introduces some hysteresis into thread choice (makes them a little bit sticky, but just for a while). I haven't built and tested it yet so can't say if it is actually is useful (there are some timing parameters to play with). The ARM system also apparently has 'Dynamic Voltage and Frequency Scaling', and something called 'drowsy caches' (just enough power to retain them). More knobs for the scheduler to play with. > Follow-up EE Times article: > http://www.eetimes.com/electronics-news/4229926/ARM-unleashes-L > ittle-Dog-on-Intel-s-tail > > > - Tim > Slightly more technical but still not very informative... http://www.arm.com/products/processors/technologies/bigLITTLEprocessing.php http://www.arm.com/files/downloads/big.LITTLE_Final.pdf Eric
[toc] | [prev] | [next] | [standalone]
| From | ChrisQ <meru@devnull.com> |
|---|---|
| Date | 2011-10-22 16:57 +0000 |
| Message-ID | <hCCoq.5994$Wo5.3041@newsfe03.ams2> |
| In reply to | #4309 |
On 10/21/11 16:28, Tim McCaffrey wrote: > > Oh, give me a break. If hyperthreading didn't break stuff, this won't > either. > > - Tim > I tend to agree. Assuming that both cores are equivalent in code excution terms, it shouldn't be difficult to arrange that the lower power core takes priority up to a certain load, then enable the second core... Regards, Chris
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-10-22 17:40 +0100 |
| Message-ID | <j7url4$qiu$1@gosset.csi.cam.ac.uk> |
| In reply to | #4325 |
In article <hCCoq.5994$Wo5.3041@newsfe03.ams2>, ChrisQ <meru@devnull.com> wrote: >On 10/21/11 16:28, Tim McCaffrey wrote: > >> Oh, give me a break. If hyperthreading didn't break stuff, this won't >> either. > >I tend to agree. Assuming that both cores are equivalent in code >excution terms, it shouldn't >be difficult to arrange that the lower power core takes priority up to a >certain load, then >enable the second core... That's not, nor ever was, the problem. The hardware issues are fairly easily soluble, and the operating system ones are well-understood technology (though that doesn't mean what it should), but the application ones are hell. It is remarkably hard to write certain kinds of parallel primitive if the speed of your CPU is too unpredictable, and experience is that most parallel implementations fail horribly when that happens and the application stresses the relevant kind of primitive. There isn't a problem with the very low-communication parallelism typical of things like Web servers, but there assuredly is with the high-communication parallelism typical of HPC. And an increasing number of 'non-HPC' codes are using such techniques (for, say, faster graphics performance). Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | ChrisQ <meru@devnull.com> |
|---|---|
| Date | 2011-10-23 14:39 +0000 |
| Message-ID | <DGVoq.6212$Wo5.4036@newsfe03.ams2> |
| In reply to | #4326 |
On 10/22/11 16:40, nmm1@cam.ac.uk wrote: > > That's not, nor ever was, the problem. > > The hardware issues are fairly easily soluble, and the operating > system ones are well-understood technology (though that doesn't > mean what it should), but the application ones are hell. It is > remarkably hard to write certain kinds of parallel primitive if > the speed of your CPU is too unpredictable, and experience is that > most parallel implementations fail horribly when that happens and > the application stresses the relevant kind of primitive. There > isn't a problem with the very low-communication parallelism > typical of things like Web servers, but there assuredly is with > the high-communication parallelism typical of HPC. And an > increasing number of 'non-HPC' codes are using such techniques > (for, say, faster graphics performance). > > That sounds like excuses to me, in that any modern application dependent on the gory internals of the os, or hardware timing subtleties, would be asking for trouble. In 1980 perhaps, but not now. It's the os's job to provide system services and an abstraction layer to hide any such h/w dependencies. Any speed differences, or cpu switching should be handled transparently, depending on load. As for hpc, I doubt if such a big / little architecture would be at all relevant. Sounds like a good idea, but couldn't this have been handled with less complexity using adaptive clocking of a single core ?... Regards, Chris
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-10-23 16:11 +0100 |
| Message-ID | <j81art$4at$1@gosset.csi.cam.ac.uk> |
| In reply to | #4340 |
In article <DGVoq.6212$Wo5.4036@newsfe03.ams2>, ChrisQ <meru@devnull.com> wrote: >> >> The hardware issues are fairly easily soluble, and the operating >> system ones are well-understood technology (though that doesn't >> mean what it should), but the application ones are hell. It is >> remarkably hard to write certain kinds of parallel primitive if >> the speed of your CPU is too unpredictable, and experience is that >> most parallel implementations fail horribly when that happens and >> the application stresses the relevant kind of primitive. There >> isn't a problem with the very low-communication parallelism >> typical of things like Web servers, but there assuredly is with >> the high-communication parallelism typical of HPC. And an >> increasing number of 'non-HPC' codes are using such techniques >> (for, say, faster graphics performance). > >That sounds like excuses to me, in that any modern application >dependent on the gory internals of the os, or hardware >timing subtleties, would be asking for trouble. In 1980 perhaps, >but not now. It's the os's job to provide system services and an >abstraction layer to hide any such h/w dependencies. Any speed >differences, or cpu switching should be handled transparently, >depending on load. As for hpc, I doubt if such a big / little >architecture would be at all relevant. You don't have any HPC experience, do you? :-) Yes, a great deal of such misbehavior is due to incompetence, but such parallelism is NOT handled by the operating system (that would be too slow), and there are some solid theoretical reasons why this problem cannot be solved, only alleviated. It is already a major headache with many of the fancy hardware and operating system features. The reason that non-HPC applications so rarely see the problems is that the potentially problematic event rate is massively lower (often a factor of 10^-6 or more), so a MTBF of one day in HPC corresponds to over a decade for non-HPC. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | ChrisQ <meru@devnull.com> |
|---|---|
| Date | 2011-10-23 17:44 +0000 |
| Message-ID | <foYoq.4125$%J7.2182@newsfe11.ams2> |
| In reply to | #4341 |
On 10/23/11 15:11, nmm1@cam.ac.uk wrote: > > You don't have any HPC experience, do you? :-) > > Yes, a great deal of such misbehavior is due to incompetence, > but such parallelism is NOT handled by the operating system > (that would be too slow), and there are some solid theoretical > reasons why this problem cannot be solved, only alleviated. > It is already a major headache with many of the fancy hardware > and operating system features. > > The reason that non-HPC applications so rarely see the problems > is that the potentially problematic event rate is massively > lower (often a factor of 10^-6 or more), so a MTBF of one day > in HPC corresponds to over a decade for non-HPC. > > > Regards, > Nick Maclaren. No, I don't have any hpc experience :-), but can see that where you want the higest performance, you might use all kinds of shorcuts around the os to get there, together with detailed knowledge of the os internals. The 1980 comment meant to suggest that. Desktop machines had serious performance limitations and all kinds of hacks were used to get round them. For example, counting cycles within interrupt handlers to reach timing constraints. Modern machines have enough performance to allow an os to be written properly, using sound engineering principles and my original comment was really saying there's no longer any excuse for not doing so. hpc is and probably always will be a special case though. I guess machines can never be fast enough for some applications. I do like your ideas about non interruptable systems, but it would need all the normal i/o offloaded onto intelligent peripherals, with the cpu using polling / message passing to tie it all together. With the price of hardware now, such a scheme would not be expensive... Regards, Chris
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-10-23 18:46 +0100 |
| Message-ID | <j81jtm$5em$1@gosset.csi.cam.ac.uk> |
| In reply to | #4344 |
In article <foYoq.4125$%J7.2182@newsfe11.ams2>, ChrisQ <meru@devnull.com> wrote: > >No, I don't have any hpc experience :-), but can see that where you want >the higest performance, you might use all kinds of shorcuts around the os >to get there, together with detailed knowledge of the os internals. The >1980 comment meant to suggest that. Desktop machines had serious >performance limitations and all kinds of hacks were used to get round >them. For example, counting cycles within interrupt handlers to reach >timing constraints. > >Modern machines have enough performance to allow an os to be written >properly, >using sound engineering principles and my original comment was really >saying >there's no longer any excuse for not doing so. Ah, there I agree with you, except that the limitations are as often hardware as operating system, and that there never really has been any excuse for the appalling interfaces both generally provide. But, even then, one would have to allow the application control over the speed of its CPUs and whether they were gang scheduled, or abandon a whole class of algorithms. As an aside, this issue is one of the main reasons for GUI and networking unreliability, the modern forms of which use timing-dependent algorithms heavily. >I do like your ideas about non interruptable systems, but it would need all >the normal i/o offloaded onto intelligent peripherals, with the cpu using >polling / message passing to tie it all together. With the price of hardware >now, such a scheme would not be expensive... That's not really necessary, actually, with the number of simple cores you can put on a chip nowadays. In most circumstances, you could dedicate a core to each fast device, and a couple for slow ones, without impacting much on chip area. All those then need is a queue of tasks. But there has been a terrible reluctance to provide more, much simpler and slower, CPUs - despite the power advantages. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Womack <twomack@chiark.greenend.org.uk> |
|---|---|
| Date | 2011-10-23 19:30 +0100 |
| Message-ID | <WH*wDrQt@news.chiark.greenend.org.uk> |
| In reply to | #4345 |
In article <j81jtm$5em$1@gosset.csi.cam.ac.uk>, <nmm1@cam.ac.uk> wrote: >But, even then, one would have to allow the application control >over the speed of its CPUs and whether they were gang scheduled, >or abandon a whole class of algorithms. You don't have to abandon them, they'll generally work correctly but slowly. It's a problem I've got at the moment, running MPI jobs on a NUMA machine; even if I use taskset to get it to allocate three jobs on each of eight CPUs, the scheduler will tend to permute the jobs around the set and leave them on a different CPU from their memory. But I can tell which CPU the memory was allocated on, and construct taskset commands to bolt the task to its memory, and then it seems to work reasonably well. I appreciate this would be a good deal more awkward if I had tasks that weren't created once and for all. Tom
[toc] | [prev] | [next] | [standalone]
Page 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.arch
csiph-web