NodeJS 32 vs 64 bit performance.

[Chris Dew]

Hi, we run NodeJS in production and I want to ask some performance
questions.

We use Ubuntu Server AMD64. We run multiple, small non-NodeJS
binaries which we have compiled as 32 bit executables. Our servers
have enough cores/processes that system RAM would be exhausted if each
malloc'd its maximum 2GiB of addresss pace - i.e. the 2GiB/process
address space limit is not an issue.

Is there any advantage to using 32 bit NodeJS on a 64 bit
architecture, when running ten or more NodeJS processes behind pound?
Are there benchmarks?

I'm asking this because our other binaries use less memory and run
slightly faster as 32 bit executables.
http://www.tuxradar.com/content/ubuntu-904-32-bit-vs-64-bit-benchmarks
hints the opposite - that V8 performance may be worse as a 32 bit
binary.

Thanks,

Chris.

P.S. What would the impact on npm be? Would it be better to maintain
a 32 bit (VM) system for NodeJS/npm builds, and ship all binaries
(NodeJS and npm C++ packages) wholesale onto the 64 bit servers?
P.P.S. getlibs: http://ubuntuforums.org/showthread.php?t=474790

[Joe Developer]

On Wed, Apr 20, 2011 at 12:25 PM, Chris Dew <chri...@barricane.com> wrote:

Hi, we run NodeJS in production and I want to ask some performance
questions.

We use Ubuntu Server AMD64.  We run multiple, small non-NodeJS
binaries which we have compiled as 32 bit executables.  Our servers
have enough cores/processes that system RAM would be exhausted if each
malloc'd its maximum 2GiB of addresss pace - i.e. the 2GiB/process
address space limit is not an issue.

Is there any advantage to using 32 bit NodeJS on a 64 bit
architecture, when running ten or more NodeJS processes behind pound?
Are there benchmarks?

I'm asking this because our other binaries use less memory and run
slightly faster as 32 bit executables.
http://www.tuxradar.com/content/ubuntu-904-32-bit-vs-64-bit-benchmarks
hints the opposite - that V8 performance may be worse as a 32 bit
binary.

Just a note, that benchmark is for FireFox performance running http://v8.googlecode.com/svn/data/benchmarks/v5/run.html

I haven't done any benchmarks myself, and I would suggest that to *know* you should try running some in your environment. 

Thanks,

Chris.

P.S. What would the impact on npm be?  Would it be better to maintain
a 32 bit (VM) system for NodeJS/npm builds, and ship all binaries
(NodeJS and npm C++ packages) wholesale onto the 64 bit servers?
P.P.S. getlibs: http://ubuntuforums.org/showthread.php?t=474790

--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.

[Egor Egorov]

V8 3.0-3.1 is much slower on 64bit than on 32bit machines due to the fact that crankshaft optimizer is disabled. However if you recompile node.js with V8 3.2.x (it's easy ans works fine) you will have a huge speedup. 

[Fedor Indutny]

In which version 64bit crankshaft was landed?

According to this:

http://www.arewefastyet.com/?a=b&machine=8

http://www.arewefastyet.com/?a=b&machine=9

It's at least in a trunk

On Thu, Apr 21, 2011 at 4:25 PM, Egor Egorov <egor....@gmail.com> wrote:

V8 3.0-3.1 is much slower on 64bit than on 32bit machines due to the fact that crankshaft optimizer is disabled. However if you recompile node.js with V8 3.2.x (it's easy ans works fine) you will have a huge speedup. 

--

[Shripad K]

This is a good read:

http://neugierig.org/software/chromium/notes/2009/05/javascript-heap.html

Excerpt:

'I was chatting with a v8 developer about a 64-bit implementation and he had an interesting comment, which I'll now share with you*. One of the fears of 64-bit code is that all your pointers double in size, which means you get half the cache, twice the memory usage, etc.'

[Matt]

Let's hope they don't do that. 4GB limit is too low for server side JS.

[Vyacheslav Egorov]

Matt, limit for v8 heap is 1.7-1.9 gb on x64 (1gb on ia32) now. But
your server will start suffering noticeable full GC pauses before
hitting this limit.

My _personal_ opinion is that nobody should ever have more then 100 mb
of objects in JS heap. Everything beyond that should go to native heap
which is bounded only by OS/hardware limitations.

--
Vyacheslav Egorov

[Joe Developer]

On Thu, Apr 21, 2011 at 7:15 PM, Vyacheslav Egorov <veg...@chromium.org> wrote:

Matt, limit for v8 heap is 1.7-1.9 gb on x64 (1gb on ia32) now. But
your server will start suffering noticeable full GC pauses before
hitting this limit.

My _personal_ opinion is that nobody should ever have more then 100 mb
of objects in JS heap. Everything beyond that should go to native heap
which is bounded only by OS/hardware limitations.

 

Nod, it would seem odd to me that you would have anything near that much in-process data that you wouldn't want shared between node processes on the same machine.  Can someone share use-cases where one would want to have it process specific?

[Shripad K]

True. Since Javascript is single-threaded it makes no sense having a large v8 heapsize. It is recommended to run multiple processes. 

[Matt]

It might not make sense in your application (everyone here thinks "Node === Web" and can't see outside of that box). There are a lot of servers out there that might need more.

[Shripad K]

I do not talk about 'Node === Web' (which is partly true :) ). However I think you need to take the entire sentence. "Since Javascript is single-threaded it makes no sense having a large v8 heapsize"

See this from the same article: 

'His response, which this whole post was lead-in for, is that when you have that much memory it's difficult to actually make use of all of it from a language like JavaScript because it's single-threaded. That is, the time it takes to read in and out (or more importantly, process) that much data starts making apps that would use more data unuseful.'

[Joe Developer]

On Thu, Apr 21, 2011 at 8:00 PM, Matt <hel...@gmail.com> wrote:

It might not make sense in your application (everyone here thinks "Node === Web" and can't see outside of that box). There are a lot of servers out there that might need more.

That was why I was asking :) What situations are those? 

[Joe Developer]

On Thu, Apr 21, 2011 at 8:07 PM, Shripad K <assortme...@gmail.com> wrote:

I do not talk about 'Node === Web' (which is partly true :) ). However I think you need to take the entire sentence. "Since Javascript is single-threaded it makes no sense having a large v8 heapsize"

See this from the same article: 

'His response, which this whole post was lead-in for, is that when you have that much memory it's difficult to actually make use of all of it from a language like JavaScript because it's single-threaded. That is, the time it takes to read in and out (or more importantly, process) that much data starts making apps that would use more data unuseful.'

Well, I can see situations where you might not be reading in all that data, but generating it as a part of what you are dealing with, but those situations seem, offhand, fairly far between, and there is even further between cases where you need both to keep the full generated data in memory AND you don't want persistence for it AND you see no benefit in sharing it between processes.

I am curious to hear what Matt is seeing. 

[Matt]

On Thu, Apr 21, 2011 at 9:08 AM, Joe Developer <joe.d.d...@gmail.com> wrote:

On Thu, Apr 21, 2011 at 8:00 PM, Matt <hel...@gmail.com> wrote:

It might not make sense in your application (everyone here thinks "Node === Web" and can't see outside of that box). There are a lot of servers out there that might need more.

That was why I was asking :) What situations are those? 

Honestly there's a gazillion...

How about a mail server serving 100k concurrent connections?

A web server with a two-level cache (local memory then memcached)?

Just about anything related to finance.

A large in-memory trie structure that needs to be accessed via a network request.

An IPv6 blocklist.

I can keep going, but these kind of memory restrictions only make sense in a web browser IMHO.

Matt.

[Joe Developer]

On Thu, Apr 21, 2011 at 9:03 PM, Matt <hel...@gmail.com> wrote:

On Thu, Apr 21, 2011 at 9:08 AM, Joe Developer <joe.d.d...@gmail.com> wrote:

On Thu, Apr 21, 2011 at 8:00 PM, Matt <hel...@gmail.com> wrote:

It might not make sense in your application (everyone here thinks "Node === Web" and can't see outside of that box). There are a lot of servers out there that might need more.

That was why I was asking :) What situations are those? 

Honestly there's a gazillion...

How about a mail server serving 100k concurrent connections?

A web server with a two-level cache (local memory then memcached)?

Just about anything related to finance.

A large in-memory trie structure that needs to be accessed via a network request.

An IPv6 blocklist.

I must admit that I don't find keeping the data in-process particularly appealing for any of those. 

I am not arguing that the limit should be sought retained, but I think that in-process memory on that scale seems fairly odd. 

IPv6 blocklists would likely be too large for any in-memory solution unless you are talking 'super computer' sized hardware, if you are talking about spam or botnets.

If you have that kind of traffic I would imagine that you want to be able to share a caching queue between the processes rather than have each process do their own lookups, even if they are local to the process. 

Throwing the data into fx a ramdisk and / or having an efficient query engine / queue  talking with your node processes seems a bit more sane. 

I can keep going, but these kind of memory restrictions only make sense in a web browser IMHO.

Well, I am not sure that they make sense there either - certainly we are going to see games running up against that fairly soon. 

Matt.

[Matt]

On Thu, Apr 21, 2011 at 10:43 AM, Joe Developer <joe.d.d...@gmail.com> wrote:

On Thu, Apr 21, 2011 at 9:03 PM, Matt <hel...@gmail.com> wrote:

On Thu, Apr 21, 2011 at 9:08 AM, Joe Developer <joe.d.d...@gmail.com> wrote:

On Thu, Apr 21, 2011 at 8:00 PM, Matt <hel...@gmail.com> wrote:

It might not make sense in your application (everyone here thinks "Node === Web" and can't see outside of that box). There are a lot of servers out there that might need more.

That was why I was asking :) What situations are those? 

Honestly there's a gazillion...

How about a mail server serving 100k concurrent connections?

A web server with a two-level cache (local memory then memcached)?

Just about anything related to finance.

A large in-memory trie structure that needs to be accessed via a network request.

An IPv6 blocklist.

I must admit that I don't find keeping the data in-process particularly appealing for any of those. 

I am not arguing that the limit should be sought retained, but I think that in-process memory on that scale seems fairly odd. 

It's all about performance. Accessing anything "shared" be it on file or over the network is several orders of magnitude slower than accessing from local memory (I seem to recall something like 600 cycles for memory vs 1million for disk access, more for network).

Sure, using async I/O can make that process able to use any idle time efficiently (except for disk access - that's very much imperfect even with node), but it still becomes relevant to user experience and response times.

Matt.

[Joe Developer]

Nod, but that is a false choice - you don't have to use network protocols or disk - you can use a suitable storage / query / caching queue solution - that does not have those memory limitations and then you get caching across multiple node processes as a bonus. 

This communication can be via IPC or something custom in C if you want. 

Yes, you might lose a bit of performance, and this might be made up for by the efficiency of the external, shared caching queue, it depends on the actual situation. Even if in-process, sifting through 10 gb data isn't free. 

[Louis Santillan]

To get better performance out of a uni-process language like JS, you
need SIMD (http://en.wikipedia.org/wiki/SIMD#Software) or some other
form of vector computation. In the ia32/x86-64 world, that means MMX
(http://en.wikipedia.org/wiki/MMX_%28instruction_set%29), 3Dnow!
(http://en.wikipedia.org/wiki/3DNow!), SSE*
(http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions) or any of the
modern GPU architectures. On ARM, there's NEON
(http://en.wikipedia.org/wiki/ARM_architecture#Advanced_SIMD_.28NEON.29).
And the applications that currently use them are well defined (2D/3D
graphics, transcoding, large mem ops).

-Louis

[Egor Egorov]

On Thursday, April 21, 2011 3:15:07 PM UTC+3, veg...@chromium.org wrote:

My _personal_ opinion is that nobody should ever have more then 100 mb
of objects in JS heap. Everything beyond that should go to native heap
which is bounded only by OS/hardware limitations.

Do node Buffers count as JS heap? 

 

--
Vyacheslav Egorov

[Vyacheslav Egorov]

Their backing storage resides outside of JS heap so no.

100 mb might a bit harsh... I just find the idea of large in-memory
storage engines built in pure JS a bit disturbing.

--
Vyacheslav Egorov

[Matt]

As the performance of V8 approaches that of even Java, why wouldn't we build any kind of app in Node? Including those with high memory requirements.

[Ryan Dahl]

On Tue, Apr 19, 2011 at 10:25 PM, Chris Dew <chri...@barricane.com> wrote:
> Hi, we run NodeJS in production and I want to ask some performance
> questions.
>
> We use Ubuntu Server AMD64.  We run multiple, small non-NodeJS
> binaries which we have compiled as 32 bit executables.  Our servers
> have enough cores/processes that system RAM would be exhausted if each
> malloc'd its maximum 2GiB of addresss pace - i.e. the 2GiB/process
> address space limit is not an issue.
>
> Is there any advantage to using 32 bit NodeJS on a 64 bit
> architecture, when running ten or more NodeJS processes behind pound?
> Are there benchmarks?
>
> I'm asking this because our other binaries use less memory and run
> slightly faster as 32 bit executables.
> http://www.tuxradar.com/content/ubuntu-904-32-bit-vs-64-bit-benchmarks
> hints the opposite - that V8 performance may be worse as a 32 bit
> binary.
>

The x86 V8 is more mature than the x64 one. In Node v0.4 (which
corresponds to V8 3.1) the runtime optimization engine, crankshaft, is
enabled by default on x86 but disabled by default on x64. (You can
enable crankshaft on x64 by doing using the --crankshaft command line
argument.) You'll get better performance out of x86.

[Ryan Dahl]

On Fri, Apr 22, 2011 at 6:44 AM, Matt <hel...@gmail.com> wrote:
> As the performance of V8 approaches that of even Java, why wouldn't we build
> any kind of app in Node? Including those with high memory requirements.

The sky-high abstractions that the JVM and V8 provide like garbage
collection are not appropriate for programs that need many gigabytes
of memory.

[Matt]

There are plenty of apps written for the JVM that use gigabytes of memory.

Why are we being shortsighted on this? 640k is enough for everyone?

Matt.

[Matt Ranney]

On Fri, Apr 22, 2011 at 6:13 PM, Matt <hel...@gmail.com> wrote:

There are plenty of apps written for the JVM that use gigabytes of memory.

I think we'll get there, but it just hasn't happened yet.  The primary user of JavaScript VMs is a web browser.  Web browser applications do not yet have massive memory requirements from JavaScript.  As web browsers and web applications continue to get more powerful, surely the VMs will get more sophisticated about how they manage larger amounts of memory.

Until then, keep your big chunks of memory in core using Buffers or shared via something like Redis.

[Egor Egorov]

On Friday, April 22, 2011 4:34:25 PM UTC+3, veg...@chromium.org wrote:

100 mb might a bit harsh... I just find the idea of large in-memory
storage engines built in pure JS a bit disturbing.

Some people may even find the server side in pure JS a bit disturbing but here we are :)