diff for duplicates of <200702152203.59902.arnd@arndb.de> diff --git a/a/1.txt b/N1/1.txt index 7d3d86c..c5dafcb 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,18 +1,18 @@ On Thursday 15 February 2007 21:21, Carl Love wrote: -> I have done some quick measurements. =A0The above method limits the loop -> to at most 2^16 iterations. =A0Based on running the algorithm in user +> I have done some quick measurements. The above method limits the loop +> to at most 2^16 iterations. Based on running the algorithm in user > space, it takes about 3ms of computation time to do the loop 2^16 times. ->=20 +> > At the vary least, we need to put the resched in say every 10,000 -> iterations which would be about every 0.5ms. =A0Should we do a resched -> more often? =A0 +> iterations which would be about every 0.5ms. Should we do a resched +> more often? Yes, just to be on the safe side, I'd suggest to do it every 1000 iterations. -=20 + > Additionally we could up the size of the table to 512 which would reduce -> the maximum time to about 1.5ms. =A0What do people think about increasing +> the maximum time to about 1.5ms. What do people think about increasing > the table size? No, that won't help too much. I'd say 256 or 128 entries is the most @@ -22,11 +22,11 @@ we should have. > approach means that the space between the precomputed values at the high > end would be much larger then 2^14, assuming 256 precomputed values. > That means it could take much longer then 3ms to get the needed LFSR -> value for a large N. =A0By evenly spacing the precomputed values, we can +> value for a large N. By evenly spacing the precomputed values, we can > ensure that for all N it will take less then 3ms to get the value. > Personally, I am more comfortable with a hard limit on the compute time > then a variable time that could get much bigger then the 1ms threshold -> that Arnd wants for resched. =A0Any thoughts? +> that Arnd wants for resched. Any thoughts? When using precomputed values on a logarithmic scale, I'd recommend just rounding to the closest value and accepting the relative inaccuracy, diff --git a/a/content_digest b/N1/content_digest index e2145ca..79d1594 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -5,27 +5,27 @@ "Subject\0Re: [Cbe-oss-dev] [RFC, PATCH] CELL Oprofile SPU profiling updated\tpatch\0" "Date\0Thu, 15 Feb 2007 22:03:59 +0100\0" "To\0Carl Love <cel@us.ibm.com>\0" - "Cc\0linuxppc-dev@ozlabs.org" - cbe-oss-dev@ozlabs.org - oprofile-list@lists.sourceforge.net - " linux-kernel@vger.kernel.org\0" + "Cc\0cbe-oss-dev@ozlabs.org" + linuxppc-dev@ozlabs.org + linux-kernel@vger.kernel.org + " oprofile-list@lists.sourceforge.net\0" "\00:1\0" "b\0" "On Thursday 15 February 2007 21:21, Carl Love wrote:\n" "\n" - "> I have done some quick measurements. =A0The above method limits the loop\n" - "> to at most 2^16 iterations. =A0Based on running the algorithm in user\n" + "> I have done some quick measurements. \302\240The above method limits the loop\n" + "> to at most 2^16 iterations. \302\240Based on running the algorithm in user\n" "> space, it takes about 3ms of computation time to do the loop 2^16 times.\n" - ">=20\n" + "> \n" "> At the vary least, we need to put the resched in say every 10,000\n" - "> iterations which would be about every 0.5ms. =A0Should we do a resched\n" - "> more often? =A0\n" + "> iterations which would be about every 0.5ms. \302\240Should we do a resched\n" + "> more often? \302\240\n" "\n" "Yes, just to be on the safe side, I'd suggest to do it every 1000\n" "iterations.\n" - "=20\n" + " \n" "> Additionally we could up the size of the table to 512 which would reduce\n" - "> the maximum time to about 1.5ms. =A0What do people think about increasing\n" + "> the maximum time to about 1.5ms. \302\240What do people think about increasing\n" "> the table size?\n" "\n" "No, that won't help too much. I'd say 256 or 128 entries is the most\n" @@ -35,11 +35,11 @@ "> approach means that the space between the precomputed values at the high\n" "> end would be much larger then 2^14, assuming 256 precomputed values.\n" "> That means it could take much longer then 3ms to get the needed LFSR\n" - "> value for a large N. =A0By evenly spacing the precomputed values, we can\n" + "> value for a large N. \302\240By evenly spacing the precomputed values, we can\n" "> ensure that for all N it will take less then 3ms to get the value.\n" "> Personally, I am more comfortable with a hard limit on the compute time\n" "> then a variable time that could get much bigger then the 1ms threshold\n" - "> that Arnd wants for resched. =A0Any thoughts?\n" + "> that Arnd wants for resched. \302\240Any thoughts?\n" "\n" "When using precomputed values on a logarithmic scale, I'd recommend\n" "just rounding to the closest value and accepting the relative inaccuracy,\n" @@ -48,4 +48,4 @@ "\n" "\tArnd <><" -0bfff9b74380a1ccfee943ac46b7d46278ffb71b4690bc12bfe870fae22e92ad +788d579856289229ffc753d2182d64879e890ded9b31bcaebac6e85374a587b9
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.