Re: 64-bit memory consumption

Eric Grange <egrangeNO@xxxxxxxxxxxxxxx> wrote:

Alas, threaded garbage collecting has many issues, [...] (ie. in practice
it means that it works only if your threads are sleeping).

I think you might have misinterpreted me, or I didn't make myself clear
- I'm not talking about incremental GC (i.e. running in parallel with
user code), but the fact that larger memories can be scanned just as
fast as smaller memories because the GC itself can run on multiple
threads in parallel when collecting.

Of course, my application domain was application servers, so I didn't need
SSE etc. Time spent in GC never exceeded 2% or so.

There is time spent in GC that won't be affected only to the GC cycles,
you get indirect hits in the form of poor cache coherency and cache
pollution in the code that uses GC'ed memory.

I've found exactly the opposite: because of GC memory compaction, the
type of application (request/response) and its pattern of memory
allocation (big chunk up front at initialization, lots of small
short-lived structures during processing), CPU cache utilization is
*improved* over manual allocation.

3) A "SIMD sublanguage" in MSIL, perhaps designed along the lines of

This would give the option of hand-tweaking, beyond internal calls
manipulating intrinsics, if there was a good and natural mapping from
the instructions to the underlying hardware capabilities.

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

I'm not holding my breath :)

From the improvements I've seen from .NET 1.0 -> 1.1 -> 2.0, I think the
pace of change and the increase in quality is pretty amazing for a
company of Microsoft's size.

I find it hard to believe I've only been using .NET 2.0 since last July
or so. .NET 1.1 seems like something from a bygone era, old and crufty.

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.

Well, this doesn't really have to be expected, 'old' compiler technology
like the one in Delphi doesn't suffer from such tight peepholes, even
though its compilation speed is very similar to that of the JITter

It is to be expected that the machine that a compiler targets code for
is itself affected by that targeting, via a feedback mechanism. The
people at Intel and AMD focus on optimizing the kind of code that
today's object-oriented compilers produce, and the MSIL "abstract
machine" is no different - and because of its mutable nature, the
feedback effects are increased. Instructions that exist in MSIL yet
aren't produced by the C# compiler (such as tail.call, which I've
discussed in my blog at
http://barrkel.blogspot.com/2006/05/clr-tailcall-optimization-or-lack.html)
are hardly optimized at all.

(it's
faster than C#->IL for sure, and from a subjective point of view, I
would say it's also faster to go from .pas to x86 opcodes than from IL
to x86 opcodes).

I don't agree with that assertion for the kind of code I write. Quite
the contrary: I've seen speedups of 80% and more simply recompiling
Delphi code with Delphi.NET.

This isn't code that deals with vector operations or low-level pointer
arithmetic, but code that manipulates and allocates large object graphs.

Of course, with Delphi/Win32, you always have recourse to asm/end, which
isn't available without significant penalty in the managed world.

[...] on a
server, your cache is shared by multiple applications, and you can't
appropriate it all for your application's purpose without affecting the
rest.

On the contrary - on a server, you're usually the *only* application of
any importance running (if your application is mission critical, that
is), and when your throughput is strictly limited by CPU, then you get a
full slice to take advantage of the cache etc.

In a few years, the hardware might have caught up to hide current .Net
shortcomings, but who will still be using current .Net in a few years?

This is another good point - currently compiled code will benefit for
free on existing hardware as improved .NET runtimes become available.

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).

ASP.Net does *not* count as real GC-based application, more like as
script language's GC, as all its GC memory gets regularly cleaned up
(and IIS core itself isn't using it for its own needs).

I don't understand your assertion. From the perspective of ASP.NET in
the application server I was most lately involved in, the most
significant thing used was the .ASHX handler (i.e. a HTTP handler) to
provide a simple gateway to a whole separate framework. No ASP.NET code
was allocating objects, and there were no .ASPX files on the server. It
was simply a CLR host.

The ASP.NET ISAPI plugin hosts the .NET runtime, so it controls
AppDomain recycling - that's what I refer to when I'm talking about
recycling.

As for .net-based services, I've had one case where a .Net service ended
up locking up a server we were running on despite having no leaks to
speak off: the server had an extended period of CPU load, so GC didn't
kick until it was too late and swapping hell had begun. Server was
physically stopped after a few hours, .Net service got moved to its own
machine.

That sounds like anecdotal evidence of a badly programmed system, hardly
a critical flaw in .NET.

Never had any trouble with .Net used for scripting-level tasks (as in
ASP), and IMO that's all the current GC is really capable of handling
reliably: tasks that work for a limited amount of time, and whose memory
allocations are guaranteed to be cleaned up as a whole (rather than
relying on the GC to do it).

I don't know - I've never used .NET for scripting-level tasks.

-- Barry

--
http://barrkel.blogspot.com/
.

Relevant Pages

  • Re: Allocated Memory alerts
    ... If you do not encounter any real server performance issue, ... the high memory usage is expected. ... The Health monitor is running on the SBS server. ... A memory allocation threshold is configured on the particular monitored ...
    (microsoft.public.windows.server.sbs)
  • Re: Typecasting in C
    ... > warnings) you set higher warning level. ... a slower, less capable Xeon server. ... enough memory sticks to fill up the address space. ... The main point still is that a compiler should support portability of code ...
    (comp.lang.c)
  • Re: Mex Overflow Error Using Free Borland Compiler
    ... > I need help eliminating the source of the following Mex runtime error. ... > Borland compiler handles overflow errors. ... > The first thing I tried is dynamic memory allocation. ...
    (comp.soft-sys.matlab)
  • Re: Installation Question
    ... Each server application has its own resource allocation technique. ... suppose you have 8GB of memory -- ... For Analysis Services, if you use Analysis Manager and right-click on the ...
    (microsoft.public.sqlserver.olap)
  • Re: Benchmark: STLs list vs. hand-coded one
    ... bound - in fact it is hard to find anything in a compiler that isn't ... allocation bound (perhaps the scanner as it spends a rather large ... How many people have a Gbyte of memory? ... seems to have a gig of RAM. ...
    (comp.arch.embedded)