develooper Front page | perl.perl5.porters | Postings from June 2013

the state of VMS (was Re: [perl #XXXXXX] miniperl fails with SIGBUSon sparc (usethreads+use64bitint))

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
June 11, 2013 13:56
Subject:
the state of VMS (was Re: [perl #XXXXXX] miniperl fails with SIGBUSon sparc (usethreads+use64bitint))
Message ID:
20130611135613.GB3729@plum.flirble.org
On Wed, May 29, 2013 at 07:41:41AM -0500, Craig A. Berry wrote:
> On Tue, May 28, 2013 at 3:10 AM, Nicholas Clark <nick@ccl4.org> wrote:

> > That's useful, but what I'd hope for, given that the initial version of the
> > alignment fix was already committed to blead as 24ee35539e5d73b5~92
> >
> > So it works on VMS Itanium. Which is good. But I'm sort of curious, is it
> > slower at 24ee35539e5d73b5~93 (or earlier - eg v5.18.0)
> >
> 
> Is it not c2a50dd that would be the cut-off point?
> 
> $ git log --oneline -n500 | grep -C2 c2a50dd
> cb1974b Update Pod-Perldoc to CPAN version 3.20
> 5b9c515 Update Pod-Usage to CPAN version 1.62
> c2a50dd Ensure that the IV in struct pmop (for ithreads) is aligned
> properly.
> 1a72e16 Update to CPAN-Meta means META.* need regenerating
> 814e893 Update File-Temp to CPAN version 0.2301

Yes, silly me.

> Based on that assumption I built blead@1a72e16 and the full build and run
> was about 3% faster than later.  There have been so many module updates and
> other goings-on that I doubt that is a number that means much.  Except it
> doesn't look like we had pathological alignment behavior before your fix.

Thanks for checking this.


Meanwhile, I've just copied 386de64977e726b5 across to the Itanium on the
HP cluster, and it's got to point of running tests. This one is known, right?

t/comp/parser ................................................. FAILED--unexpected output at test 0

Nicholas Clark

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About