Is VC7 unmanaged code really 50 times slower than VC6?
Sarah Thompson
give or take a day or two. My immediate reaction was that the CLR
concept is a brilliant idea, but my code (unmanaged C++) felt a bit
slow. Amongst other things, I'm involved in a project that is
implementing a wide variety of parsers for various proprietary and
not-so-proprietary file formats, which has resulted in a number of
recursive descent parsers being written.
For test purposes, I wrote a parser that parsed a 300-ish line source
file. The recursive descent code needs some work, sure, but I was
shocked that it actually took something of the order of eight minutes
to complete. The code could stand some optimisation, but it
fundamentally isn't that bad (i.e. there is an initial lexer pass
using a deterministic FSA that is extremely quick, so the parser is
just working on tokens). As a sanity check, I compiled the same code
using VC++6, Intel C++ and gcc (the code is pretty much straight up
the middle ISO C++, nothing fancy). The latter compilers generated
code that completed in roughly 10 seconds in each case, give or take a
second or so.
Is code under the CLR *really* 50 times slower than 'old-fashioned'
native code? We're talking nearly 2 orders of magnitude here; the kind
of slowdown you'd expect from a tightly written bytecode interpreter,
not JIT compilation. Having scanned a fair bit of material about the
CLR concept, I'd have expected performance to be near enough
equivalent to native code, maybe a touch slower. But 50 *times*
slower??? Surely not! Running ngen on the assembly made no difference
beyond reduced load time, so it's not likely to be the case that bits
of my code were getting compiled on the fly, and in any case, all the
documentation I've seen indicates that the code generation happens at
load time rather than literally on a JIT basis. Or is this a wrong
assumption?
Thoughts that the slowdown could be due to garbage collection don't
really pan out - the code is doing a lot of recursive function calls,
but only allocating memory when it matches a construct (which is
negligible compared with the run time), and doesn't actually do any
freeing at all. Either function calls in CLR are horrifically slow,
CLR code is inherently horiffically slow, or both. I am also concerned
that the lexical analyser (which has a very tight inner loop running a
lex-like state table driven finite state automaton/state machine, with
no function calls at all) seems slow. The test harness outputs a
message to the console before and after lexing, and you can see a
delay of what must be a few hundred milliseconds, where in 'real'
VC++6 code, the delay is unmeasurably short for the same file (as
you'd expect it to be given an N-complex linear algorithm like this).
I had high hopes for CLR - this finding was a serious shock today. Is
this a FAQ? Is there something I've missed here? Is there any way to
get VC++7 to generate proper code that can still interwork with .NET?
This is causing us to have to reevaluate our use of .NET in general,
if this really is true.
Thank you in advance,
Sarah Thompson
PS: The results of our timing tests are as follows:
Compiler VC++ 6.0 release mode, default options
Time (s) 9
Speed relative to VC6(%) 100
Speed relative to VC7 (%) 5277.777778
Compiler Intel C++ 5.0 release mode, default options
Time (s) 11
Speed relative to VC6(%) 81.81818182
Speed relative to VC7 (%) 4318.181818
Compiler g++ 2.95.3-5 release mode, -O2 optimisation
Time (s) 11
Speed relative to VC6(%) 81.81818182
Speed relative to VC7 (%) 4318.181818
Compiler VC++7.0 release mode, CLR no precompile
Time (s) 475
Speed relative to VC6(%) 1.894736842
Speed relative to VC7 (%) 100
Compiler VC++7.0 release mode, CLR, ngen used
Time (s) 551
Speed relative to VC6(%) 1.633393829
Speed relative to VC7 (%) 86.20689655
PPS: I can't release the test code for copyright reasons.
PPPS: Hardware was a Dell Inspiron 5000e, 750MHz Pentium 3 running
Win2k, VS.NET release version
Michel Gallant
http://www.devhood.com/tutorials/tutorial_details.aspx?tutorial_id=203
and compared notes ?
- Mitch
Carl Daniel
news:c54fb8d8.02031...@posting.google.com...
> I have been using VC7 (full release version) since it was released,
> give or take a day or two. My immediate reaction was that the CLR
> concept is a brilliant idea, but my code (unmanaged C++)
>
>
> native code?
So which is it, unmanaged C++, or running under the CLR?
If unmanged, are you comparing Debug builds or Release builds? Debug builds
under VC7 are much slower than VC6 due to additional runtime checking that's
turned on by default. Release builds should be comparble or somewhat faster
with VC7 (due to optimizer improvements). (Of course, some of those
"improvements" have bitten people - it seems that a new optimizer bug is
posted to this newsgroup about once a week. I can't wait for VS.NET SP1).
-cd
Suresh __NoJunkMail kumar
does a lot of string operations, you will need to optimize your string
routines.
Take this example for instance
string S = "";
for(int i=0; i <5000000; i++) {
S = S + "a";
}
over time this code will start becoming slower and slower and slower. There
is good reason why this happens.
Initially, you are allocating memory of 0 bytes to store the string;
Now, in the next iteration, you are allocating 1 byte, freeing the 0 byte
block
in the next, 2 bytes, freeing the 1 byte block
in the next 3 bytes, freeing the 2 byte block etc, etc
That would mean that the heap will become defragmented with blocks of size
1,2,3,4.....
So, as everytime your S = S + "a" tries to allocate new memory of N+1 byte
bock, first it tries to allocate a block on top of the heap. Usually VC++
would give 1MB heap. Now, since your program will exhaust the search on the
top of heap after 2000 iterations ( n(n+1)/2 < 1M) , malloc/new will try
searching for a new block along the freed heap. Now, the heap even though it
has free space is defragmented. So, malloc would have to try to find a block
of N+1 bytes by combing blocks that are less then N bytes. Ofcourse, this
means that memory allocation is no longer O(1), instead O(N^2) and this
would tremdously impact your program. Now multiply that O(N^2) by the big-O
of ur program and now you have an incredibly slow program.
I do think this is the effect you are probably seeing.
I suggest you change your string routines and everything would be fine then.
-Suresh
Rutgers VLSI Group
"Sarah Thompson" <sa...@telergy.com> wrote in message
news:c54fb8d8.02031...@posting.google.com...
Suresh __NoJunkMail kumar
However, interoping between managed and unmanaged code will definitely be
slower.
-Suresh
"Sarah Thompson" <sa...@telergy.com> wrote in message
news:c54fb8d8.02031...@posting.google.com...
Ronald Laeremans [MSFT]
it. What compiler flags are you compiling the code with?
And in general VC 7.0 unmanaged code is significantly faster than 6.0. It
will be very hard for us to see what your issues are if you can't either
profile them on your end and narrow down what is slower, or can work with us
sharing the source code.
Ronald Laeremans
Visual C++ compiler and libraries team
"Sarah Thompson" <sa...@telergy.com> wrote in message
news:c54fb8d8.02031...@posting.google.com...
Mike Lazear
Use the StringBuilder class instead of string.
Search for "Using the StringBuilder Class" in the MSDN Library and read the
description.
Mike
"Suresh __NoJunkMail kumar" <mdsuresh__R...@eden.rutgers.edu> wrote
in message news:eN$$pm4zBHA.2216@tkmsftngp07...
Silvain Piree
Sarah,
I'm no .Net expert, but I had similar experiences when moving from
C++ to Java (not .Net). It turned out Java didn't do buffering on
file reads. Performance increased dramatically when I did something
like "new BufferedReader(new FileReader(...))".
Perhaps a similar problem is occurring in your software, and buffering
may help you (but then again, I'm no .Net expert; perhaps one of the
.net experts could correct me).
Good luck, Silvain
"Sarah Thompson" <sa...@telergy.com> wrote in message
news:c54fb8d8.02031...@posting.google.com...
Sarah Thompson
Running under the CLR, but not 'managed C++'. I'd have guessed that
made it 'un-'managed C++, but obviously my common sense is too stupid
for Microsoft's acronym factory.
> If unmanged, are you comparing Debug builds or Release builds? Debug builds
> under VC7 are much slower than VC6 due to additional runtime checking that's
> turned on by default. Release builds should be comparble or somewhat faster
> with VC7 (due to optimizer improvements). (Of course, some of those
> "improvements" have bitten people - it seems that a new optimizer bug is
> posted to this newsgroup about once a week. I can't wait for VS.NET SP1).
I'm comparing release builds in all cases, with default optimisation
levels other than for g++, which was set to -O2 because its defaults
made it look slower than it really is. The CLR debug build took so
long that I couldn't be bothered to wait for it to complete.
Sarah
Sarah Thompson
> does a lot of string operations, you will need to optimize your string
> routines.
Not necessary. The lexer and parser don't actually do any string
operations.
> Take this example for instance
> string S = "";
> for(int i=0; i <5000000; i++) {
>
> S = S + "a";
> }
>
> over time this code will start becoming slower and slower and slower. There
> is good reason why this happens.
>
> Initially, you are allocating memory of 0 bytes to store the string;
>
> Now, in the next iteration, you are allocating 1 byte, freeing the 0 byte
> block
> in the next, 2 bytes, freeing the 1 byte block
> in the next 3 bytes, freeing the 2 byte block etc, etc
> That would mean that the heap will become defragmented with blocks of size
> 1,2,3,4.....
> So, as everytime your S = S + "a" tries to allocate new memory of N+1 byte
> bock, first it tries to allocate a block on top of the heap. Usually VC++
> would give 1MB heap. Now, since your program will exhaust the search on the
> top of heap after 2000 iterations ( n(n+1)/2 < 1M) , malloc/new will try
> searching for a new block along the freed heap. Now, the heap even though it
> has free space is defragmented. So, malloc would have to try to find a block
> of N+1 bytes by combing blocks that are less then N bytes. Ofcourse, this
> means that memory allocation is no longer O(1), instead O(N^2) and this
> would tremdously impact your program. Now multiply that O(N^2) by the big-O
> of ur program and now you have an incredibly slow program.
That was true of some older STL implementations. Newer ones reallocate
vectors/strings in big chunks rather than one character at a time,
which is claimed to be N log N, rather than N^2. That said, it's a
moot point as regards my code, because it doesn't actually do any of
this anyway.
Sarah
Sarah Thompson
> it. What compiler flags are you compiling the code with?
Compiler flags:
/O2 /Ob1 /D "WIN32" /D "NDEBUG" /D "_MBCS" /FD /EHsc /MT /GS /GR
/Yu"stdafx.h" /Fp"Release/ssllcc.pch" /Fo"Release/"
/Fd"Release/vc70.pdb" /W3 /nologo /c /Zi /clr /TP
Linker flags:
/OUT:"Release/ssllcc.exe" /INCREMENTAL:NO /NOLOGO /DEBUG
/PDB:"Release/ssllcc.pdb" kernel32.lib user32.lib gdi32.lib
winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib
oleaut32.lib uuid.lib odbc32.lib odbccp32.lib
> And in general VC 7.0 unmanaged code is significantly faster than 6.0. It
> will be very hard for us to see what your issues are if you can't either
> profile them on your end and narrow down what is slower, or can work with us
> sharing the source code.
Apologies for the terminology misunderstanding. My code is ISO C++,
using the STL, compiled as a .NET CLR executable. I'm not using __gc.
> Ronald Laeremans
> Visual C++ compiler and libraries team
Thank you for your time,
Sarah
Tomas Restrepo [MVP]
> Running under the CLR, but not 'managed C++'.
Actually, if you compiled it with /clr and are running it under the CLR, it
_is_ managed C++. In MC++, you have to distinguish between managed code and
managed data. In your case, you were building managed code but leaving your
data unmanaged (since you weren't using any __gc or __value types).
--
Tomas Restrepo
tom...@mvps.org
Suresh __NoJunkMail kumar
with CLR. In fact, if you do read the documentation, unmanaged code will run
slower inside an a managed environment. go look up gcroot template class
inside the documentation. You will find pointers there as to why unmanaged
code will be slower inside managed code. STL, ATL, templates in general
have nothing to do with the CLR because the CLR currently doesn't "actually"
support them.
- Suresh
"Tomas Restrepo [MVP]" <tom...@mvps.org> wrote in message
news:#m8Z0$$zBHA.2068@tkmsftngp05...
Sean Gies
on day 2 of learning about managed C++:
Could it be possible that pieces of her code are managed (running in the
CLR) while all of her classes and structs are unmanaged? If this were true,
then there could be a huge bottleneck where the code is popping back and
forth between the managed and unmanaged pieces of code. Prior to switching
on the extensions, all of those managed blocks of code were compiled native,
thus no bottleneck.
Maybe it happened like this:
class Stream {
public:
char GetNext() {return d[i++];}
bool HasMore() {return i<=l;}
char *d;
int i, l;
};
void Parse(Stream *s) {
do {
char c = s->GetNext();
// Do some parsing...
} while (s->HasMore());
}
With the managed extensions turned off, most of that code would have been
inlined into an efficient, fast executable. When the managed extensions
were turned on, the Stream class remained unmanaged because of the lack of a
__gc keyword while the Parse function became managed in order to allow it
access to the .NET framework. Now, instead of inlining the Stream member
functions into the Parse function, the managed Parse function must cross the
interop boundary from the CLR into unmanaged code every time it access the
unmanaged Stream class.
I am only guessing that this is the problem, so take it with a grain of
salt.
I bet it would run faster if the code containing tight loops was either all
managed or all unmanaged, NOT a mix of managed functions and unmanaged
classes.
-Sean
Tomas Restrepo [MVP]
> Could it be possible that pieces of her code are managed (running in the
> CLR) while all of her classes and structs are unmanaged?
That's actually the default behavior when you compile with /clr but don't
make classes managed by using __gc or __value explicitly.
> If this were true,
> then there could be a huge bottleneck where the code is popping back and
> forth between the managed and unmanaged pieces of code.
Not necessarily true. The only place I know this can be a bottleneck is if
you mix managed code with virtual methods in __nogc types, since the
dispatching requires a switch to unmanaged code to deal with the unmanaged
vtable. For non-virtual methods, that doesn't happen.
--
Tomas Restrepo
tom...@mvps.org
Sarah Thompson
> you mix managed code with virtual methods in __nogc types, since the
> dispatching requires a switch to unmanaged code to deal with the unmanaged
> vtable. For non-virtual methods, that doesn't happen.
Is a __nogc type the default, i.e. if I declare a class with no __gc
(no __anything actually), is the class then automatically __nogc? I'd
have assumed it would need to be, because 'ordinary' C++ wouldn't take
well to its data moving around on its own. This may well be the exact
issue, because the parser classes all inherit from a single base
class, and call each other through virtual member functions. I always
had a hunch that those calls were somehow way slower than they should
be.
Is there a way around this, or do I need to drop the CLR approach?
Sarah
Tomas Restrepo [MVP]
> Is a __nogc type the default, i.e. if I declare a class with no __gc
> (no __anything actually), is the class then automatically __nogc?
Yes, that is correct, __nogc is the default.
> I'd
> have assumed it would need to be, because 'ordinary' C++ wouldn't take
> well to its data moving around on its own. This may well be the exact
> issue, because the parser classes all inherit from a single base
> class, and call each other through virtual member functions. I always
> had a hunch that those calls were somehow way slower than they should
> be.
Yes, that's very likely what's going on here. MS is aware of the issue, and
I'm sure they're likely loking for possible alternatives and improvements.
>
> Is there a way around this, or do I need to drop the CLR approach?
Well, that depends... what's in it for you in converting the app to CLR?
--
Tomas Restrepo
tom...@mvps.org
Brad Wilson
> /O2 /Ob1 /D "WIN32" /D "NDEBUG" /D "_MBCS" /FD /EHsc /MT /GS /GR
> /Yu"stdafx.h" /Fp"Release/ssllcc.pch" /Fo"Release/"
> /Fd"Release/vc70.pdb" /W3 /nologo /c /Zi /clr /TP
Remove the /clr and re-test. You're making managed C++, not unmanaged C++,
when you use /clr.
Brad
--
Read my weblog at http://www.quality.nu/dotnetguy/
Sarah Thompson
> > (no __anything actually), is the class then automatically __nogc?
>
> Yes, that is correct, __nogc is the default.
Right. That pretty much nails this issue down I think.
> > I'd
> > have assumed it would need to be, because 'ordinary' C++ wouldn't take
> > well to its data moving around on its own. This may well be the exact
> > issue, because the parser classes all inherit from a single base
> > class, and call each other through virtual member functions. I always
> > had a hunch that those calls were somehow way slower than they should
> > be.
>
> Yes, that's very likely what's going on here. MS is aware of the issue, and
> I'm sure they're likely loking for possible alternatives and improvements.
Well, I wish them luck in sorting out the problem.
> > Is there a way around this, or do I need to drop the CLR approach?
>
> Well, that depends... what's in it for you in converting the app to CLR?
Just politics. (When anyone says 'just politics', it was 'just
politics' that started most wars, so please have sympathy!). Anyway, I
managed to persuade our manager to let us move the parser code into a
Win32 native DLL, keeping the same .NET managed C++ class interface as
before, but with the calls mapped to the DLL. As those calls happen
once per source file, then once per dependency to get the results
(we're doing this for an in-house impact analysis system, if you
haven't guessed already), this will definitely cure our performance
problems.
I tried compiling the test program that did so badly under the CLR as
a VC7 Win32 console app today - the performance in release mode was
outstanding. Noticeably better than VC6, although I've not actually
done timing tests to be sure.
Sarah
PS: I'd like to thank everyone who has responded for their help and
advice - it is very much appreciated, and has without doubt saved our
project considerable time. :)
Tomas Restrepo [MVP]
> Just politics. (When anyone says 'just politics', it was 'just
> politics' that started most wars, so please have sympathy!).
Well, I work for a company, too, so I understand your "pain" <g>
> Anyway, I
> managed to persuade our manager to let us move the parser code into a
> Win32 native DLL, keeping the same .NET managed C++ class interface as
> before, but with the calls mapped to the DLL.
That's a good approach. Another (possibly simpler one), would've been to
just maintain the files that implemented the parser as unmanaged code. This
is one place where the VC team did an outstanding job, imho! You can just
enable /clr on _some_ files in your project, not all, and mix both in a
single image. Or, you can also make sure parts of the code get compiled as
unmanaged code if the whole project is compiled with /clr by using
#pragma unmanaged
in the proper places.
--
Tomas Restrepo
tom...@mvps.org
Sean Gies
> > have assumed it would need to be, because 'ordinary' C++ wouldn't take
> > well to its data moving around on its own. This may well be the exact
> > issue, because the parser classes all inherit from a single base
> > class, and call each other through virtual member functions. I always
> > had a hunch that those calls were somehow way slower than they should
> > be.
>
> Yes, that's very likely what's going on here. MS is aware of the issue,
and
> I'm sure they're likely loking for possible alternatives and improvements.
Could someone explain to me exactly what happens to C++ code when you flip
on /clr? Does all the code become managed, including the member functions
of unmanaged types? I'm not to clear on the line between managed code/types
and unmanaged code/types.
I understand that types only become managed when you explicitly add keywords
such as __gc, but when do blocks of code become managed?
-Sean
Sean Gies
> just maintain the files that implemented the parser as unmanaged code.
This
> is one place where the VC team did an outstanding job, imho! You can just
> enable /clr on _some_ files in your project, not all, and mix both in a
> single image. Or, you can also make sure parts of the code get compiled as
> unmanaged code if the whole project is compiled with /clr by using
> #pragma unmanaged
> in the proper places.
Those per-file settings are always difficult to setup and maintain. For my
project, I have been planning on putting all of the unmanaged speed-critical
code into a static .lib project and linking it into my managed .dll project.
Are there advantages to doing it as you suggested? Could the compiler do
better optimization if the unmanaged code was not compiled into a static
.lib file?
-Sean
Tomas Restrepo [MVP]
> Those per-file settings are always difficult to setup and maintain.
That depends on how you implement them, but yes, they can be.
> For my
> project, I have been planning on putting all of the unmanaged
speed-critical
> code into a static .lib project and linking it into my managed .dll
project.
That's a good idea and should work fine.
>
> Are there advantages to doing it as you suggested? Could the compiler do
> better optimization if the unmanaged code was not compiled into a static
> .lib file?
That depends a lot on what your code does and how it is implemented. One
thing to be aware of is that /clr is incompatible with some other compiler
switches, such as runtime checks. Also, consider the fact that /clr is
incompatible with the /GL switch (link time code generation) so you do loose
some optimizations (you might win some of those back if you compile the
unmanaged code to a DLL and not a LIB, and compile that with /GL, provided
you have a viable call pattern between your exe and dll).
Perhaps one of the VC guys can comment on how much /clr throws off the
optimizer?
--
Tomas Restrepo
tom...@mvps.org
Sarah Thompson
> just maintain the files that implemented the parser as unmanaged code. This
> is one place where the VC team did an outstanding job, imho! You can just
> enable /clr on _some_ files in your project, not all, and mix both in a
> single image. Or, you can also make sure parts of the code get compiled as
> unmanaged code if the whole project is compiled with /clr by using
> #pragma unmanaged
> in the proper places.
Wow - I didn't realise you could do that. I'll give this a try. As you
say, it will save an awful lot of pain.
Thanks!
Sarah
Ronald Laeremans [MSFT]
The only obvious real slowdown is calling through function pointers
(including virtual function calls that go through the vtable). because of
interop with unmanaged code we need to treat all function pointers as
pointing to unmanaged code, all such calls where both the caller and the
callee are implemented in managed code (MSIL) go through a
managed-unmanaged-managed transition which is very costly.
We are working to eliminate that issue in a future version (but not in the
version we sometimes refer to as 7.1).
-Ronald-
"Sarah Thompson" <sa...@telergy.com> wrote in message
news:c54fb8d8.02032...@posting.google.com...
Ronald Laeremans [MSFT]
is after a #pragma unmanaged in that file.
Ronald Laeremans
Visual C++ compiler and libraries team
"Sean Gies" <som...@somewhere.com> wrote in message
news:O8LzNXS0BHA.1712@tkmsftngp04...
Joe "Nuke Me Xemu" Foster
> Code becomes managed when you compile a file with the /CLR switch. Unless it
> is after a #pragma unmanaged in that file.
Which #pragma turns off the .NET Framework SDK EULA section 4.8?
"4.8 Benchmark Testing. You may not disclose the results of any
benchmark test of the .NET Framework component of the Product
to any third party without Microsoft's prior written approval."
URL:http://msdn.microsoft.com/downloads/Eula_NetFramework.htm
Hmm, we haven't heard from Ms. Thompson in a few days, have we...
--
Joe Foster <mailto:jlfoster%40znet.com> Wanna buy a Bridge? <http://xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!
Ronald Laeremans [MSFT]
contact to work with to get you permission to publish a benchmark and I will
make sure you get hooked up with the right folks. (Since I am starting out
on a trip tomorrow my replies might be slow over the next 10 days.)
Ronald Laeremans
Visual C++ compiler and libraries team
"Joe "Nuke Me Xemu" Foster" <j...@bftsi0.UUCP> wrote in message
news:#fmm7MK1BHA.2484@tkmsftngp07...
Sarah Thompson
I'm still here. :) Just busy with releasing my C++ signal/slot library
(plug: http://sigslot.sourceforge.net/). Until you mentioned it, I had
no idea that there was any kind of legal problem with mentioning
performance statistics. I read EULAs with about as much enthusiasm as
I visit dentists, so I must beg forgiveness for having missed that.
As yet, no one from Microsoft is suing me (to my knowledge), anyway.
On the performance issue, yes, moving to genuinely unmanaged code in
VC7 did fix the problem (e.g. 650000 lines/22MB of VB source lexed and
parsed in a few seconds. Oops - did it again!). VC7 in unmanaged mode
is very good - the code seems to scream along, beating even Intel C++
as best I can measure. This speedup was partially due to carefully
tweaking the grammar (left factoring to any compiler people out
there), but mostly the difference was simply due to not using managed
code. So, clearly there is a bit of a difference between managed and
unmanaged C++, but I just happen to have written some code that treads
on something that makes a BIG difference. It's probably nothing that
can't be fixed - no doubt I'm causing the compiler to emit an IL
instruction sequence that the JIT compiler doesn't optimise well.
Here's an idea: Microsoft can hire me, then I'll fix it myself. :)
Sarah
Joe "Nuke Me Xemu" Foster
> > Hmm, we haven't heard from Ms. Thompson in a few days, have we...
>
> I'm still here. :) Just busy with releasing my C++ signal/slot library
> (plug: http://sigslot.sourceforge.net/). Until you mentioned it, I had
> no idea that there was any kind of legal problem with mentioning
> performance statistics. I read EULAs with about as much enthusiasm as
> I visit dentists, so I must beg forgiveness for having missed that.
Well, now you know better. Have you heard about the FrontPage 2002
components EULA clause forbidding the "disparagement" of Microsoft?
> As yet, no one from Microsoft is suing me (to my knowledge), anyway.
Naah, they'll just send MiBs in black helicopters... Fortunately,
they're still in the midst of a "migration" to .NET, so don't bother
watching the skies for a while yet.
> code. So, clearly there is a bit of a difference between managed and
> unmanaged C++, but I just happen to have written some code that treads
> on something that makes a BIG difference. It's probably nothing that
> can't be fixed - no doubt I'm causing the compiler to emit an IL
> instruction sequence that the JIT compiler doesn't optimise well.
Screw the JITter -- compile the MSIL to hardware! Aren't there still
some CPUs out there that can be drastically "reconfigured" on-the-fly?
--
Joe Foster <mailto:jlfoster%40znet.com> "Regged" again? <http://www.xenu.net/>
Brandon Bray [MSFT]
>
> Well, now you know better. Have you heard about the FrontPage 2002
> components EULA clause forbidding the "disparagement" of Microsoft?
> they're still in the midst of a "migration" to .NET, so don't bother
> watching the skies for a while yet.
You know, there are some forums where indiscriminately being rude and
trolling about is looked upon with admiration -- this is NOT one of those
forums. If you have problems you're trying to solve, please inform.
Otherwise, I suggest taking these clearly off-topic discussions somewhere
where the readership truly wants to hear you.
--
Cheerio!
Brandon Bray Program Manager in the Visual C++ Compiler Team
And now a word from the lawyers: This posting is provided "AS IS" with no
warranties, and confers no rights. You assume all risk for your use. © 2002
Microsoft Corporation. All rights reserved.
Joe "Nuke Me Xemu" Foster
> Joe "Nuke Me Xemu" Foster wrote:
> >
> > Well, now you know better. Have you heard about the FrontPage 2002
> > components EULA clause forbidding the "disparagement" of Microsoft?
> > Naah, they'll just send MiBs in black helicopters... Fortunately,
> > they're still in the midst of a "migration" to .NET, so don't bother
> > watching the skies for a while yet.
>
> You know, there are some forums where indiscriminately being rude and
> trolling about is looked upon with admiration -- this is NOT one of those
> forums.
Oh very well, I'll go find someplace where "indiscriminately being rude
and trolling about is looked upon with admiration"... Say, is Microsoft
Marketing currently hiring?
URL:http://www.novell.com/news/press/archive/2001/10/pr01093.html
> If you have problems you're trying to solve, please inform.
Soitenly! Will MSVC--'s myriad standards compliance and other Bugs++
of the Month ever be fixed, or is the focus still on strong-arming the
C++ standards committee?
> Otherwise, I suggest taking these clearly off-topic discussions somewhere
> where the readership truly wants to hear you.
Presumably, that would be like the Novell NetWare mailing list, right?
Thank you,
--
Joe Foster <mailto:jlfoster%40znet.com> L. Ron Dullard <http://www.xenu.net/>
Joe "Nuke Me Xemu" Foster
> Foster, these [MSFT]'ers are not behind the evilness of MSFT; they just
> work there. Beating on them won't solve anything. I'm sure if it were
> up to them, they'd get rid of the scum low-lifes there and we could all
> "like" MSFT as a company, instead of, well, you know.
So then what exactly is the role of, frex, a "Program Manager in the
Visual C++ Compiler Team", an over-glorified fetcher of coffee, hmm?
--
Joe Foster <mailto:jlfoster%40znet.com> Space Cooties! <http://www.xenu.net/>
Michael (michka) Kaplan
> So then what exactly is the role of, frex, a "Program Manager in the
> Visual C++ Compiler Team", an over-glorified fetcher of coffee, hmm?
Program managers are not any such thing, and its kind of offensive that you
can manage nothing more than insults just because you do not understand how
something works (at a minimum you have proven your social engineering skills
could use some improvement).
--
MichKa
Michael Kaplan
Trigeminal Software, Inc. -- http://www.trigeminal.com/
International VB? -- http://www.i18nWithVB.com/
C++? MSLU -- http://msdn.microsoft.com/msdnmag/issues/01/10/
Joe "Nuke Me Xemu" Foster
> "Joe "Nuke Me Xemu" Foster" <j...@bftsi0.UUCP> wrote...
>
> > So then what exactly is the role of, frex, a "Program Manager in the
> > Visual C++ Compiler Team", an over-glorified fetcher of coffee, hmm?
>
> Program managers are not any such thing, and its kind of offensive that you
> can manage nothing more than insults just because you do not understand how
> something works (at a minimum you have proven your social engineering skills
> could use some improvement).
Actually, I was merely questioning "40th"'s assertion that the
Microserfs I've been "beating on" have no real decision-making
authority whatsoever. You couldn't have misinterpreted my post
more wildly had you deliberately tried! /Were/ you trying to?
--
Joe Foster <mailto:jlfoster%40znet.com> L. Ron Dullard <http://www.xenu.net/>
Michael (michka) Kaplan
> Actually, I was merely questioning "40th"'s assertion that the
> Microserfs I've been "beating on" have no real decision-making
> authority whatsoever. You couldn't have misinterpreted my post
> more wildly had you deliberately tried! /Were/ you trying to?
Sorry, wrong again.
The people you have been beating on here do not have power over the things
that *you* are so damn bitter about, no. This does not mean that they are
powerless, or that they get coffee for others.
Chris Thomas
Yeah, well, it seems that the eula restrictions and other lack of anything
useful other than chest-beating .Net Marketitecture has resulted in the
stillborn .Net. Hasn't anyone else noticed? .Net is already fading away,
before it even had a chance.
The Linux frieght train, powered by Java, is already fast upon us... can't
you hear it? It's all over the internet -- thunderous and free, 2003 will
be the Year of Linux. If you are a professional programmer and haven't
started learning J2EE and Linux, you're missing the boat. Only fortune 100
will embrace .Net.
Anybody with 1/2 half a brain would embrace Linux/J2EE, or for
cross-platform, something like Flash. Or a mozilla or opera plugin.
Bah
"Michael (michka) Kaplan" <forme...@nospam.trigeminal.spamless.com> wrote
in message news:OkODES83BHA.2284@tkmsftngp07...
Cowboy (aka Gregory A. Beamer) [MVP]
I have a whole brain and I see C# and VB.NET projects coming out of the
woodwork here. Guess some people did not notice it was stillborn. As long as
stupid business men are more willing to hire me as a .NET developer than a
J2EE developer, I doubt I will switch.
P.S. Grow up!
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
Author: ADO.NET and XML: ASP.NET on the Edge
****************************************************************************
****
Think outside the box!
****************************************************************************
****
"Chris Thomas" <chris....@allscripts.com> wrote in message
news:uKGLTi7GCHA.2024@tkmsftngp11...
Chris Thomas
situation -- can't pay our bills on some religious debate. Bring on windows
and .net, and loads of employment opportunities. Just pay attention to
Linux; you might get blindsided.
"Cowboy (aka Gregory A. Beamer) [MVP]"
<NoSpamM...@comcast.netRemoveThis> wrote in message
news:u8sEIw7GCHA.1716@tkmsftngp13...
Cowboy (aka Gregory A. Beamer) [MVP]
Actually, I hate the whole fanatical warfare. I currently am working in Java
(albeit on Windows), but the next position is supposed to be .NET. And, I
have worked quite a bit with Linux.
The downside with Linux, right now, is the lack of commercial software to
get a buy in from management (and, the masses). If that hurdle can be
crossed, I believe you will see the market grow, esp. if MS is still having
huge security problems (partially their own fault, and partially due to the
fact they are such a big target).
****************************************************************************
****
Think outside the box!
****************************************************************************
****
"Chris Thomas" <chris....@allscripts.com> wrote in message
news:eENQZIVHCHA.2460@tkmsftngp10...
James Battle
It's not that it's not good UNIX O/S, but because there aren't the
commercial apps available.
CTO's are also terrified of the idea of using an OPEN Source O/S.
The only reason that Linux vendors keep dumping on Windows is that,
in reality, Linux suports a tiny number of devices/commercial apps.
It's easy to write a good version of VI so that it doesn't crash....
As for Java. It's a good language, but there are a LOT of banks
currently changing to .NET. FACT.
James Battle
Ironbark Limited
"Cowboy (aka Gregory A. Beamer) [MVP]"
<NoSpamM...@comcast.netRemoveThis> wrote in message
news:#LCSTweHCHA.704@tkmsftngp08...
Joe "Nuke Me Xemu" Foster
> No financial institution I've ever worked for has taken Linux seriously.
> It's not that it's not good UNIX O/S, but because there aren't the
> commercial apps available.
What time frame are we talking about, the 70s, 80s, and perhaps even
the early 90s?
> CTO's are also terrified of the idea of using an OPEN Source O/S.
> The only reason that Linux vendors keep dumping on Windows is that,
> in reality, Linux suports a tiny number of devices/commercial apps.
If they really need someone they could yell at over the phone, or maybe
even sue, there are plenty of VARs selling versions of Linux.
> It's easy to write a good version of VI so that it doesn't crash....
Oh, I'm sure there's still a buffer overrun bug or two left in the old
girl yet!
> As for Java. It's a good language, but there are a LOT of banks
> currently changing to .NET. FACT.
After having worked for a few banks myself, I'd hardly take that as a
ringing endorsement of .NET...
--
Joe Foster <mailto:jlfoster%40znet.com> DC8s in Spaace: <http://www.xenu.net/>
Mark
strategic decisions based on this. To dismiss Linux out of hand would be a
serious short-coming of any CIO. Financial pressure is enuring that Linux is
gaining market share in the server market. In a bank I used to work with
Linux is being used to run the branches systems. If you have something like
200 branches thats a lot of money saved.
As for linux being short on Appps it depends on what you want Linux to do.
1) As a workstation - I also used to think that there were limited apps but
this has changed a lot recently. Many software vendors are porting their
apps to Linux eg CA. And there is a host of productivity suites out there
that cost a fraction of the price of Office. Did you know they have a free
project management app thats a clone of MS Project? In most organisations
that I have been in the bulk of users are still running office95/97 and
windows 98 as it has all the required functionality.
2) As a server running some bespoke applicaiton - As a development platform
Linux has all the tools and then some. Apache is the leading Web Server.
What has this got to do with .NET? The main point in any decision for a
large organistion is not to be tied in to a particular vendor. Everything
must be unpluggable and replaceable. Just like software components that can
be changed without having to change the whole app so is the aim with OS and
hardware. Banks have large hetergenous systems and an app that starts off on
a departmental server running W2k might end up on the main frame. Why
rewrite everything? Just unplage Windows plugin Solaris or OS400 VMS and go.
This is Java's stregnth. It would be great if .net really was platform
independent. This would require the porting of all .net libraries as well as
the run time etc. If this was the case then .NET would be the out and out
winner for any orgainsation. Sadly I can't see Bill allowing this technology
to do anything other than tie people in to windows.
"James Battle" <james....@ironbark.co.uk> wrote in message
news:efRXphpICHA.1632@tkmsftngp10...
Mark
So waht we need is a JAVA .net hybrid.
"Mark" <m...@NoJunkMail.mweb.co.za> wrote in message
news:ag8nj7$8iq$1...@ctb-nnrp2.saix.net...
Anders Dahlberg
> PS: I forgot to add the great thing about .net is language unpluggability.
> So waht we need is a JAVA .net hybrid.
Really? is it?
So, please tell me *one* language except C# that you can use in .NET as is
without any modifications?
Courageous
>So, please tell me *one* language except C# that you can use in .NET as is
>without any modifications?
The real issue here is that the CLR primitives are designed for C#-style
actions. For example, if you want to implement a programming language with
MI in it, the CLR is going to give you a major headache. The very design
of the CLR is C#-centric, and languages that desire to be hosted on the CLR
must take on the C# design decisions. So this "multiple language" meme for
.NET is all huffy puffy marketing lies.
C//
Chris Thomas
suits in washington, in an attempt to restore investor confidence. I for one
would be much more at ease investing in a corporation that IS NOT TIED TO
MICROSOFT. Microsoft are convicted monopolists and can't be trusted. I
don't care if .NET solves all the world's problems--- corporations with
public accountability, and public entities in general, must not be tied to
Microsoft. It's just not good business sense to tie the heart of your
business to one vendor.
"Courageous" <jkr...@san.rr.com> wrote in message
news:ek5hiuc7fampo8ids...@4ax.com...
Bob Grommes
It's true that no language ported to .NET will preserve 100% backward
compatibility, but I don't really see that claim being made. What people are
really being asked to buy into is the .NET framework and the CLR. Having an
interface to the CLR using something resembling your language of choice makes
the buy-in less painful, but not painless.
On the other hand with Java you have to adopt a particular language *in
addition* to a particular framework, which when you think about it is no
different than, say, VB6's value proposition except that Java is (at least in
theory) multi-platform.
I see .NET as THE watershed advancement for MSFT shops today, and for tomorrow
I see its encroachment onto other platforms, with or without MSFT's active
support, as inevitable. MSFT has done its developers a great favor in unifying
and modernizing its various APIs and frameworks into something reasonably
well-designed, flexible, fast, and Internet-optimized. Beyond that I think
it's amazing that there are so many serious open source projects underway to
port this technology from the "evil empire" to other platforms and to make
other platforms more interoperable with it. .NET has clearly struck a
responsive chord with a critical mass of developers. I believe it will succeed
handsomely.
--Bob
"Courageous" <jkr...@san.rr.com> wrote in message
news:ek5hiuc7fampo8ids...@4ax.com...
>
Dilton McGowan II
> This is Java's stregnth. It would be great if .net really was platform
> independent. This would require the porting of all .net libraries as well
as
> the run time etc. If this was the case then .NET would be the out and out
> winner for any orgainsation. Sadly I can't see Bill allowing this
technology
> to do anything other than tie people in to windows.
What about DotGNU and Mono?
Dilton
Hendrik Schober
> [...]
> It's true that no language ported to .NET will preserve 100% backward
> interface to the CLR using something resembling your language of choice makes
> the buy-in less painful, but not painless.
>
> On the other hand with Java you have to adopt a particular language *in
> addition* to a particular framework,
Well, but the question remains: Is that really worse than
twisting an already existing language with known idioms,
styles, issues etc. into new paradigms? I.e., how much of
C++ (I mean the "good" C++: predictable dtor-calls,
exception safety idioms, STL, etc.) is really left after
bending it into Managed C++?
I think, to really master a language, you have to know all
these little "usage things", the spirit of it, or however
you might call it, that are hard to communicate using
grammars and that (unfortunately) are usually learned not
before you learned the syntax of the language. If you pull
away the underlying platform (or, as in the C/C++ case, the
assumptions about the platform) under the language, this
will all be different, and you have te re-learn it. Since
writing one language's style using another language's
syntax most of the time is the worst of all combinations,
it might be better, to just use a new language.
(Note that I don't think this hurts the benefit of beeing
able to port your old (C/C++) code to the new platform, if
you can leave it as it is.)
> which when you think about it is no
> different than, say, VB6's value proposition except that Java is (at least in
> theory) multi-platform.
Not that I would particulary like Java, but that's like
saying vegetarionas are no different than meat-eaters,
except that the former won't eat meat while the latter do.
That _is_ the issue.
> [...]
Schobi
--
Spam...@gmx.de is never read
I'm HSchober at gmx dot de
Ben Kloosterman
I use NT/ WIn2K for non computer people desktops and I think Linux will
never get this market ( eg > 90%).
But Linux especially with IBM starting to push it ( as a poor mans UNIX
compared to their AIX ) does have a place in the market especially with
Apache and I believe Mono and DotGnu will be important to the ultimate
success of .NET.
.....
Ben
"Dilton McGowan II" <dil...@pacbell.net> wrote in message
news:uD2VWQvKCHA.2372@tkmsftngp11...