> On Sat, 11 Jan 2003 22:31:42 +, Nicholas Clark <[EMAIL PROTECTED]> said:
> On Sat, Jan 11, 2003 at 11:17:57PM +0100, Andreas J. Koenig wrote:
>> And it reminds me on my postings to p5p about glibc being very buggy
>> up to 2.3 (posted during last October). I came to the conclusion th
Nicholas Clark <[EMAIL PROTECTED]> wrote:
:So I'm confused. It looks like some bits of perl are incredibly sensitive to
:cache alignment, or something similar. And as a consequence, perlbench is
:reliably reporting wildly varying timings because of this, and because it
:only tries a few, very speci
--- Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Nicholas Clark wrote:
>
>
> > So I'm confused. It looks like some bits of perl are incredibly sensitive
> to
> > cache alignment, or something similar.
>
>
> This reminds me on my remarks on JITed mops.pasm which variied ~50% (or
> more) dependi
On Sat, Jan 11, 2003 at 11:17:57PM +0100, Andreas J. Koenig wrote:
> And it reminds me on my postings to p5p about glibc being very buggy
> up to 2.3 (posted during last October). I came to the conclusion that
> perl cannot be benchmarked at all with glibc before v2.3.
I remember your posting, bu
> On Sat, 11 Jan 2003 22:26:39 +0100, Leopold Toetsch <[EMAIL PROTECTED]> said:
> Nicholas Clark wrote:
>> So I'm confused. It looks like some bits of perl are incredibly sensitive to
>> cache alignment, or something similar.
> This reminds me on my remarks on JITed mops.pasm which vari
At 6:12 PM +0100 1/10/03, Jerome Quelin wrote:
Dan Sugalski wrote:
and who's got
questions on how this works? (I can put together examples, but this
is pretty long as it is, and I think it's reasonably
self-explanatory. Besides, assembly language isn't generally the best
way to demonstrate a
At 11:51 AM +0100 1/11/03, Leopold Toetsch wrote:
Brent Dax wrote:
Steve Fink:
# -memcpy(targ, ret->strstart, ret->bufused);
# -targ[ret->bufused + 1] = '\0';
# +memcpy(targ, ret->strstart, ret->strlen);
# +targ[ret->strlen] = '\0';
I could be wrong, but isn't strlen the
At 4:08 PM + 1/11/03, Nicholas Clark wrote:
On Thu, Jan 09, 2003 at 04:40:20PM -0500, Dan Sugalski wrote:
The find_method vtable entry should die, and be replaced with a plain
method entry. This should return either the address of the start of
the method's bytecode, or NULL. The NULL retur
Steve Fink wrote:
On Jan-11, Leopold Toetsch wrote:
Brent Dax wrote:
Steve Fink:
# -memcpy(targ, ret->strstart, ret->bufused);
# -targ[ret->bufused + 1] = '\0';
# +memcpy(targ, ret->strstart, ret->strlen);
# +targ[ret->strlen] = '\0';
I could be wrong, but isn't strl
On Friday, January 10, 2003, at 09:56 PM, Damian Conway wrote:
Just out of curiosity, how did you measure that? ;-)
Well, obviously, I used the Symbol::Readability module:
module Symbol::Readability;
sub delta_r(Str $a, Str $a) returns Int is exported {
return sum [»ord«split//,$x]
On Jan-11, Leopold Toetsch wrote:
> Brent Dax wrote:
>
> >Steve Fink:
> ># -memcpy(targ, ret->strstart, ret->bufused);
> ># -targ[ret->bufused + 1] = '\0';
> ># +memcpy(targ, ret->strstart, ret->strlen);
> ># +targ[ret->strlen] = '\0';
> >
> >I could be wrong, but isn't str
If memory serves me right, Nicholas Clark wrote:
> That doesn't sound right. But if it is right, then it sounds very wrong.
>
> (Translation: Are you sure about your terms, because what you describe sounds
> wonky. Hence if they are using UTF8 but with 16 bit chars, that feels like a
> silly desig
On Thu, Jan 09, 2003 at 04:40:20PM -0500, Dan Sugalski wrote:
> The find_method vtable entry should die, and be replaced with a plain
> method entry. This should return either the address of the start of
> the method's bytecode, or NULL. The NULL return is for those cases
> where the method actual
If memory serves me right, Nicholas Clark wrote:
> fussy. I presume Rhys is thinking about compiling C code to parrot, and then
> linking through to native C code (such as the native standard C library) via
> parrot.
Nope ... At least for our .NET platorm stuff ,we are planning to compile
glibc i
On Sat, Jan 11, 2003 at 10:12:42AM +0530, Gopal V wrote:
> If memory serves me right, Chris Dutton wrote:
> > Actually, if you really want Eiffel to compile to Parrot, it might be
> > interesting to work on getting ANSI C to compile to Parrot first, since
> > most Eiffel compilers use compilation
On Fri, 10 Jan 2003 14:12:12 +, Thom Boyer wrote:
> 'Course, then I've gotta explain why
> $x = 7 ~> 63;
> doesn't evaluate to 9
Surely because you haven't yet overloaded gozinta for the Number class!
-- c
Brent Dax wrote:
Steve Fink:
# -memcpy(targ, ret->strstart, ret->bufused);
# -targ[ret->bufused + 1] = '\0';
# +memcpy(targ, ret->strstart, ret->strlen);
# +targ[ret->strlen] = '\0';
I could be wrong, but isn't strlen the length in characters rather than
the length in byt
As already mentioned in the DOD threads, this patch adds a new
constant_pmc_pool and one additional interface function:
PMC *constant_pmc_new_noinit(Interp*, INTVAL base_type)
Constant PMCs are used by key constants (generated during PBC reading in
packfile.c) and in PerlHash for a global undef
Steve Fink wrote:
Ah! So all we have to do is use discontiguous PMCs -- the first 32
bytes is at offset 0, the second at byte offset 128 or so. Then we can
interleave them, so that everything in offset 0..127 gets loaded into
the cache, but 128..255 is left untouched. (Just kidding.)
s/32/16/
Jonathan Sillito wrote:
The attached patch fixes the problem.
Wow, that fast, thanks.
... It changes Scratchpad's data pointer
to be a pointer to an array of Parrot_Lexicals (rather than an array of
pointers to Parrot_Lexicals). The (name and value) lists are shared but
never the actual Parr
Jerome Quelin wrote:
Dan Sugalski wrote:
... Besides, assembly language isn't generally the best
way to demonstrate anything... :)
Indeed, once you wrote some Parrot assembly code to support a^Htwo
stupid^Wesoteric languages, Parrot assembly is quite a nice and easy
way to see how theory b
Steve Fink:
# -memcpy(targ, ret->strstart, ret->bufused);
# -targ[ret->bufused + 1] = '\0';
# +memcpy(targ, ret->strstart, ret->strlen);
# +targ[ret->strlen] = '\0';
I could be wrong, but isn't strlen the length in characters rather than
the length in bytes?
--Brent Dax <[
22 matches
Mail list logo
