On 14 Aug 2000, Chaim Frenkel wrote:
> > "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
>
> LW> No, they're only stored once per statement, as far as I recall. This
> LW> is a great way to handle all sorts of lexically scoped things, provided
> LW> they don't require finer specificity than
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> No, they're only stored once per statement, as far as I recall. This
LW> is a great way to handle all sorts of lexically scoped things, provided
LW> they don't require finer specificity than a statement. Each new
LW> statement just rams a
Dan Sugalski writes:
: That's what I was thinking about, and it also makes the ops smaller.
Er, I don't think so, if you're talking about what I think you're talking
about.
: (We got a warning flag field in every op as of 5.6.0, IIRC)
No, they're only stored once per statement, as far as I reca
At 08:16 PM 8/8/00 +, Nick Ing-Simmons wrote:
>Caches work well with small-ish linear-ish hotspots that keep being re-used.
>When access pattern does not follow that pattern things get (gradually) worse.
>
>How gradual and how -ish depends on cache architecture which is
>fun, often proprietary
Bart Lateur <[EMAIL PROTECTED]> writes:
>On Tue, 08 Aug 2000 11:33:06 -0400, Dan Sugalski wrote:
>
>>The problem perl will always run into is that our executable code counts as
>>data to CPUs, and lives in the D cache, along with all the data we work on.
>>Ripping through a few 100K strings'll k
On Tue, 8 Aug 2000 20:58:46 -0400 (EDT), Dan Sugalski wrote:
>On Tue, 8 Aug 2000, Bart Lateur wrote:
>
>> Time for subroutine threading, isntead of op threading?
>
>Probably, depending on your definition of subroutine threading.
>
>> That would definitely make the "compiled" code at least twice a
On Tue, 8 Aug 2000, Ken Fox wrote:
> Dan Sugalski wrote:
> > The problem perl will always run into is that our executable code counts as
> > data to CPUs, and lives in the D cache, along with all the data we work on.
> > Ripping through a few 100K strings'll kill any sort of benefits to keeping
>
Dan Sugalski wrote:
> The problem perl will always run into is that our executable code counts as
> data to CPUs, and lives in the D cache, along with all the data we work on.
> Ripping through a few 100K strings'll kill any sort of benefits to keeping
> the optree small ...
Which is an argument
On Tue, 8 Aug 2000, Bart Lateur wrote:
> On Tue, 08 Aug 2000 11:33:06 -0400, Dan Sugalski wrote:
>
> >The problem perl will always run into is that our executable code counts as
> >data to CPUs, and lives in the D cache, along with all the data we work on.
> >Ripping through a few 100K strings
On Tue, 8 Aug 2000, Nick Ing-Simmons wrote:
> Dan Sugalski <[EMAIL PROTECTED]> writes:
> >
> >The problem perl will always run into is that our executable code counts as
> >data to CPUs, and lives in the D cache, along with all the data we work on.
>
> Hmm, that is the best case for JIT compil
On Tue, 08 Aug 2000 11:33:06 -0400, Dan Sugalski wrote:
>The problem perl will always run into is that our executable code counts as
>data to CPUs, and lives in the D cache, along with all the data we work on.
>Ripping through a few 100K strings'll kill any sort of benefits to keeping
>the opt
Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>The problem perl will always run into is that our executable code counts as
>data to CPUs, and lives in the D cache, along with all the data we work on.
Hmm, that is the best case for JIT compiler I have ever seen.
>Ripping through a few 100K strings
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
>
>>> A different op would be a better performance win. Even those sections
>>> that didn't want the check has to pay for it.
>
>GB> That may not be completly true. You would in effect be increasing th
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> The problem perl will always run into is that our executable code
DS> counts as data to CPUs, and lives in the D cache, along with all
DS> the data we work on. Ripping through a few 100K strings'll kill
DS> any sort of benefits
At 12:05 PM 8/8/00 -0400, Chaim Frenkel wrote:
>Does the cache hit/miss depend on the nearness of the code or simply
>on code path? Obviously having the checked version be a wrapper of
>the base op and near it on the same page would be a VM win.
Code path, usually. Nearness is only an issue up to
Chaim Frenkel writes:
> GB> As Chip says, human intuition is a very bad benchmark.
>
> Does the cache hit/miss depend on the nearness of the code or simply
> on code path? Obviously having the checked version be a wrapper of
> the base op and near it on the same page would be a VM win.
This soun
> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
>> A different op would be a better performance win. Even those sections
>> that didn't want the check has to pay for it.
GB> That may not be completly true. You would in effect be increasing the
GB> size of code for perl itself. Whether or n
At 11:54 AM 8/8/00 +0100, Graham Barr wrote:
>On Mon, Aug 07, 2000 at 02:23:08PM -0400, Chaim Frenkel wrote:
> > A different op would be a better performance win. Even those sections
> > that didn't want the check has to pay for it.
>
>That may not be completly true. You would in effect be increas
On Mon, Aug 07, 2000 at 02:23:08PM -0400, Chaim Frenkel wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> DS> At 06:37 AM 8/7/00 -0400, Chaim Frenkel wrote:
> >> Are there any (p5p) pragmas that have a runtime effect?
>
> DS> strict, for one. Warnings for another.
>
> Please e
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 06:37 AM 8/7/00 -0400, Chaim Frenkel wrote:
>> Are there any (p5p) pragmas that have a runtime effect?
DS> strict, for one. Warnings for another.
Please explain how these are runtime? I see them as compile time.
>> Would requiring/l
At 05:42 PM 8/7/00 +0100, Graham Barr wrote:
>On Mon, Aug 07, 2000 at 12:03:36PM -0400, Dan Sugalski wrote:
> > I've been thinking we could have a "state change" op that would
> selectively
> > and lexically alter the appropriate state variable (warnings, stricture,
> > shell, taint checking, wha
On Mon, Aug 07, 2000 at 12:03:36PM -0400, Dan Sugalski wrote:
> I've been thinking we could have a "state change" op that would selectively
> and lexically alter the appropriate state variable (warnings, stricture,
> shell, taint checking, whatever) on the fly. Each op would check the
> current
At 06:37 AM 8/7/00 -0400, Chaim Frenkel wrote:
>Are there any (p5p) pragmas that have a runtime effect?
strict, for one. Warnings for another.
>Would requiring/limiting pragmas to have a strictly compile time effect
>have a win for internals (performance, development, whatever)?
Probably, but p
Are there any (p5p) pragmas that have a runtime effect?
Would requiring/limiting pragmas to have a strictly compile time effect
have a win for internals (performance, development, whatever)?
Would there be any breakage?
For example, warnings. Rather than checking the flag in each op. A wrapper
24 matches
Mail list logo
