http://qs321.pair.com?node_id=684142


in reply to Re: Pass by ref vs alias : why does scalar size matter?
in thread Pass by ref vs alias : why does scalar size matter?

So, at least judging from the limited set of versions and platforms, things point in the direction of Windows or MSVC to be responsible for the dramatic slowdown although I'm at a loss as to what part might be causing the slowdown.

Not only Windows, because I'm running mine on Linux:

Summary of my perl5 (revision 5 version 8 subversion 8) configuration: Platform: osname=linux, osvers=2.6.18, archname=x86_64-linux-thread-multi uname='linux eisler 2.6.18 #1 smp tue nov 21 12:59:21 utc 2006 x86 +_64 x86_64 x86_64 gnulinux ' config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr -Dinstallusr +binperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Duseshrplib=tr +ue -Doptimize=-O2 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -g -Wa +ll -pipe' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemulti +plicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=define use64bitall=define uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS +-DDEBUGGING -fno-strict-aliasing -pipe -Wdeclaration-after-statement +-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -g -Wal +l -pipe', cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGI +NG -fno-strict-aliasing -pipe -Wdeclaration-after-statement' ccversion='', gccversion='4.1.2 20061115 (prerelease) (SUSE Linux) +', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=1 +6 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', + lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib64' libpth=/lib64 /usr/lib64 /usr/local/lib64 libs=-lm -ldl -lcrypt -lpthread perllibs=-lm -ldl -lcrypt -lpthread libc=/lib64/libc-2.5.so, so=so, useshrplib=true, libperl=libperl.s +o gnulibc_version='2.5' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E - +Wl,-rpath,/usr/lib/perl5/5.8.8/x86_64-linux-thread-multi/CORE' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib64' Characteristics of this binary (from libperl): Compile-time options: DEBUGGING MULTIPLICITY PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP THREADS_HAVE_PIDS USE_64_BIT_ +ALL USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API Built under linux Compiled at Nov 25 2006 11:02:03 @INC: /usr/lib/perl5/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/5.8.8 /usr/lib/perl5/site_perl/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl .

Replies are listed 'Best First'.
Re^3: Pass by ref vs alias : why does scalar size matter?
by Corion (Patriarch) on May 02, 2008 at 12:00 UTC

    This would leave "x86" architecture as the only common thing. My "weird" Perls are running under 32-bit Windows x86 (Intel Celeron 2.8 GHz). You are seeing this under 64-bit Linux (AMD?).

    But the HP-UX machine also is a 64-bit x86 machine (Intel Xenon Server CPUs), and it doesn't exhibit the problematic behaviour.

      Same (clinton's) results here on a MacMini running Ubuntu, so it doesn't seem a processor specific issue:

      This is perl, v5.8.8 built for powerpc-linux-gnu-thread-multi
      It's an Intel core duo, but yes: AMD like