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 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
| From | "Paul A. Clayton" <paaronclayton@gmail.com> |
|---|---|
| Date | 2011-11-12 14:05 -0800 |
| Subject | Re: cost of prolog/epilog (was: big-little) |
| Message-ID | <5c8dc23b-bdac-46d2-ab62-ad306c0d2997@n38g2000yqm.googlegroups.com> |
| In reply to | #4734 |
On Nov 12, 3:57 pm, Kalle Olavi Niemitalo <k...@iki.fi> wrote: [snip] > I tried writing the recursive part of fibonacci in amd64 asm but > the result was only 1% faster for fib(45) than what gcc -O2 > generated, on Intel Core i3-380UM. I'm no asm optimization > expert but I did expect I'd do better. I guess gcc did not recognize this as a minor deviation from tail recursion and implement a loop and possibly unroll the loop a bit. (Recognizing the mathematical properties would probably not be a generally useful optimization, I suspect; more broadly translating recursion into loops might be a somewhat generally useful optimization.) Deep recursion of simple functions is generally bad for deeply pipelined processors. (I do wonder if there would be sufficient benefit in return stack compression.)
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2011-11-18 02:39 +0100 |
| Subject | Re: cost of prolog/epilog (was: big-little) |
| Message-ID | <ja4cvp$jh8$1@online.de> |
| In reply to | #4740 |
Paul A. Clayton wrote: > (Recognizing the mathematical properties would > probably not be a generally useful optimization, I suspect; > more broadly translating recursion into loops might be a > somewhat generally useful optimization.) Well, that would be interesting. Recognizing that you don't need a double recursive function for fib is not difficult: fib(x) := x < 2 ? x : fib(x-1) + fib(x-2); It's quite easy to see that fib(x-1) computes fib(x-2) (except when x<2), so all you need is to remember that result, and you have a single recursion that can be converted into a loop. Ok, you need multiple return values for that, i.e. a C compiler will have difficulties to represent the transformed helper function, but there are languages which do not have this problem. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | torbenm@diku.dk (Torben Ægidius Mogensen) |
|---|---|
| Date | 2011-11-18 10:59 +0100 |
| Subject | Re: cost of prolog/epilog |
| Message-ID | <7zsjll92ep.fsf@ask.diku.dk> |
| In reply to | #4806 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > Paul A. Clayton wrote: >> (Recognizing the mathematical properties would >> probably not be a generally useful optimization, I suspect; >> more broadly translating recursion into loops might be a >> somewhat generally useful optimization.) > > Well, that would be interesting. Recognizing that you don't need a > double recursive function for fib is not difficult: > > fib(x) := x < 2 ? x : fib(x-1) + fib(x-2); > > It's quite easy to see that fib(x-1) computes fib(x-2) (except when > x<2), so all you need is to remember that result, and you have a single > recursion that can be converted into a loop. Ok, you need multiple > return values for that, i.e. a C compiler will have difficulties to > represent the transformed helper function, but there are languages which > do not have this problem. Indeed. And there is a general transformation method called "tupling" that will do the above. Since (as the name indicates) it involves building tuples, it works best for languages where tuple-building is easy, which is the case in most functional languages. Torben
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2011-11-18 22:06 +0100 |
| Subject | Re: cost of prolog/epilog |
| Message-ID | <ja6hc1$o54$1@online.de> |
| In reply to | #4811 |
Torben �gidius Mogensen wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: > >> fib(x) := x < 2 ? x : fib(x-1) + fib(x-2); >> >> It's quite easy to see that fib(x-1) computes fib(x-2) (except when >> x<2), so all you need is to remember that result, and you have a >> single >> recursion that can be converted into a loop. Ok, you need multiple >> return values for that, i.e. a C compiler will have difficulties to >> represent the transformed helper function, but there are languages >> which do not have this problem. > > Indeed. And there is a general transformation method called "tupling" > that will do the above. Since (as the name indicates) it involves > building tuples, it works best for languages where tuple-building is > easy, which is the case in most functional languages. In any case, I'd would expect a functional language compiler to be first on that - transforming fib into a helper function with a tuple of two values as output. We realize that we need both fib(x-1) and fib(x-2) to calculate fib(x), and the tuple fib(x),fib(x-1) = fib(x-1)+fib(x-2),fib(x-1) gives us the next iteration. BTW: touple-building *should* be easy in a C-like language, as well. It's just an oversight. Go can build tuples to some extent with the , operator (the natural tuple operator), and it has multiple return values, but it has the usual inconsistencies: you define a multiple return value by a tuple of primitive types, not by some special named return values construct. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | mac <acolvin@efunct.com> |
|---|---|
| Date | 2011-11-20 23:01 +0000 |
| Subject | Re: cost of prolog/epilog (was: big-little) |
| Message-ID | <134596659343522302.064885acolvin-efunct.com@news.eternal-september.org> |
| In reply to | #4806 |
> Well, that would be interesting. Recognizing that you don't need a > double recursive function for fib is not difficult: > > fib(x) := x < 2 ? x : fib(x-1) + fib(x-2); I don't have access to a good Fortran, but this is the sort recurrence that can be optimized for array indices. Can someone with HPF try this? It would bef particularly interesting with the reference outside the loop to some fib(n), to see if the compiler can eliminate the entire tarray.
[toc] | [prev] | [next] | [standalone]
| From | Chris Gray <cg@GraySage.com> |
|---|---|
| Date | 2011-11-13 13:35 -0700 |
| Subject | Re: cost of prolog/epilog |
| Message-ID | <87mxbzoj4q.fsf@GraySage.com> |
| In reply to | #4734 |
Kalle Olavi Niemitalo <kon@iki.fi> writes:
[Way off topic for comp.arch, but I'm just following up.]
> Terje Mathisen <"terje.mathisen at tmsw.no"> writes:
>> Native 64-bit C code on my laptop took 0.27 seconds, looking at the
>> disassembly it looks like you could speed this up by 50-100% with
>> better asm (function prolog/epilog is important for such a tiny
>> recursive function).
> I tried writing the recursive part of fibonacci in amd64 asm but
> the result was only 1% faster for fib(45) than what gcc -O2
> generated, on Intel Core i3-380UM. I'm no asm optimization
> expert but I did expect I'd do better.
I thought about it a bit after the earlier examples of bytecode costs of
this. Basically, for many bytecode engines, mine included, a recursive
function like "fib" is a bad case. They will do comparatively better on
looping code.
The testing in my "jsr" bytecode op:
if function is a "builtin" (written in C) then
...
else if function is "native" (native code for Zed function) then
...
else if function is invalid (has no bytecode) then
...
else if function call would overflow the stack then
...
else
Package_Package_t *pkPr = thePr->pr_containingPackage;
if (! thePr->pr_ctSafe && ! pkPr->pk_inited &&
pkPr->pk_varSize != 0)
{
... (containing package setup - rarely runs)
}
if (! thePr->pr_isStub) {
pkPr->pk_bcActiveCount += 1;
}
*--sp = (z_word_t) fp;
*--sp = (z_word_t) pc;
*--sp = (z_word_t) currentProc;
currentProc = thePr;
bcctx->bcctx_currentProc = currentProc;
bc = currentProc->pr_bytecode;
pk = pkPr;
sp = (z_word_t *) ((z_bits8_t *) sp - bc->bc_localSize);
#if UNALIGNED_OK && ZED_ENDIAN == ZED_LITTLE_ENDIAN
if (! bc->bc_byteSwapped) {
bcByteSwap((z_bits8_t *) &bc->bc_code->v_elements[0],
SIZE1(bc->bc_code));
bc->bc_byteSwapped = z_true;
}
#endif
pc = (z_bits8_t *) &bc->bc_code->v_elements[0];
fp = sp;
bcctx->bcctx_FP = fp;
Quite a lot of overhead. Constrast with a simple non-checking "add":
CASE(bc_qadd) {
z_word_t ul2;
ul2 = *sp++;
*sp += ul2;
BREAK;
}
One of the advantages of bytecode machines and other kinds of interpreters
is that they can easily handle run-time changes in the status of the code
they are running. Since Zed allows that, it is hard to get rid of all of
the tests in the "jsr" case. It would be easy enough to have an alternate
opcode that doesn't need to test for "builtin", since that can't change.
But whether or not a function has native code *can* change. Similarly, the
bytecode status can change if the function is edited and re-compiled
within the system.
-Chris Gray
[toc] | [prev] | [next] | [standalone]
| From | wclodius@lost-alamos.pet (William Clodius) |
|---|---|
| Date | 2011-11-11 22:13 -0700 |
| Message-ID | <1kal8ks.3q8n72roou6wN%wclodius@lost-alamos.pet> |
| In reply to | #4718 |
ChrisQ <meru@devnull.com> wrote:
> On 11/06/11 02:46, BGB wrote:
>
> > usually, the way I test the speed of interpreters is to have a loop or
> > similar which does arithmetic calculations.
> >
> > a common example is the recursive Fibonacci sequence.
> >
> > so, one does a recursive Fibonacci in the interpreter and in native
> > code, and compares them.
> >
> > other tests would include things like calculating hashes or checksums,
> > using bubble-sort or ripple sort or similar on arrays, ...
> >
> >
> > how I got the 70x figure was by running the tests on the real CPU, and
> > comparing it against the test as being run in an x86 interpreter (in
> > both cases, the code was in C and was compiled with GCC).
> >
> >
> > with an interpreter for an HLL or similar, the difference is often
> > smaller. more so, a typical higher-level interpreter will leave a lot
> > more to be done by native code.
> >
> > more so, if one is using a lot of natively-compiled library code, the
> > difference will be much smaller (in real use, the slowdown is often not
> > terribly severe).
> >
> >
> > also, most "real world" problems don't really take the form of "how
> > quickly can you calculate fib(40) via a recursive function?".
> >
> > FWIW, the fib function as expressed in my scripting language (BGBScript):
> > function fib(x:int):int
> > {
> > if(x>2)return(fib(x-2)+fib(x-1));
> > else return(1);
> > }
> >
> > or such...
>
> Not that translators are my area, but wonder if you instrumented the
> code to see where
> it was spending all it's time, or just accepted the compiler optimised
> output ?...
>
> Regards,
>
> Chris
There are several things that slow down interpretter. First is the time
needed to extract the instruction from the bytecode and branch to the
code section implementing the instruction. The for loop and switch
statement he described earlier is not the most efficent way to implement
the first part, but is perhaps the most straightforward. From his
comp.lang.misc postings I suspect he is experimenting with more
sophisticated methods, i.e. threaded code. Second is the number of
vvirtual machine instructions needed to implement the desired semantics.
This overhead is worst for a dynamically typed language. Third is the
time needed to execute the code of each instruction. The frequency of
mutibranching in a typical interpretter means that the much of the time
is spent waiting for the pipeline to drain before executing the next
instruction.
--
Bill Clodius
los the lost and net the pet to email
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-11-11 23:43 -0700 |
| Message-ID | <j9l4jt$3so$1@news.albasani.net> |
| In reply to | #4726 |
On 11/11/2011 10:13 PM, William Clodius wrote:
> ChrisQ<meru@devnull.com> wrote:
>
>> On 11/06/11 02:46, BGB wrote:
>>
>>> usually, the way I test the speed of interpreters is to have a loop or
>>> similar which does arithmetic calculations.
>>>
>>> a common example is the recursive Fibonacci sequence.
>>>
>>> so, one does a recursive Fibonacci in the interpreter and in native
>>> code, and compares them.
>>>
>>> other tests would include things like calculating hashes or checksums,
>>> using bubble-sort or ripple sort or similar on arrays, ...
>>>
>>>
>>> how I got the 70x figure was by running the tests on the real CPU, and
>>> comparing it against the test as being run in an x86 interpreter (in
>>> both cases, the code was in C and was compiled with GCC).
>>>
>>>
>>> with an interpreter for an HLL or similar, the difference is often
>>> smaller. more so, a typical higher-level interpreter will leave a lot
>>> more to be done by native code.
>>>
>>> more so, if one is using a lot of natively-compiled library code, the
>>> difference will be much smaller (in real use, the slowdown is often not
>>> terribly severe).
>>>
>>>
>>> also, most "real world" problems don't really take the form of "how
>>> quickly can you calculate fib(40) via a recursive function?".
>>>
>>> FWIW, the fib function as expressed in my scripting language (BGBScript):
>>> function fib(x:int):int
>>> {
>>> if(x>2)return(fib(x-2)+fib(x-1));
>>> else return(1);
>>> }
>>>
>>> or such...
>>
>> Not that translators are my area, but wonder if you instrumented the
>> code to see where
>> it was spending all it's time, or just accepted the compiler optimised
>> output ?...
>>
>> Regards,
>>
>> Chris
> There are several things that slow down interpretter. First is the time
> needed to extract the instruction from the bytecode and branch to the
> code section implementing the instruction. The for loop and switch
> statement he described earlier is not the most efficent way to implement
> the first part, but is perhaps the most straightforward. From his
> comp.lang.misc postings I suspect he is experimenting with more
> sophisticated methods, i.e. threaded code. Second is the number of
> vvirtual machine instructions needed to implement the desired semantics.
> This overhead is worst for a dynamically typed language. Third is the
> time needed to execute the code of each instruction. The frequency of
> mutibranching in a typical interpretter means that the much of the time
> is spent waiting for the pipeline to drain before executing the next
> instruction.
>
yep.
I have implemented faster interpreters in the past.
I had a version of the BGBScript interpreter in 2006 which I had
micro-tuned to get within 15x of native on the "fib()" test, but the
interpreter was otherwise nearly unusable (very complex/painful API with
many exposed implementation details and macros all over the place).
it was still loop-and-switch based, but made use of "super ops", which
were basically very complex opcodes such that much of the function could
be expressed in a few opcodes. also, the interpreter structure was a bit
more minimal.
both my prior interpreters (a Scheme interpreter in 2002, and the first
BGBScript implementation in 2004), and later interpreters, have been slower.
my early interpreters were technically pre-bytecode:
the scheme interpreter used modified ASTs (S-Expressions);
the first BGBScript interpreter used XML-nodes (DOM-like) in combination
with bit-masked 16-bit integers.
my later interpreters have more focused on usability and features than
performance. from 2006 onwards, BGBScript had been using bytecode and a
S-Exp based AST format (not used at runtime, unlike before).
with the 2006 implementation, I experimented with JIT, and eventually
wrote a C compiler based on this in 2007 (with me later reverting back
to using an XML-based parser derived from the 2004 implementation for
the front-end). however, I was eventually defeated by issues with
compiler performance and bugs (compiler was slow, and far too often
produced broken output, and I was finding myself incapable of
effectively debugging it...).
sadly, most of my subsequent attempts at implementing a full
(general-purpose) native code-gen (from the ground up) have ended in
failure. most success I have been having has been with specialized
task-specific code generators (but this is far more ad-hoc).
the current BGBScript interpreter is derived from the 2008
implementation (which combined parts of the 2004 and 2006 interpreters).
it was mostly motivated by the 2006 implementation being near-unusable.
most later development has been incremental (rather than near-total
rewrites).
I first experimented with threaded code in my x86 interpreter (2010),
mostly as a way to overcome the performance limitations of giant nested
switch blocks (I had something like 3 levels of switch blocks).
some of my "pure" tests (with very specialized threaded-code operations)
had showed performance rivaling that of native code (granted, these
tests were statically-types).
I tried creating a new threaded interpreter (ground-up) in late
2010/early 2011, but this effort died (internal complexity ran out of
control). this would have been a (mostly) statically-typed interpreter.
I subsequently resumed working with my old interpreter instead (despite
being far from perfect, it at least works). however, internally, this
old interpreter is still mostly dynamically typed.
just recently (~ 5 days ago), I have transitioned the old interpreter to
using threaded code (largely replacing the "loop-and-switch"
construction with a "loop-and-call" construction).
but, yes, maybe I am being a bit incompetent with all this...
[toc] | [prev] | [next] | [standalone]
| From | Chris Gray <cg@GraySage.com> |
|---|---|
| Date | 2011-11-12 14:08 -0700 |
| Message-ID | <87sjltnj52.fsf@GraySage.com> |
| In reply to | #4727 |
BGB <cr88192@hotmail.com> writes:
> my early interpreters were technically pre-bytecode:
> the scheme interpreter used modified ASTs (S-Expressions);
> the first BGBScript interpreter used XML-nodes (DOM-like) in
> combination with bit-masked 16-bit integers.
My first interpreter for my old AmigaMUD system was just a recursive
treewalk of the semantic trees (just the parse trees, actually). For
a fairly dated look at timings, discussion of timings, etc., see:
http://www.graysage.com/cg/MUD/AmigaMUD/ByteCode.txt
My Zed stuff is based on the AmigaMUD bytecode engine, using the
unaligned fetches discussed, and the gcc "computed goto".
I have a quite small piece of X86-64 code generation for Zed, and thought
about trying to get "fib" to work with that. But, right now, my proc
entry/exit is horrid (save/restore all callee-save regs, floats included),
so it would likely run slower than the bytecode!
--
Chris Gray
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-11-12 19:10 -0700 |
| Message-ID | <j9n8vn$91r$1@news.albasani.net> |
| In reply to | #4735 |
On 11/12/2011 2:08 PM, Chris Gray wrote: > BGB<cr88192@hotmail.com> writes: > >> my early interpreters were technically pre-bytecode: >> the scheme interpreter used modified ASTs (S-Expressions); >> the first BGBScript interpreter used XML-nodes (DOM-like) in >> combination with bit-masked 16-bit integers. > > My first interpreter for my old AmigaMUD system was just a recursive > treewalk of the semantic trees (just the parse trees, actually). For > a fairly dated look at timings, discussion of timings, etc., see: > some earlier forms of my Scheme interpreter were this way, but with some things like macro-expansion taking place. later forms got more involved, partially replacing symbols with scope index numbers, and using operation-numbers in place of symbols. however, the structure was still list-based. a later "compiler" was written which basically converted this form into C code, however, this introduced a lot of complexities (the compiler and interpreter couldn't share binding-environments or functions, ...). eventually, I abandoned this VM (although parts of it were later reused in the BGBScript VM). > http://www.graysage.com/cg/MUD/AmigaMUD/ByteCode.txt > > My Zed stuff is based on the AmigaMUD bytecode engine, using the > unaligned fetches discussed, and the gcc "computed goto". > mine is plain C, so no GCC'isms here. my stuff builds with both GCC and MSVC, with me using MSVC as the main compiler when building on Windows. > I have a quite small piece of X86-64 code generation for Zed, and thought > about trying to get "fib" to work with that. But, right now, my proc > entry/exit is horrid (save/restore all callee-save regs, floats included), > so it would likely run slower than the bytecode! > yes, ok. I have a native code-generator for x86 and x86-64, but it is used mostly by my C compiler (currently, BGBScript and my C compiler use different backends, and there are notable differences in the bytecode...). I had a JIT (32-bit x86 only) for the 2006 version of BGBScript, but this was not maintained for the 2008 version (which was changed significantly from the 2006 version). the codegen for my C compiler is a highly modified branch of the JIT from the 2006 VM. or such...
[toc] | [prev] | [next] | [standalone]
| From | Chris Gray <cg@GraySage.com> |
|---|---|
| Date | 2011-11-13 13:40 -0700 |
| Message-ID | <87hb27oixg.fsf@GraySage.com> |
| In reply to | #4743 |
BGB <cr88192@hotmail.com> writes:
> mine is plain C, so no GCC'isms here.
> my stuff builds with both GCC and MSVC, with me using MSVC as the main
> compiler when building on Windows.
Conditional compilation:
#ifdef __GNUC__
#define USE_COMPUTED_GOTO 1
#else
#define USE_COMPUTED_GOTO 0
#endif
plus some macros "CASE" and "BREAK" to do the right things.
--
Chris Gray
[toc] | [prev] | [next] | [standalone]
| From | Bakul Shah <usenet@bitblocks.com> |
|---|---|
| Date | 2011-11-13 14:49 -0800 |
| Message-ID | <4EC0496A.6060503@bitblocks.com> |
| In reply to | #4751 |
On 11/13/11 12:40 PM, Chris Gray wrote:
> BGB<cr88192@hotmail.com> writes:
>
>> mine is plain C, so no GCC'isms here.
>> my stuff builds with both GCC and MSVC, with me using MSVC as the main
>> compiler when building on Windows.
>
> Conditional compilation:
>
> #ifdef __GNUC__
> #define USE_COMPUTED_GOTO 1
> #else
> #define USE_COMPUTED_GOTO 0
> #endif
>
> plus some macros "CASE" and "BREAK" to do the right things.
>
This brings back some happy hacking memories! From some very old code:
[IIRC on a 33Mhz 386 the simulator was faster than the real 2Mhz 8bitter]
#define DO1(op, arg, ticks) { \
Byte vb; Word vw; Byte* a; \
COUNT += ticks; if (COUNT >= cpu->trigger) INTR |= ITIME; \
arg; op; \
NEXT; \
}
#define DO(op, ticks) DO1(op, 0, ticks)
# if __GNUC__ > 1 && defined DIRECT_JUMP
static const void * const caselab[256] = {
&&x00, &&x01, &&x02, &&x03, &&x04, &&x05, &&x06, &&x07,
&&x08, &&x09, &&x0a, &&x0b, &&x0c, &&x0d, &&x0e, &&x0f,
...
&&xf0, &&xf1, &&xf2, &&xf3, &&xf4, &&xf5, &&xf6, &&xf7,
&&xf8, &&xf9, &&xfa, &&xfb, &&xfc, &&xfd, &&xfe, &&xff,
};
# define SWITCH(x) goto *caselab[x];
# define CASE(y) cat(x,y)
# define NEXT if (INTR) goto ret; goto *caselab[nexti()]
# define ENDSWITCH
#else
# define SWITCH(x) switch(x) {
# define CASE(y) case cat(0x,y)
# define NEXT if (INTR) goto ret; continue
# define ENDSWITCH }
#endif
...
void
simulate(register CPU *cpu, register Byte *mem) {
for (;;) {
SWITCH(nextinst())
CASE(01): DO(NOP, 2);
CASE(02): DO(IDIV, 41);
CASE(03): DO(FDIV, 41);
...
CASE(12): DO1(BRSET, DIR, 6);
...
ENDSWITCH
}
ret:
RESTORE;
}
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-11-13 18:51 -0700 |
| Message-ID | <j9ps6o$6kj$1@news.albasani.net> |
| In reply to | #4751 |
On 11/13/2011 1:40 PM, Chris Gray wrote: > BGB<cr88192@hotmail.com> writes: > >> mine is plain C, so no GCC'isms here. >> my stuff builds with both GCC and MSVC, with me using MSVC as the main >> compiler when building on Windows. > > Conditional compilation: > > #ifdef __GNUC__ > #define USE_COMPUTED_GOTO 1 > #else > #define USE_COMPUTED_GOTO 0 > #endif > > plus some macros "CASE" and "BREAK" to do the right things. > one can also just use threaded code though, which AFAICT shouldn't be too much more expensive... another limitation of computed goto is that one can't goto across function boundaries...
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <"terje.mathisen at tmsw.no"> |
|---|---|
| Date | 2011-10-24 10:12 +0200 |
| Message-ID | <h8jfn8-9p32.ln1@ntp6.tmsw.no> |
| In reply to | #4355 |
BGB wrote: > however, none of this requires strict reliance on either determinism or > specific CPU clock-rate behavior. > > granted: in particularly nasty conditions (say, likely poorly designed > apps, where much time goes into threads fighting over a mutex) then the > slower core may be more likely to have a lower chance of getting the > lock (since it will only try to lock 1/2 or 1/4 as often as the faster > cores). I suspect this to be less of a problem: If we have a setup like big.LITTLE, all cores (slow/fast) share a common CC interconnect, right? In such an environment it seems to me that the various cores would all be capable of initiating memory transactions at nearly the same rate/speed? Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2011-10-24 12:11 -0400 |
| Message-ID | <jwv39ei4bk2.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #4358 |
> If we have a setup like big.LITTLE, all cores (slow/fast) share a common CC
> interconnect, right?
FWIW, I get the impression from reading some of the articles that the
big.LITTLE thingy does not use both cores at the same time, but switches
from one to the other instead.
Does anyone know for sure if the small and big cores work concurrently?
Also, does anyone know what they share (clearly they share external
memory, but what about the caches?).
Stefan
[toc] | [prev] | [next] | [standalone]
| From | "Paul A. Clayton" <paaronclayton@gmail.com> |
|---|---|
| Date | 2011-10-24 10:28 -0700 |
| Message-ID | <17ac2901-35bb-4176-bb58-0e0328a338b3@g7g2000vbv.googlegroups.com> |
| In reply to | #4363 |
On Oct 24, 11:11 am, Stefan Monnier <monn...@iro.umontreal.ca> wrote:
[snip]
> Does anyone know for sure if the small and big cores work concurrently?
> Also, does anyone know what they share (clearly they share external
> memory, but what about the caches?).
The ARM design idea is for non-concurrent operation (for simplicity
in
software), but concurrent operation is not excluded.
The L2 caches presented in the ARM whitepaper ("Big.LITTLE
Processing with ARM Cortex™-A15 & Cortex-A7") are separated
by 'cluster' of the same type of core (page 3): "While a more area
optimized approach would have been to share a single level-2 cache
between Cortex-A15 and Cortex-A7 this part of the design can
benefit from optimizations in favor of energy efficiency or
performance.
As such Cortex-A15 and Cortex-A7 have integrated level-2 caches."
(i.e.,integrated by core type as indicated in Figure 3 [page 4]).
[toc] | [prev] | [next] | [standalone]
| From | nospam@ab-katrinedal.dk (Niels Jørgen Kruse) |
|---|---|
| Date | 2011-10-24 19:38 +0200 |
| Message-ID | <1k9nq77.je0waocuejskN%nospam@ab-katrinedal.dk> |
| In reply to | #4363 |
Stefan Monnier <monnier@iro.umontreal.ca> wrote: > > If we have a setup like big.LITTLE, all cores (slow/fast) share a common CC > > interconnect, right? > > FWIW, I get the impression from reading some of the articles that the > big.LITTLE thingy does not use both cores at the same time, but switches > from one to the other instead. > > Does anyone know for sure if the small and big cores work concurrently? > Also, does anyone know what they share (clearly they share external > memory, but what about the caches?). From the slides, it is clear that there are separate L2 caches for big and LITTLE cores. Apparently, the L2 caches are more closely integrated with the cores than for the earlier core generations that had very slow L2. <http://www.anandtech.com/show/4991/arms-cortex-a7-bringing-cheaper-dual core-more-power-efficient-highend-devices> -- Mvh./Regards, Niels Jørgen Kruse, Vanløse, Denmark
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <"terje.mathisen at tmsw.no"> |
|---|---|
| Date | 2011-10-24 21:02 +0200 |
| Message-ID | <sapgn8-qfh2.ln1@ntp6.tmsw.no> |
| In reply to | #4363 |
Stefan Monnier wrote: >> If we have a setup like big.LITTLE, all cores (slow/fast) share a common CC >> interconnect, right? > > FWIW, I get the impression from reading some of the articles that the > big.LITTLE thingy does not use both cores at the same time, but switches > from one to the other instead. > > Does anyone know for sure if the small and big cores work concurrently? > Also, does anyone know what they share (clearly they share external > memory, but what about the caches?). They have separate caches, running both big and LITTLE at the same time is dubbed big.LITTLE MP, so that is definitely both supported and suggested for some workloads. The white paper linked here last week actually does show some useful info... Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | "Paul A. Clayton" <paaronclayton@gmail.com> |
|---|---|
| Date | 2011-10-23 12:02 -0700 |
| Message-ID | <754b3e4c-80a8-4d63-b4f1-c27d82045852@n13g2000vbv.googlegroups.com> |
| In reply to | #4340 |
On Oct 23, 9:39 am, ChrisQ <m...@devnull.com> wrote: [snip] > Sounds like a good idea, but couldn't this have been handled with > less complexity using adaptive clocking of a single core ?... The key word is leakage (static power consumption). By sacrificing performance, a core can be made to have much lower leakage (by using less-leaky transistors or fewer transistors). The fewer transistors option can also decrease energy per unit work and perhaps even energy-delay (i.e., the core can be more efficient). A simpler core may also require less wake-up time and energy, allowing it to be put into a deeper sleep while still meeting responsiveness requirements and not being less energy efficient if the sleep period is relatively short. The leakage of the high-performance core can be effectively cut to zero by power gating the entire core.
[toc] | [prev] | [next] | [standalone]
| From | Morten Reistad <first@last.name> |
|---|---|
| Date | 2011-11-03 00:51 +0100 |
| Message-ID | <sNidnXtrAbXJQSzTnZ2dnUVZ87-dnZ2d@telenor.com> |
| In reply to | #4307 |
In article <GUfoq.10299$El.1356@newsfe19.iad>, EricP <ThatWouldBeTelling@thevillage.com> wrote: >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. What is wrong with a hypervisor that integrates with the hardware? The OS just sees two, or four processors. The hypervisor may or may not map one or two of them to the small, slow processor and run simple-minded hyperthreading so it appears to be two processors. When usage picks up, the hypervisor fires up the large processors, and keep the slower ones on standby. Windows does not even have to know. >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. This can all be done by a hypervisor. -- mrr
[toc] | [prev] | [next] | [standalone]
Page 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
Back to top | Article view | comp.arch
csiph-web