On Tue, Feb 11, 2003 at 09:24:21AM +0100, A. Bergman wrote:
>
> On måndag, feb 10, 2003, at 23:03 Europe/Stockholm,
> [EMAIL PROTECTED] wrote:
I've never heard myself called that before :-)
> >This is probably the right default for the general case, but it is
> >counterproductive for benchmarki
On måndag, feb 10, 2003, at 23:03 Europe/Stockholm,
[EMAIL PROTECTED] wrote:
50% of the time your function/label/loop/jump is 16 byte aligned.
50% of the time your function/label/loop/jump is "randomly" aligned
So, a slight code size change early on in a file can cause the
remaining
functions
Dunno where this 'from' line came from, but it says here:
[EMAIL PROTECTED] wrote:
:On Sun, Jan 12, 2003 at 10:24:23AM +0100, Leopold Toetsch wrote:
:all default to a machine dependent default. This default isn't documented
:explicitly, but I presume that on x86 it's the same as the x86 specific -m
On Sun, Jan 12, 2003 at 10:24:23AM +0100, Leopold Toetsch wrote:
> In perl.perl6.internals, you wrote:
> > --- Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> >> * SLOW (same slow with register or odd aligned)
> >> * 0x818118a :sub0x8164cac,%ebx
> >> * 0x8181190 :jne0x818118a
>
At 7:43 AM +0100 1/14/03, Leopold Toetsch wrote:
BTW, I legitimatly don't know. I have a sinking suspicition that
the only way to know if somthing is a jump target is to scan through
the entire bytecode and check if it gets used as one.
I'm all for having an optional "jump/branch target" secti
On 01/12/2003 4:41 AM, Leopold Toetsch wrote:
There might be additional problems with glibc, but the deviations in JIT
code timings are only caused by moving the loop by on byte (crossing a 8
byte boundary).
Do we have enough metadata at JIT-time to pad locations that get jmp'd
to to an 8-byte
James Mastros wrote:
On 01/12/2003 4:41 AM, Leopold Toetsch wrote:
There might be additional problems with glibc, but the deviations in
JIT code timings are only caused by moving the loop by on byte
(crossing a 8 byte boundary).
Do we have enough metadata at JIT-time to pad locations that ge
On Sat, Jan 11, 2003 at 07:05:22PM +, Nicholas Clark wrote:
> I was getting about 5% speedups on penfold against vanilla development perl.
> Penfold is an x86 box (actually a Citrix chip, which may be important) running
> Debian unstable, with gcc 3.2.1 and 256M of RAM.
>
> I tried the same te
[EMAIL PROTECTED] wrote:
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
:o
Andreas J. Koenig wrote:
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 JIT
In perl.perl6.internals, you wrote:
> --- Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>> * SLOW (same slow with register or odd aligned)
>> * 0x818118a :sub0x8164cac,%ebx
>> * 0x8181190 :jne0x818118a
> The slow one has the loop crossing over a 16 byte boundary. Try moving it
> 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
16 matches
Mail list logo
