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
Dan Sugalski wrote:
> At 09:25 AM 8/6/00 -0400, Ken Fox wrote:
> > We're definitely going to have some sort of traversing collector. It
> > might only augment the ref count collector.
>
> I'd rather not have multiple GC schemes going at once. (Though we may need
> some sort of "refered to by" fie
On Tue, 08 Aug 2000, Dan Sugalski wrote:
> I've been considering adding all the 'basic' operations (simple math,
> repetition, maybe comparisons) into the base vtable. That'd mean that,
> while the core perl might have *no* idea what to do with:
>
> @foo = @bar * 12;
>
> the slots would be th
Chaim Frenkel wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
> DS> To do it generally opens a huge can of worms. Doing it in a limited number
> DS> of cases (int->BigInt, float->BigRat, char->UTF8) is more reasonable, and
> DS> we can certainly manage that.
>
> Why limited? Doesn
On Tue, 8 Aug 2000, Ken Fox wrote:
> Chaim Frenkel wrote:
> > Have every Package generate a vtbl for each subroutine in the package.
> > Then when something is blessed into the package ...
>
> > I wasn't discussing the core. Rather a possible optimization of
> > method lookup.
> >
> > At any t
Chaim Frenkel wrote:
> Have every Package generate a vtbl for each subroutine in the package.
> Then when something is blessed into the package ...
> I wasn't discussing the core. Rather a possible optimization of
> method lookup.
>
> At any time only for any method name only a single version c
On Tue, 8 Aug 2000, Nick Ing-Simmons wrote:
> Perl6 Rfc Librarian <[EMAIL PROTECTED]> writes:
> >This document is not precisely concerned with the details of the
> >implementation
> >of the interfaces it specifies, beyond a general attempt to restric
> >itself to the possible.
>
> But this list
Chaim Frenkel wrote:
> > "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
> NI> The "mg.c" 'magic hacks' are in essence applying vtable semantics (they
> NI> are even called vtables in the sources) to a subset of "values".
> NI> So yes vtables mean evrything is "magic" so nothing needs "sp
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> The problem with that is that vtables need to be constant, and the list of
DS> subs in a package isn't constant, nor is it always known at compile time.
Why? All you need is a constant location.
Given that perl has to see _all_ subrouti
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 8 Aug 2000, Chaim Frenkel wrote:
> > "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
>
> NI> Chaim Frenkel <[EMAIL PROTECTED]> writes:
> >> Have every Package generate a vtbl for each subroutine in the package.
> >> Then when something is blessed into the package (if this is retained
> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
NI> Chaim Frenkel <[EMAIL PROTECTED]> writes:
>> Have every Package generate a vtbl for each subroutine in the package.
>> Then when something is blessed into the package (if this is retained for
>> OO) then the objects vtbl becomes the p
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
Perl6 Rfc Librarian <[EMAIL PROTECTED]> writes:
>This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
>=head1 TITLE
>
>Interfaces for linking C objects into perlsubs
>
>=head1 VERSION
>
> Maintainer: David Nicol <[EMAIL PROTECTED]>
> Date: 7 Aug 2000
> Version: 2
> Mai
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>
>I don't recall anyone commenting on my suggestion:
>
>Have every Package generate a vtbl for each subroutine in the package.
>Then when something is blessed into the package (if this is retained for
>OO) then the objects vtbl becomes the precompiled mer
http://dev.perl.org/rfc/37.pod
And if we adopt complex data structures (how complex? just
wrappers for C structs, into very fast hashes) as suggested in
rfc 61, we could return those special, limited pseudohashes
with only the relevant names, resolvable into offsets at
compile time, instead of t
> "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
Hildo Biersma quoted RFC 62 and then went on thusly:
> > C is an excellent medium for sharing the glory of the internals
> > of Perl with the C programming community. It is hoped that the
> > interface deescribed herein will become an excellent medium for
> > sharing the glory of the internals o
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
At 01:04 AM 8/8/00 +, Perl6 RFC Librarian wrote:
>=head1 TITLE
>
>Interfaces for linking C objects into perlsubs
This sounds more like we want perl to act like C's prologue code, so we can
invoke C programs without firing up a sub-process. It sounds rather nice,
but getting this working mos
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 08:47 AM 8/8/00 +0100, Hildo Biersma wrote:
>There's an excellent book on how vtables work in C++ and what issues
>have to be reolved for inheritance. multiple inheritance. This bbok
>also shows a number of useful compile-time optimizations, some of which
>might be applicable to perl6.
Yay, m
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
Perl6 RFC Librarian wrote:
>
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Interfaces for linking C objects into perlsubs
>
> =head1 VERSION
>
> Maintainer: David Nicol <[EMAIL PROTECTED]>
> Date: 7 Aug 2000
> Version: 2
> Mailing
Uri Guttman wrote:
>
> can someone write up a short description (or rfc is you prefer) on
> vtables. i gather that they are a per value (for some definition of
> value) dispatch table which handles the ways a value can be
> accessed. everyone is using that term and i haven't seen a concrete
> def
31 matches
Mail list logo
