Matthew Wilson wrote:
> That's not really what I was suggesting.
> 
> I'm saying that if a (single instance of a) C++ app had a footprint of 2MB,
> it's likely that an
> equivalent C# one would be 23MB, rather than 400MB.

OK, I see what you are saying.

Sure, I also don't think a 2MB C++ app would be 200MB if
done in C#, but look at what I wrote below. The start
of an app I wrote in C# is 8MB (per copy running.) A
C# app with a moderate amount of functionality is 21MB.

I wouldn't have guessed that a moderately featured
C# app would be 21MB, so I'm not going to assume
the overhead is very fixed, just because I've already
been suprised at the massive memory use so far. What
I've come to expect for memory use doesn't seem to
apply to .NET.


> I would have a *very* hard time swallowing the latter, and frankly .NET
> would not be viable if that were the case.
> 

I bet that people who think that all good programs
are written in assembler are already having a hard
time swallowing .NET.


> 
> "Frank Wills" <fdwills@sandarh.com> wrote in message
> news:bgskt3$2bd8$1@digitaldaemon.com...
> 
>>Matthew Wilson wrote:
>>
>>>"John Reimer" <jjreimer@telus.net> wrote in message
>>>news:3F31CB6A.4000406@telus.net...
>>>
>>>
>>>>>I was disappointed that MS went the route of using a VM. C# is
>>>>>really nice to use, but a full featured app that I had written in
>>>>>C++ has a memory footprint of about 175K. Just the start of a
>>>>>rewrite of that app in C# has a memory footprint more that 100
>>>>>times larger at 21,000K.
>>>>>
>>>>
>>>>Excuse me?! You mean almost 20 MB? Woah! Who would want to use C# if the
>>>>app ends up that big?  I can hardly imagine people supporting and using
>>>>such a technology!
>>>
>>>
>>>For all that I find such bloat inexcusable (not to say risible!), it is
> 
> not
> 
>>>the case that the memory sizes are integral multiples of each other,
> 
> more
> 
>>>likely (though not absolutely) that it represents a fixed overhead, ie.
>>>
>>>C++          C#
>>>175K        20MB
>>>2MB         23MB
>>>4MB          26MB
>>>
>>>and such. (Of course, I just invented thos figures ...)
>>>
>>
>>Well, I guess that shows what happens when
>>you invent figures! ;) Actually I would have
>>expected that same thing myself, but alas
>>it is not so.
>>
>>The C++ app is all C++, so there is little
>>overhead, and it's memory usage per copy is
>>linear.
>>
>>The 20MB C# app can only run one copy, but
>>a second C# app that I just started uses
>>8,000K (8MB), and each additional copy uses
>>another 8MB. It's memory usage is also linear.
>>Ten copies of this start of a C# app uses
>>10 x 8MB = 80MB.
>>
> 
> 
> 
> 

> > I would have a *very* hard time swallowing the latter, and frankly .NET would not be viable if that were the case.
> >
>
> I bet that people who think that all good programs
> are written in assembler are already having a hard
> time swallowing .NET.

Mate, people who think good programs are written in C or C++ are having that same hard time!

Makes you appreciate why they're not bothering supporting the .NET framework on old OSs (that are resident on systems with, say, 128MB or less memory - IIRC, NT 4 is not supported!).

:)

Matthew Wilson wrote:
>>>I would have a *very* hard time swallowing the latter, and frankly .NET
>>>would not be viable if that were the case.
>>>
>>
>>I bet that people who think that all good programs
>>are written in assembler are already having a hard
>>time swallowing .NET.
> 
> 
> Mate, people who think good programs are written in C or C++ are having that
> same hard time!
> 
> Makes you appreciate why they're not bothering supporting the .NET framework
> on old OSs (that are resident on systems with, say, 128MB or less memory -
> IIRC, NT 4 is not supported!).
> 
> :)
> 

NT 4.0 was supported in .NET 1.0, but they dropped it
in .NET 1.1. MS claims that they didn't have the
resources to support .NET on NT 4.0. Yeah, right.
Like I believe that.

I'm still using NT 4.0. I've purchased Win2K as a safety
backup, but I'm doing all I can to move to *BSD and Linux.
No way do I ever want to use anything from MS beyond Win2K.

Frank Wills wrote:

>> Excuse me?! You mean almost 20 MB? Woah! Who would want to use C# if the app ends up that big?  I can hardly imagine people supporting and using such a technology!
>>
>> I had no idea...

What's so wrong with it? And who says it has to stay like that? Personally, i would avoid MS libraries using .NET, so that one can take advantage of alternative VMs which will probably be better with time... and are not Windows-bound.

It may have something to do with loading strategy. Like, SUN Java VM - a real bloater - loads many parts of the library at once, while IBM Java VM rather waits until they are actually needed. They both share the same library.

The large memory footprint can also be a fake in some cases - like when you load files as memory-mapped, but never read some parts of them.

-i.

Ilya Minkov wrote:
> 
>>> Excuse me?! You mean almost 20 MB? Woah! Who would want to use C# if the app ends up that big?  I can hardly imagine people supporting and using such a technology!
>>>
>>> I had no idea...
> 
> 
> What's so wrong with it? And who says it has to stay like that? 

It may not, or it may get worse. I don't have much confidence in
MS going in the direction of requiring less hardware resouces. I
don't run WinXP, nor do I have access to the alpha/beta Longhorn,
but I've read that with the new database file system a machine
that runs Win2K or WinXP fairly well gets bogged down pretty well
running Longhorn.

> Personally, i would avoid MS libraries using .NET, so that one can take advantage of alternative VMs which will probably be better with time... and are not Windows-bound.

Do you like VMs? Just curious.

> It may have something to do with loading strategy. Like, SUN Java VM - a real bloater - loads many parts of the library at once, while IBM Java VM rather waits until they are actually needed. They both share the same library.

Yeah. Someone could develop a .NET VM that might be a lot leaner, faster.

> The large memory footprint can also be a fake in some cases - like when you load files as memory-mapped, but never read some parts of them.
> 
> -i.
> 
I think it is. I've tried to load the system down with lots of C# apps
running at once, and even though the system Task Manager shows that
they are each consuming the same large amount of memory, the machine
stlll continues to run, whereas it would choke on the memory load if
non .NET apps were consuming that much memory.

The .NET framework runtime library is roughly 20MB, so I imagine that's why your application is taking up so much memory during runtime. Your own app's code probably occupies less than 1MB of memory.

The .NET runtime is a very very fancy bit of engineering. It can do lots of interesting things, like creating a set of permissions for dependant code. For example, you could write an app with plugin support, and limit the abilities of any plugins (plugins may not read or write from disks, etc.) even if those plugins are writtn by 3rd party developers.

But, if you're not using very many of these cool capabilities of the .NET framework, you're getting short-changed. Personally, I think the .NET framework should be broken into lots of little pieces that can each be loaded when needed. And, I suspect that that's exactly what will happen in the next five years or so.

--Benji Smith

In article <bgsnfr$2djt$1@digitaldaemon.com>, Frank Wills says...
>I wouldn't have guessed that a moderately featured
>C# app would be 21MB, so I'm not going to assume
>the overhead is very fixed, just because I've already
>been suprised at the massive memory use so far. What
>I've come to expect for memory use doesn't seem to
>apply to .NET.

Benji Smith wrote:
> The .NET framework runtime library is roughly 20MB, so I imagine that's why your
> application is taking up so much memory during runtime. Your own app's code
> probably occupies less than 1MB of memory.

One C# app that I wrote, which uses 21 MB of memory, has
only 0.035 MB of code. Compiled, the exe is 0.057 MB.

Another C# app that I had just started, which uses 8 MB
per copy in memory, has 0.0007 MB of code (that's not
a typo.) Compiled, the exe is 0.005 MB.

> The .NET runtime is a very very fancy bit of engineering. It can do lots of
> interesting things, like creating a set of permissions for dependant code. For
> example, you could write an app with plugin support, and limit the abilities of
> any plugins (plugins may not read or write from disks, etc.) even if those
> plugins are writtn by 3rd party developers.

Yes, except for the VM (I dislike VMs), and the huge resource cost,
and the distribution difficulties, and the MS product tie-in (it
forces people to keep upgrading their OS), it is pretty slick (think
honey pot for programmers.)

> But, if you're not using very many of these cool capabilities of the .NET
> framework, you're getting short-changed. Personally, I think the .NET framework
> should be broken into lots of little pieces that can each be loaded when needed.
> And, I suspect that that's exactly what will happen in the next five years or
> so.

Some of that is done already. Apps tend to have a memory footprint
relative the Foundation components used. A small app can be under
10MB. I'm sure they will improve .NET, but I doubt that without
some kind of serious market pressure .NET will grow smaller. I've
never seen MS make anything grow smaller. When NT 3.0 came out it
could hardly run on the 486s that were available at the time. NT
has only grown bigger (and changed names). I wonder what WinXP
would be like on a 486 with 32 MB of RAM.

> 
> --Benji Smith
> 
> In article <bgsnfr$2djt$1@digitaldaemon.com>, Frank Wills says...
> 
>>I wouldn't have guessed that a moderately featured
>>C# app would be 21MB, so I'm not going to assume
>>the overhead is very fixed, just because I've already
>>been suprised at the massive memory use so far. What
>>I've come to expect for memory use doesn't seem to
>>apply to .NET.
> 
> 
> 

Benji Smith wrote:
> The .NET framework runtime library is roughly 20MB, so I imagine that's why your
> application is taking up so much memory during runtime. Your own app's code
> probably occupies less than 1MB of memory.
> 

That makes sense.

> But, if you're not using very many of these cool capabilities of the .NET
> framework, you're getting short-changed. Personally, I think the .NET framework
> should be broken into lots of little pieces that can each be loaded when needed.
> And, I suspect that that's exactly what will happen in the next five years or
> so.

Broken into lots of tiny pieces, I agree with.  As to where it should be fed... well I could offer some suggestions ;-).  I just can't stand huge bloated technologies, no matter how masterful the engineering is.

One technology that has been doing this sort of thing marvelously well for several years is Taos Intent.  Mind you, it doesn't achieve quite the same goals as .NET.  It's a very nifty cross-platform technology in a very small footprint.  It operates on the principle of tiny "tools," code units that are loaded/translated as needed. Several languages compilers have been ported to it's OS layer.

Tao seems to appeal much more to the old-school assembler/embedded programmer types.  Still it's making some headway.  Anyone familiar with Tao?

Later,

John

Frank Wills wrote:

> Do you like VMs? Just curious.

I *HATE* it when i direct my browser to some webpage... and then it locks up for half a minute. What's up? SUN Java loading! Thanks to IBM VM, it got much better now. :)

I think there is much future with VMs. I believe i posted some material about Tick C - which is a compiler which generated executables carrying a tiny VM with them, maybe 100k or so... What for? It instantieates templates at run-time.

The good thing about this is, there are many values in programs which get settled in the beginning, and stay the same during the whole program runtime. You cannot hardcode them as constants - although coneptually they are. That's what Tick C does: depending on what data you have, it may be compiled, inlined, and optimised into the code.

The optimiser in Tick C is really crappy, and would usually generate code almost half as fast as an optimising compiler. Nontheless, when used to generate a code to multiply a vector by a constant martix, it would outscore GCC by a few times, and was even faster than GCC when used as a GIMP plug-in for simple image processing. You see, that's where the future might go - at least what sound, video, and image processing conserns, where you apply the same operation very often.

I myself have been interested in Structural Audio, and have been intending to write an efficient sound processing VM. After avaluating all kinds of compilers, i had more or less an idea of what it should be like, technically. Java VM in its current form was not even considered. But with time, i stumbled over .NET, and the MONO project. .NET alone seems to get much more right than Java does - and IMO was an objious step which someone *had* to do. The JIT-compiler from MONO will be available not only internally, but is also developed to be be easy to embed in own projects. I think i even contributed some very minor JIT idea. The current one is about the level of Tick C, the next one should be significantly better.

New VM-based languages pop right out of the floor! A decent-performance and very tiny Demoscene-related (OpenGL+libSDL) VM appeared just 2 months ago -- targeted at high-performance visual effects!

> Yeah. Someone could develop a .NET VM that might be a lot leaner, faster.

Hope so. And if development is so open and well-modularized as it is with MONO, research instututions would also be eager to use it to test their optimisation ideas... What do we get? Accumulated power!

>> The large memory footprint can also be a fake in some cases - like when you load files as memory-mapped, but never read some parts of them.

> I think it is. I've tried to load the system down with lots of C# apps
> running at once, and even though the system Task Manager shows that
> they are each consuming the same large amount of memory, the machine
> stlll continues to run, whereas it would choke on the memory load if
> non .NET apps were consuming that much memory.

This is interesting.

-i.

Ilya Minkov wrote:
> Frank Wills wrote:
> 
>> Do you like VMs? Just curious.
> 
> 
> I *HATE* it when i direct my browser to some webpage... and then it locks up for half a minute. What's up? SUN Java loading! Thanks to IBM VM, it got much better now. :)
> 
> I think there is much future with VMs. I believe i posted some material about Tick C - which is a compiler which generated executables carrying a tiny VM with them, maybe 100k or so... What for? It instantieates templates at run-time.
> 
> The good thing about this is, there are many values in programs which get settled in the beginning, and stay the same during the whole program runtime. You cannot hardcode them as constants - although coneptually they are. That's what Tick C does: depending on what data you have, it may be compiled, inlined, and optimised into the code.
> 
> The optimiser in Tick C is really crappy, and would usually generate code almost half as fast as an optimising compiler. Nontheless, when used to generate a code to multiply a vector by a constant martix, it would outscore GCC by a few times, and was even faster than GCC when used as a GIMP plug-in for simple image processing. You see, that's where the future might go - at least what sound, video, and image processing conserns, where you apply the same operation very often.
> 
Couldn't that kind of optimization be done without any kind of
VM? Just do the optimization when the code loads, but don't
add any kind of VM layer?

> I myself have been interested in Structural Audio, and have been intending to write an efficient sound processing VM. After avaluating all kinds of compilers, i had more or less an idea of what it should be like, technically. Java VM in its current form was not even considered. But with time, i stumbled over .NET, and the MONO project. .NET alone seems to get much more right than Java does - and IMO was an objious step which someone *had* to do. The JIT-compiler from MONO will be available not only internally, but is also developed to be be easy to embed in own projects. I think i even contributed some very minor JIT idea. The current one is about the level of Tick C, the next one should be significantly better.
That's pretty interesting. I found this article on Structural Audio
related to the twin towers in NY.
http://www.cyberclass.net/palmquist.htm

> 
> New VM-based languages pop right out of the floor! A decent-performance and very tiny Demoscene-related (OpenGL+libSDL) VM appeared just 2 months ago -- targeted at high-performance visual effects!
> 
>> Yeah. Someone could develop a .NET VM that might be a lot leaner, faster.
> 
> Hope so. And if development is so open and well-modularized as it is with MONO, research instututions would also be eager to use it to test their optimisation ideas... What do we get? Accumulated power!
> 
Yes, .NETs VM is in my opinion a much better thing than what
Java VMs tend to be. I wonder if .NET isn't more in the direction
of what you are talking about.

>>> The large memory footprint can also be a fake in some cases - like when you load files as memory-mapped, but never read some parts of them.
> 
> 
>> I think it is. I've tried to load the system down with lots of C# apps
>> running at once, and even though the system Task Manager shows that
>> they are each consuming the same large amount of memory, the machine
>> stlll continues to run, whereas it would choke on the memory load if
>> non .NET apps were consuming that much memory.
> 
> 
> This is interesting.
> 
> -i.
>