Back to General and Gameplay Programming

Is MFC dead now that we have C#?

Shadow1234567890 · 2002-09-01T22:12:28

I don''t have much experience with visual C#.net. I &#111nly installed it a week ago. I liked it becasuse it is exactly what I thought it would be...a cross between visual basic and C++. That idea is in itself is appealing, but it also makes me upset because there seems to be no use for the MFC which I have also been trying to learn. C# seems to be by far the best way to quickly create powerful solutions for the windows platform. All comments are welcome, I hope this is a big discussion.

General and Gameplay Programming Programming

Started by Shadow1234567890 August 31, 2002 11:13 AM

25 comments, last by Shadow1234567890 21 years, 7 months ago

the Speed Bump

240

September 01, 2002 12:41 PM

quote:Original post by Greven
On a completely OT point. Writing M$ to refer to Microsoft is not childish. Personally it is my way of making a small statement about how I feel about their business practices and to express my discontent about them. It is not about them wanting to make money, it is about them wanting to crush anyone that stands in their way. I could go on, but I won't. It would be a moot point and has been argued to death elsewhere. Just understand that for some of us, the $ is a statement of our feelings, not a childish babble.

Microsoft is a company like any other. ;P They're not out to "get you" any more than any other large corporation out there. The problem lies in the simple fact that there's no competition. Things would be just peachy (pretty awesome, in fact) if there was another evil superconglomerate that was at once on even footing with Microsoft, and in direct competition with it.

I'm hip because I say "M$" instead of "MS".

[edited by - the Speed Bump on September 1, 2002 1:42:02 PM]

"There is only one everything"

Epolevne

175

September 01, 2002 12:59 PM

HenryApe:
.NET''s MSIL was DESIGNED to be JIT''d...whereas java''s byte code was not. The emphasis was on the original design of the byte codes (the "legacy code" if you will), not the evolution that happened afterward. This design difference leads to major differences in the use of the stack and other areas that make JIT engines faster/more efficient. It''s one of the reasons that the 1st generation .NET JITer is as fast as 4th (or more?) generation Java JITers.

Epolevne

HenryApe

120

September 01, 2002 06:01 PM

quote:Microsoft is a company like any other.

Considering Microsoft''s court history, it might be correct to say that they are a company like maybe Standard Oil, but not like "any other".

quote:It''s one of the reasons that the 1st generation .NET JITer is as fast as 4th (or more?) generation Java JITers.

Now, now, Microsoft were very early to include a JIT compiler in its IE VM, it would be surprising if they did not at least keep up with the evolution. It is a pity that they have banned the free publication of .NET performance benchmarks in their EULA, makes it hard to find any good information on the strengths and weaknesses of C# and their JIT compiler.

the Speed Bump

240

September 01, 2002 06:06 PM

quote:
It is a pity that they have banned the free publication of .NET performance benchmarks in their EULA, makes it hard to find any good information on the strengths and weaknesses of C# and their JIT compiler.

eheh. Yeah. *cough*

Looks like it''s a teensey bit faster than java, and a teensey bit better on memory too. But nowhere near C++.

I''m hip because I say "M$" instead of "MS".

"There is only one everything"

Arild Fines

968

September 01, 2002 06:28 PM

One interesting thing about those benchmarks: C# was one of the worst performers in the string concatenation test. However, if you look at the source, you will see that they perform string concatenation like this:

  for (int i=0; i<N; i++) {            hello = String.Concat(hello, "hello\n");        }

This is of course the most idiotic way of doing a large number of string concatenations in .NET. Every single iteration of that loop will create a new String object.
Compare to the Java implementation, which uses the StringBuffer class:

  for (int i=0; i<n; i++) {            stringBuffer.append(hello);    }

This will of course be orders of magnitude faster, since there are no object instantiations in the loop. The C# test should have done the same, using the .NET equivalent of StringBuffer called StringBuilder. The way the test is now, it is comparing apples and elephants.
And here I think we hit on some of the reasoning behind that clause in the EULA...

"When you know the LORD you have no need for masturbation!"

--AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.[Project site] [IRC channel] [Blog]

HenryApe

120

September 01, 2002 06:34 PM

When looking at the tests, they first impression is that they seem to small to be relevant. Some test, such as the nested loop test, may actually be optimized away by smart JVMs (Microsoft's and IBM's VMs occasionally do this). It is a pity that the guy just tests Sun's VM as IBM's older VM has been known to perform better for this kind of simplistic tests.

The word frequency count test for Java also unnecessarily uses a synchronized container class, giving an unfair synchronization overhead when there are unsynchronized alternatives readily available (ArrayList instead of Vector). In fact, several of the tests seem to measure the library implementation rather than the language speed.

There is also no mention of him allowing the JVMs any startup time. Generally speaking, benchmarks that include dynamic code optimizers really need to be more complex and run for a longer period of time if their results are to have any general meaning for real-world applications. Chances are that much of his results are just start-up characteristics. These problems may affect the C# benchmarks too if it runs using the JITted runtime environment.

[edited by - HenryAPe on September 1, 2002 7:51:44 PM]

Shannon Barber

1,684

September 01, 2002 09:26 PM

quote:Original post by Arild Fines
And here I think we hit on some of the reasoning behind that clause in the EULA...

This didn't stop Microsoft from releasing thier own performance benchmarks showing C# to be faster at object instaniation and memory allocation than C++ with equally dubious code

With Loki's small object allocator an object allocation and deallocation takes 460 CPU ticks on average, when allocating 1,000,000 objects, then destroying those 1,000,000 objects.
If the objects are created and destroyed (without storing a pointer to them to be deleted afterwards) the time drops to 220 CPU Ticks per creation & destruction (because the memory is cached). This is a disappointly long time (and I think I know why... time to tweak SmallObj).
I got it down to 402 CPU Ticks/object with instance persistence, 171 ticks/Object without. Heh, it takes 392 ticks to allocate, and 10 to deallocate.

(I'll be rather impressed if C# can execute a single statement in 100ns - is it possible to time it? maybe with an unmanaged call to pass back the rdtsc result?)

[edited by - Magmai Kai Holmlor on September 1, 2002 11:12:27 PM]

- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara

Is MFC dead now that we have C#?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Is MFC dead now that we have C#?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines