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
(sent to -devel and -perl; followups to -devel only, please)
Hi,
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.
For reference, quoting
18 matches
Mail list logo
