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 ($i++
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.
I have
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 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 are
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 to
* 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 have run
* 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 is
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
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 bit NVs
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.
I have
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
-- --
i386
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
On 2010-05-08, Frans Pop elen...@planet.nl 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.
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.
On Sat, May 08, 2010 at 03:44:03PM +, Philipp Kern wrote:
On 2010-05-08, Frans Pop elen...@planet.nl wrote:
archkernel userland
-- --
alpha 32 32
Isn't alpha the first 64bit of all?
(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
* 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
On 4 May 2010 22:54, Niko Tyni nt...@debian.org 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
18 matches
Mail list logo
