Re: 64-bit memory consumption

Eric Grange <egrangeNO@xxxxxxxxxxxxxxx> wrote:

One has to wonder what the point of using .Net to target 64bit would be,
since two important benefits are negated by design:
- GC already has trouble coping with hundreds of megabytes worth of
objects, and with gigabytes, it's not really improving (euphemism).

A nice side effect of future developments is that with more cores, the
scanning of gen 2 (i.e. the big bit) can be done in parallel. As long as
CPU cores and memory keep pace with each other, this shouldn't really
get slower.

Speaking for my own development on .NET, I have found it to be extremely
fast - although apps requires 2-3x more memory than in the past. Of
course, my application domain was application servers, so I didn't need
SSE etc. Time spent in GC never exceeded 2% or so.

- IL doesn't support vector floating-point, so the benefits of
standardized SSE2 support are lost.

..NET is the wrong tool for fast vector SIMD code, and that isn't its
target market.

I can think of three possible ways this could be improved in the future:

1) Supply .NET valuetypes that the CLR has intrinsic knowledge about.
Operators on these valuetypes can be internal calls, so the JIT can
exercise extra information on them.

2) Give the JIT extensive knowledge of certain idioms produced by the C#
compiler for vector-style code, so it can extract possible SIMD
implementations. This is a much longer shot than option (1).

3) A "SIMD sublanguage" in MSIL, perhaps designed along the lines of
current shader assembly languages that we see these days in GPUs. See
http://microsoft.cs.msu.su/projects/ilshaders/ilshaders.pdf for example.

- JITter (so far) doesn't seem to be able of making good use of the
extra registers, this may improve, but there are still quite a few
roundtrips to memory and stack juggling in there, unless you're lucky
enough to hit one of the few peephole optimizations.

I definitely expect register usage to improve - MS are hardly going to
stand still.

The "peephole" optimizations in .NET are directly related to common C#
idioms and the IL the current MS C# compiler emits for those idioms. So,
whether one is implementing an algorithm in C# or implementing a code
generator for MSIL, the code pattern to stick to is the "natural" one
for C#. I think this is only to be expected.

A side effect of larger pointers in .Net is that as objects get bigger,
they also become more likely to end up in generation 1+, which are less
often GC'ed, and thus it ends up inflating memory usage even more.

The size of Gen0 is directly proportional to the CPU cache size, so
again, as CPU caches get bigger, this won't make a huge difference.
Speaking from personal experience, GC has never been a problem on
multi-CPU machines in a server environment, under heavy throughput for
many hours (ASP.NET performs appdomain recycling, so days doesn't
apply).

-- Barry
.

Relevant Pages

  • Re: large binary immediately SEGVs
    ... said even running ldd on the load module caused ldd ... insisted in reducing any problem to a 4 assembler-level instruction ... memory, the text to be printed was clearly "Ready: ... Now you do not just walk into a design review and throw different ...
    (comp.os.linux.misc)
  • Re: IVR Capcity
    ... >May you please explain to me better the design issues of point 2? ... interface to 10-15 separate gigabit-Ethernet 'local' network segments. ... you have to be able to transfer it from main memory to the output device ... speeds of _2_ gBytes/sec. ...
    (comp.dcom.telecom.tech)
  • Re: OOP - a question about database access
    ... >> and not an existing database is IMO the correct approach. ... > design and OO design evolve almost in parallel (or course DB design can ... send method calls to modify the needed object data in memory ... theory offset the losses incured by a framework based memory-to-DB transactional ...
    (comp.object)
  • Re: What application frameworks exist for Delphi?
    ... However if you do design one to one or one to many ... insist on handling the deletes itself when the database has a simple ... I have several employees in memory and run a batch update to increase all ... high-efficiency batch operations, and keep the in-memory object model ...
    (borland.public.delphi.non-technical)
  • Re: Exact mechanics of a system call
    ... want to do a syscall interface, ... That depends on the ABI design which would specify what instructions ... to be stored into virtual memory that has no associated real memory, ... OSes use some appropriate trapping CPU instruction on ...
    (comp.os.linux.development.system)