On Sun, May 09, 2010 at 11:37:24PM +0300, Niko Tyni wrote:
> Testing 5.12.0 with and without use64bitint on x86 shows an approximately
> 10% increase with scalars and arrays:
>
> perl -e '${"v$i"} = $i while ($i++ < $ARGV[0]); system("ps -o rss $$")'
> 100
> perl -e '$a[$i++] = $i while ($
On Sun, May 09, 2010 at 11:37:24PM +0300, Niko Tyni wrote:
> I'm partial to enabling use64bitint on all architectures, if only for the
> sake of uniformity already mentioned in the uselongdouble discussion: bugs
> that only happen on the "smaller" architectures because of differences
> like this a
On Mon, May 10, 2010 at 11:50:23AM +0200, Martin Becker wrote:
> I'd argue against a default setting where floating point numbers
> are less precise than integers.
I believe this has always been the case on our 64-bit architectures
(ia64, alpha, amd64.)
On current sid / amd64 (perl 5.10.1-12):
On Tue, May 04, 2010 at 05:29:03PM +0200, Florian Weimer wrote:
> * Niko Tyni:
>
> > The benefits are obviously improved numeric range and precision. The
> > downside is presumably increased memory usage. I have no measurement
> > data on this; suggestions on suitable tests would be welcome.
>
>
On Sun, May 09, 2010 at 12:25:43PM +0200, Florian Weimer wrote:
> * Niko Tyni:
>
> > Given that we've already run into a dozen or so incompatibilities
> > with just the CPAN modules, -Duselongdouble seems to be a pretty
> > rare thing to do. I'm inclined to revert this setting.
>
> That is, 64 bi
On Sun, May 09, 2010 at 12:17:56PM +0200, Florian Weimer wrote:
> So it boils down to malloc granularity (I don't think Perl's allocator
> is used on Debian). For that, I wrote this little test program:
While we do use the system malloc(), I think Perl allocates bigger chunks
at a time and thus
* Niko Tyni:
> I wasn't initially going for long doubles, but several upstream
> developers recommended that they be enabled together.
>
> http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2010-04/msg00773.html
This shows that long doubles are not backwards-compatible. 8-) The
root cause
* Stefan Fritsch:
> I may be a bit late to this discussion, but aren't 64bit ints (and
> especially pack/unpack "Q") very useful for 64bit file pointers and
> such? IMHO, this means that they would also be very useful on
> "smaller" architectures like arm.
Yes, they are, and that's where I hav
On Wednesday 05 May 2010, Brendan O'Dea wrote:
> > It would be possible to choose these settings separately for each
> > architecture. Should I exclude the 'smaller' architectures
> > (armel, mips*?)
>
> You could ask debian-...@lists.debian.org and the other ports
> lists, but it seems reasonable
On Sat, May 08, 2010 at 03:44:03PM +, Philipp Kern wrote:
> On 2010-05-08, Frans Pop wrote:
> > archkernel userland
> > -- --
> > alpha 32 32
>
> Isn't alpha the first 64bit of all?
>
> > mips/mipsel 3
On Saturday 08 May 2010, Julien Cristau wrote:
> alpha is all 64.
Shows that alpha is the arch I'm least familiar with...
> and sparc kernel is 64.
This I should have gotten right :-(
Thanks.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". T
On 2010-05-08, Frans Pop wrote:
> arch kernel userland
> ----
> alpha 32 32
Isn't alpha the first 64bit of all?
> mips/mipsel 32 32
I think that's 32/64, 32; at least for mipsel.
> sparc 32
On Sat, May 8, 2010 at 17:15:50 +0200, Frans Pop wrote:
> Niko Tyni wrote:
> > Can anybody list our "pure" 32-bit architectures off-hand
> > or suggest a simple test?
>
> AFAIK for Squeeze the arches are as follows, but please anybody correct me
> where incorrect.
>
> arch kernel
Niko Tyni wrote:
> Can anybody list our "pure" 32-bit architectures off-hand
> or suggest a simple test?
AFAIK for Squeeze the arches are as follows, but please anybody correct me
where incorrect.
archkernel userland
-- --
i3863
On Tue, May 04, 2010 at 05:29:03PM +0200, Florian Weimer wrote:
> * Niko Tyni:
>
> > The benefits are obviously improved numeric range and precision. The
> > downside is presumably increased memory usage. I have no measurement
> > data on this; suggestions on suitable tests would be welcome.
>
>
On 4 May 2010 22:54, Niko Tyni wrote:
> unlike earlier versions, perl 5.12.0-1 in experimental is configured with
> the "use64bitint" and "uselongdouble" options on all architectures. I'm
> looking for input on whether this is the right choice for sid.
Sounds like a good idea to me. I had intend
* Niko Tyni:
> The benefits are obviously improved numeric range and precision. The
> downside is presumably increased memory usage. I have no measurement
> data on this; suggestions on suitable tests would be welcome.
I have run into several incompatibilities between i386 and amd64 due
to differ
17 matches
Mail list logo
