<!DOCTYPE html><html><head>
<style type="text/css">body { font-family:'Helvetica'; font-size:12px}</style>
</head>
<body><div>Hi,</div><div><br></div><div>I'd be in favor of the half-word mode:</div><ul><li>Having multiple 32-bit VMs would multiply the beam code stored in memory as well. This could mean a lot of memory wasted.</li><li>Using 32-bit VMs would not solve the 4GB limit on stack/heap size. On the contrary, the 4GB limit is for the total memory consumption of the 32-bit node. In the half-word mode the limit is per process; and you could even move data to private ETS tables from the heap for extremely memory hungry processes if nothing else helps.</li><li>If parts of your code needs HiPE, consider splitting out that part into a separate 32-bit VM running on the same node. So you will have two nodes per host: one half-word node for processes handling lot of data, and one 32-bit node with HiPE for processes doing number crunching.</li></ul><div>Regards,</div><div>Daniel</div><div><br></div><div>On Fri, 04 Apr 2014 10:33:30 +0200, Olivier BOUDEVILLE <olivier.boudeville@edf.fr> wrote:<br></div><br><blockquote style="margin: 0 0 0.80ex; border-left: #0000FF 2px solid; padding-left: 1ex"><font size="2" face="sans-serif">Hello all,</font>
<br>
<br><font size="2" face="sans-serif">Let's suppose one would like to run
a large, distributed (Erlang) application, with many processes, and that
ends up, in some cases, being RAM-bound.</font>
<br>
<br><font size="2" face="sans-serif">In order to squeeze more processes into
each node, apart from using the best data-structures to reduce memory footprint
and from having the least active processes hibernate, I imagine that a
good option could be to rely on "smaller pointers" (as they must
be used internally a lot by the VM, for most terms), i.e. either using
the 64-bit half-word emulator or instanciating as many 32-bit VMs as needed
to "pave" the actual RAM of each host, and have them communicate.
Apparently large gains in terms of memory could be expected.</font>
<br>
<br><font size="2" face="sans-serif">The half-word emulator would seem the
simplest/most elegant solution to do so (ex: I suppose that CPU extended
registers, instruction sets, etc. can then be used - which wouldn't be
the case for VMs compiled for 32-bit addressing; moreover 32-bit VMs would
probably have to communicate through the loopback or alike, involving I
suppose much marshalling/demarshalling) but apparently:</font>
<br><font size="2" face="sans-serif"> -
we currently cannot have both the half-word emulator *and* the HiPe-based
native compilation, so we have to choose between RAM and CPU (don't know
if targeting Erllvm could help)</font>
<br><font size="2" face="sans-serif"> -
more importantly, with the half-word emulator, the total RAM for stacks
+ heaps for processes would still have to be under 4GB (as stated apparently
by </font><a href="http://www.erlang-factory.com/upload/presentations/569/Halfword_Erlang_Factory_SF_2012.pdf"><font size="2" face="sans-serif">http://www.erlang-factory.com/upload/presentations/569/Halfword_Erlang_Factory_SF_2012.pdf</font></a><font size="2" face="sans-serif">)
</font>
<br>
<br><font size="2" face="sans-serif">So, my question: would relying on a
set of 32-bit VMs per host, instead of a single 64-bit VM, look like the
best option here?</font>
<br>
<br><font size="2" face="sans-serif">Thanks in advance for any hint!</font>
<br>
<br><font size="2" face="sans-serif">Best regards,</font>
<br><font size="2" face="sans-serif"><br>
Olivier.<br>
---------------------------<br>
Olivier Boudeville<br>
<br>
EDF R&D : 1, avenue du Général de Gaulle, 92140 Clamart, France<br>
Département SINETICS, groupe ASICS (I2A), bureau B-226<br>
Office : +33 1 47 65 59 58 / Mobile : +33 6 16 83 37 22 / Fax : +33 1 47
65 27 13</font>
<p><br>
Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse.</p>
<p>Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions également d'en avertir immédiatement l'expéditeur par retour du message.</p>
<p>Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur ou virus.<br>
____________________________________________________</p>
<p>This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval.</p>
<p>If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message.</p>
<p>E-mail communication cannot be guaranteed to be timely secure, error or virus-free.</p></blockquote><br><br><br></body></html>