Re: Tech directions for Delphi?

[A bit long and a bit late - late nights have been playing havoc with
my schedule.]

Eric Grange wrote:

Flashback to the FastCode MM contest

I can't flashback to something that I didn't pay any attention to in
the first place. ;-)

Beyond that, so far as I know, there is no particular overhead in
allocating data in one thread and using it in another.

...have an overhead when data crosses thread boundary (gotta move it out of the
gen 0 heap it was created in).

No, you really don't. To the other thread, it's just another pointer.
To the creating thread, the other thread is just another root keeping
the data alive.

It's just another reference that may keep the data alive in its creating
thread's heap at the next gc.

And at the next gc... what happens?
Otherwise, how would you guarantee a gen 0 heap that is /per-thread/?

Nothing special. The data is promoted to gen 1, and relocated, same as
always. Yes, it's moved out of the per-thread gen-0 heap, but so is
any other data that's still alive. There's nothing special about
having a cross-thread reference, here.

Maybe I'm stupid today, but I don't really know what this means.

If you have object A in context of thread 1 refer object B in context of thread
2, GC'ing either of A and B will require to suspend threads 1 and 2 during the
compaction phase (during which data will be shiftedaround and references updated).

Yes. Garbage collection suspends all managed threads. So?

This is true. It is also true that a full gen 2 collection is quite
rare;

That depends on your data, what you're doing, and how large the data you're
manipulating is. If you data is too large to fit in gen 0, they will actually be
quite common,

Actually, that's incorrect. Allocation comes at the same cost than in a classic
allocator (FastMM actually allocates faster than .Net's GC),

That's impressive, as alloc on .NET is not much more than advancing a
pointer.

and deallocation is
*anything* but free, it just has a delayed cost, but the cost isn't free, and it
isn't negligible either (insane trashing from compaction comes to mind, or
insane hit misses from the mark phase).

Interesting choices of words. "Insane" is not the normal experience.

and that the costs are largely driven by the rare
persistent data (that needs to be relocated).

Why rare? It's rare if you're doing stuff like preparing a webpage, all data is
temporary sure, but if you're using it in a more general purpose application,
temporary data is quite a rarer sight than persistent data.

Not really. Most desktop apps build a relatively modest working set (a
few forms, say) and don't add to it all that much. Each event handler
may involve some string bashing or collection manipulation, but in
most cases the temps go away with the event handler. Apps that keep
building their working set (symbol tables, or various sorts of event
logs) are commonly used but are a small proportion of apps written.

First, alloc/dealloc aren't expensive, they're usually cheaper in practice than
their GC equivalents (unless you compare to crappy old allocators of course,
like the WinAPI heap allocator)

A few years back, a Borland R&D guy told me that he'd done some
profiling, and most Delphi apps spent most of their time in the memory
manager. If FastMM means that this is no longer true, that's very
impressive.

However, the case for .NET doesn't really rest on automatic memory
management being cheaper overall than manual memory management. It
would be nice if this were true - just one more advantage - but it's
not necessary. The real point of .NET is the productivity that you get
from automatic memory management; a fine library; object-oriented
dlls; and type-safety across modules.

what's better, a stall of a few cycles once every billion cycles, or a
whole system lockup every few minutes?

In practice, of course, .NET apps don't do "a whole system lockup
every few minutes." It is true that the design assumes that memory is
abundant, and that things can get expensive if you are using most of
the system's RAM and still keep creating temps, but it really is a
rare app that uses hundreds of megabytes of working memory.

(By coincidence, I'm working with one right now. The Netflix prize
database takes about half a gig, packed. I can run one app that loads
that into memory and does full-time calculations. By virtue of
appropriate thread priorities, I can use my system normally while
breeding weights or whatever. No impact on the foreground apps; no
system lockups; no swapping. Try to run two such apps simultaneously,
though, and everything else gets swapped out.)

The GC lockup means you can't guarantee continuity of system, and that a single
bad beheaving code snippet can impair the whole server. I fail to see how that
could be good...

You can always write bad code.

I have to confess, I only have a single-core P4 on my desktop, so I
have no direct experience. But from what I know about the .NET
architecture, and the way gc works with multi-core machines, the above
pp is just not right. Citations?

Not a citation but an observation, I have one case of a server that crashed
because of a GC: on a server with reasonnably tight memory, there was a
combination of .Net and non-.Net services running. At some point memory usage
went over physical RAM, so data got sent to the swap disk before the .Net
service could initiate a GC. When the GC happened, it happened on partly swapped
out data... after a few hours of the machine not responding much (even task
manager was choppy, and killing the offending app had no effect), it had to be
hard-rebooted. Later turns out .Net service was using the multithreaded (aka
workstation) GC, and apparently couldn't GC the swapped out memory faster than
it allocated new memory (CPU was always busy, GC didn't kick in before it was
too late).

So, from thrashing with low memory you jumped to "if you start sharing
a lot of data (because
you split work on multiple CPU, combine it back, etc.), it's no good.
It means
that things like microtasking, sharing a lot of data, running for
extended
period of times or with interactivity requirements can't be done
without
glitches and hiccups."?

--

..NET 2.0 for Delphi Programmers www.midnightbeach.com/.net
Delphi skills make .NET easy to learn Great reviews & good sales.
.

Relevant Pages

  • Re: Id appreciate your opinion(s)
    ... The fact that so much memory is used really doesn't mean you ... When it comes to all of the apps except for ones defined in the ... then I would say that .NET or Java are perfectly fine ... Java and .NET can both do "smart" clients, fat clients, or web-based ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: memory requirements of closed vs quit apps
    ... majority of programs remain open when all their windows are closed. ... they use bugger all memory - and are ... individual apps Real and Virtual memory entries. ... In order to push it out to swap, ...
    (uk.comp.sys.mac)
  • Re: memory requirements of closed vs quit apps
    ... Close those tabs. ... I'd imagine it's the OS just trying to work out which memory needs ... The UI thing is exacerbated by the behaviour of apps to ... IMO 1Gb of RAM should easily ...
    (uk.comp.sys.mac)
  • Re: Small C# program takes up too much memory
    ... They just see a number in Task Manager, and that our software is near the ... We're taking up too much memory, according to the list they're seeing (In ... We've had a number of customer evaluate using our stuff and then ... and end up building native Win32 apps. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: [RFC][PATCH 0/3] TCP/IP Critical socket communication mechanism
    ... under memory pressure no user applications are getting scheduled. ... > the management and other important sockets have priority over others in my app... ... The management apps will be pinned into ...
    (Linux-Kernel)