[Vm-dev] Prebuilt 64-bit VM on Linux?
David T. Lewis
lewis at mail.msen.com
Mon Apr 15 12:04:26 UTC 2013
On Mon, Apr 15, 2013 at 02:37:33AM -0300, Hern?n Morales Durand wrote:
> El 10/04/2013 20:26, David T. Lewis escribi?:
> >On Wed, Apr 10, 2013 at 08:11:39PM -0300, Hern?n Morales Durand wrote:
> >>El 10/04/2013 18:57, David T. Lewis escribi?:
> >>>On Wed, Apr 10, 2013 at 06:11:53PM -0300, Hern??n Morales Durand wrote:
> >>>>I have a 64-bit CentOS server and I want a to measure the peak memory
> >>>>with valgrind for a script. For that I need a 64-VM (with a 32-bit Pharo
> >>>>I have tried with
> >>>>file reports: "squeak: ELF 32-bit LSB executable, Intel 80386, version
> >>>>1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9,
> >>>>Is there any precompiled linux 64-bit binary available?
> >>>As others have pointed out, an interpreter VM compiled for 64-bit will
> >>>work fine, though not as fast as Cog. However, recent Pharo images will
> >>>no longer run on a standard interpreter, so you cannot run a Pharo 2.0
> >>>image on a 64-bit VM.
> >>Thanks for the information. This is sad news. Because I am comparing
> >>avg. execution time against python and perl and cog is the winner for my
> >I am not familiar with valgrind, but if you can get a 32-bit version of
> >valgrind that works with the normal 32-bit Cog executable, I think that
> >would be the best thing to do. After all, that is your target execution
> >environment, so it would be good if your profiling tool runs in that same
> I was unable to get a working 32-bit version of valgrind. But even if I
> have it, I should downgrade my python and perl environments just because
> Smalltalk is not there for the fair competition. So my best choice for
> now it to get a working 64-bit VM for Linux.
> >If you are interested in memory utilization rather than speed, and if your
> >application runs in Squeak, then use a 64-bit interpreter VM and Squeak.
> I tried the 64-bit interpreter VM with Squeak, but the vm doesn't launch
> because of some GLIBC compatibility problem:
> ./squeakvm: /lib64/libc.so.6: version `GLIBC_2.14' not found (required
> by ./squeakvm)
> ./squeakvm: /lib64/libc.so.6: version `GLIBC_2.15' not found (required
> by ./squeakvm)
> I have browsed for that error, but haven't found nothing valuable.
This is a problem with incompatibilities between Linux distributions (and yes
we need to fix it). The VM that you downloaded is "too new" for the system
you are using. The solution is to recompile on an older system. If you are
comfortable building your own VM (see http://squeakvm.org/unix/devel.html)
then I would encourage you to do that. Or I compile one for you if you prefer
(but I am away and cannot do it right now).
> >If you want speed, then use Cog and find a profiling tool that can support
> >it. The difference between 32 and 64 bit compiled VMs is of no consequence
> >with respect to performance, it is really just a matter of installing the
> >necessary runtime libraries to support 32-bit operations.
> My requirement is to compare perfomance execution under the same
> conditions (VM architecture, memory load, etc). Actually in CentOS 6
> both Python and Perl have their 64-bit executables, and Smalltlak doesn't.
Let me try to summarize.
If you are interested in comparing execution speed performance, then you
must use a 32-bit Cog VM. The 64-bit interpreter VM is much slower than
Cog, and anyone running Squeak or Pharo on a 64-bit platform will use
the 32-bit Cog if performance is a concern. There are many advantages
to an interpreter VM, but speed is not one of them.
There is little or no performance difference between a VM compiled as
a 64-bit executable versus the same VM compiled as a 32-bit application.
So if you are interested in performance, a Cog VM compiled in 32-bit
is much faster than an interpreter VM compiled in 64-bit mode.
If you specifically need a 64-bit VM, or if you want to experiment with
a 64-bit image with large address space, then you must use an interpreter
VM. But it does not sound to me like this is your objective, it seems
like you are trying to work around a limitation of the valgrind profiling
More information about the Vm-dev