Re: Can Someone Change My Mind About .NET?
From: Willy Denoyette [MVP] (willy.denoyette_at_pandora.be)
Date: 04/30/04
- Next message: Marina: "Re: Justification of using C# over VB.NET"
- Previous message: William Stacey [MVP]: "Re: Can Someone Change My Mind About .NET?"
- In reply to: Olaf.Baeyens_at_skyscan.be: "Re: Can Someone Change My Mind About .NET?"
- Next in thread: Willy Denoyette [MVP]: "Re: Can Someone Change My Mind About .NET?"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 30 Apr 2004 18:42:59 +0200
See inline ****
Willy.
<Olaf.Baeyens@skyscan.be> wrote in message
news:409244ba$0$25074$a0ced6e1@news.skynet.be...
>> > Windows core is still unmanaged and .NET prigrams must go through that
>> > transition every time. When Longhorn is out, it wil be reversed. .NET
> will
>> > be faster than conventional executables now.
>>
>> That would be cool if that was the case. However I don't think that is
> so.
>> Win32 is not going away with LH. WinFx classes will still need to call
>> Win32 apis in many cases. Even if a class does not pinvoke a win32 api,
> why
>> would it be any faster then a comparable method in native win32? Maybe
> the
>> same, I don't see how faster. That would be nice however if wrong.
>>
> Simple, more an more Win32 API is beeing replaced by .NET variants.
**** Hmmm... which Win32 API's have been replaced sofar?
More and more win32 API's are introduced by now (see W2K3 and LH).
> That means that .NET programs have less and less transitions from managed
> to
> unmanaged to do.
*** No that's not true, .NET is built upon Win32, somehow, it will allways
need to transition between managed and Win32 for system services.
>
> But for existing Win32 executables, the will need Win32 API's that wraps
> functionality to the .NET core.
> That means that Win32 executables must go from unmanaged to managed code
> transitions. So they will slow down.
*** And break alot of existing applications, do you realy think the Server
and Office folks at MS are willing:
- to pay this perf. hit?
- to compromise the reliability of their server?
>
> .NET programs will be faster because the CLR gets better and better.
> At this moment, conventional exe works at its best perfocramence because
> of
> the compiler that optimizes it for the current known processors.
> If you do not recompile the .NET applcation and conventional program, you
> would see that the .NET version gets faster and faster compared to the
> conventional program butcause JIT v2.0 will optimize for the most recent
> processor while the conventional application is still stuck to the Pentium
> IV optimizations.
>
*** Don't overestimate the power of the JITter, he's heavily constrained by
the "time to optimize", and don't overestimate the power of the newer
processor family.
Don't forget that the latest native code compilers also generate better &
faster code, and that parts of the system cannot afford the overhead of the
GC both in time and space (think about drivers and core windows component
like the memory manager, scheduller, interupt handler....). And here I'm not
gonna talk about robustness, but why do you think Yukon and .NET 2.0 are
getting delayed?
> Conventional executables are static in nature. all methods and functions
> are
> laid out in a certain memory order at the moment you compiled and linked.
> .NET programs are dynamic in nature. Future JIT compiler might perform
> statistics what function is use how often, and might relocate it in a
*** "might", yes but officially anounced, no. For the moment MS has other
performance issues to solve which have much more impact than some profile
guided JITter.
> different memory block so the the most used functions are grouped together
> in a small memory address space, ready to be cached more often. Also .NET
> programs written in pure OOP way is now far more performant compare to the
> OOP version of a C++ unmanaged. because it does not need to delete small
> memory memory bloks every time stalling then program. .NET starts deleting
> the memory when it either needs memory, or if it can find some time to
> start
> cleaning up.
>
> Just be aware! .NET is NOT an interpreter, It compiles the complete code
> to
> pure win32 code but optimized for your processor. When JIT matures, it ill
> become even better optimizer.
>
> Another thing that must be taken into mind, is the fact that .NET programs
> also implements security at the low level standard.
> You should compare Win32 functions with also this type of level of
> security
> build in. If I remember correctly a web page counter extension for
> Frontpage
> 97 could be misused to take over the server. A stupid prgram that only
> intended to show a bitmap on screen was misused. This is why all programs
> now created should have this security integrated default.Even if it is a
> simple screen saver, it could be misused by a worm. (examples enough: e.g.
> windows help file could be used to take over your computer) Maybe next
> Solitair....
>
> But this is my opinion? I really believe that this .NET is the way to go,
> and I admit that I also fight against it to have my code work. ;-)
>
>
- Next message: Marina: "Re: Justification of using C# over VB.NET"
- Previous message: William Stacey [MVP]: "Re: Can Someone Change My Mind About .NET?"
- In reply to: Olaf.Baeyens_at_skyscan.be: "Re: Can Someone Change My Mind About .NET?"
- Next in thread: Willy Denoyette [MVP]: "Re: Can Someone Change My Mind About .NET?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
