|
Nemanja Trifunovic wrote: And VS is one of the rare MS desktop applications that use managed code
Very little.
Nemanja Trifunovic wrote: Wow, you are the first person aside from the authors of Paint.NET that like its performance.
And you're the first I've heard that didn't like the performance. Interestingly, in the Slashdot article you posted, I count more people saying the "fat brush" test is "silky smooth" than those claiming it performs badly. In my own testing, a brush width of 200 draws smoothly and doesn't touch the CPU, contrary to the few bad reports. Of course, this Slashdot post was from 2004, and there have been numerous updates to Paint.NET since then. When was the last time you looked at this application?
William E. Kempf
|
|
|
|
|
In my opinion, Paint.NET's page faults are far less when compared to other similar applications (same memory foot prints ).
In my machine, the number of PageFaults for PaintDotNet and Firefox, after running it for similar amount of time was very different. I tested it after running both applications for about 5 min. In firefox, I opened gmail, and many javascript intensive applications, and in paintdotnet I did a couple of renders (Pencil sketching a 8MP photo).
PaintDotNet's number of page faults was around 70,000 where as Firefox, it was 100,000 when it started ( I do have a lot of plugins) and after opening gmail and other such websites, it went up by a factor of 10! Though the memory occupied by Firefox and PaintDotNet were 80MB to 100 MB...
The point is, for the allocated 80 MB heap in PaintDotNet, due to GC, memory is freed resulting in lower page faults than firefox which also uses the same amount of memory.
Mugunth
Thanks & Regards,
M.Mugunth Kumar
M +65 82448625
W http://mugunth.kumar.googlepages.com
B http://tech-mugunthkumar.blogspot.com (Technology Blog) *NEW
Nanyang Technological University,
Wee Kim Wee School of Communication and Information,
31 Nanyang Link, Singapore - 637718.
|
|
|
|
|
Hello,
you comparing two absoluty different worlds which aren't comparable.
As you should know the virtual memory managment depends from many factors.
One point is the internal memory managment and an other the local available heap area (RAM).
All this points presents that this result isn't deterministic.
Ciao...
what*s up...
|
|
|
|
|
That paper is quite impressive, I already found links to it and have to read it. However, studies with opposite conclusions were done in the past - they did not benchmark applications without enough VM (and well, if you're swapping it's obvious that you're gonna be slow - reporting benchmark results is almost redundant on that, or might be useful to give more scary numbers ).
|
|
|
|
|
Thanks William for the answers and the link
|
|
|
|
|
Hey, nice to see you back at Code Project, Bill, although not sure why you are commenting this article which is very substandard and may be removed soon.
William E. Kempf wrote: The JIT (Just In Time) compilation doesn't happen entirely at start time. It literally happens "just in time". In addition, this can be done at installation time instead.
JIT happens whenever it decides it is a best time to happen, but in any case it is easy to observe and impacts performance. I have yet to try a .NET application that starts quickly - even a "hello world" takes a while.
William E. Kempf wrote: Finally, on this point, the IL is specifically designed to be fast to compile.
Which as you know is negatively impacting the optimization of the resulting code. In order to fully optimize the code, a compiler needs time, and JIT does not have time.
|
|
|
|
|
Nemanja Trifunovic wrote: JIT happens whenever it decides it is a best time to happen, but in any case it is easy to observe and impacts performance. I have yet to try a .NET application that starts quickly - even a "hello world" takes a while.
The most significant time spent at start up is just in loading the runtime, not in JIT compiling any code. This startup time is especially significant "the first time". I run a lot of different .NET code, and there's some much more complex applications than "hello world" that will under some circumstances load nearly instantaneously. In contrast, I've used some native applications that take a tremendous amount of time to load. This topic was discussed at length in that shoot-out series of articles I referenced, since load time is definitely a point where native code can almost always out perform, but it's not a cut-and-dried win.
Nemanja Trifunovic wrote: William E. Kempf wrote:
Finally, on this point, the IL is specifically designed to be fast to compile.
Which as you know is negatively impacting the optimization of the resulting code. In order to fully optimize the code, a compiler needs time, and JIT does not have time.
Again, don't focus to much on single variables in the equation. The majority of the optimizations can be performed during the "first compile" as the author calls it. Various optimizations such as loop unrolling, as just one example, can be performed when creating the IL. Higher level optimizations, at least in theory, are available to the JIT compiler, which has a "complete picture" view of the code and the platform. There's lots of material written on this subject as well. Theoretically, at least, you should be able to get better optimizations out of .NET code then with native compilers, despite the drawback you just noted.
There's just no "clear winner" when you talk about performance. There's too many factors to take into account. C++ will perform better in some cases. .NET in others. In theory, you can optimize the C++ code to outperform the .NET code in every case, because of the level of control you have at a low level, but as demonstrated in that shoot-out, the amount of effort is often astronomical and it's VERY unlikely anyone would go to those lengths for anything but the most absolutely time critical operation. I'm willing to bet that 99% of the people who enter these debates have never optimized code to those lengths.
William E. Kempf
|
|
|
|
|
William E. Kempf wrote: I run a lot of different .NET code, and there's some much more complex applications than "hello world" that will under some circumstances load nearly instantaneously.
I have yet to see such application.
William E. Kempf wrote: In contrast, I've used some native applications that take a tremendous amount of time to load.
Xemacs, for instance I never meant to say that it is impossible to make a native application that loads slowly - it is just much easier to write one that loads fast with the "native" language.
<blockquote class="FQ"><div class="FQA">William E. Kempf wrote:</div>Higher level optimizations, at least in theory, are available to the JIT compiler, which has a "complete picture" view of the code and the platform. There's lots of material written on this subject as well. Theoretically, at least, you should be able to get better optimizations out of .NET code then with native compilers, despite the drawback you just noted.</blockquote>
And in practice, you simply don't get good optimizations with JIT. The last time I was doing anything serious with .NET, it was not even able to inline the most obvious cases. There was a lot of marketing hype how JIT "could" produce better could becouse it "could" take into account the specific hardware it runs on. Well, it does not, at least not in practice
William E. Kempf wrote: In theory, you can optimize the C++ code to outperform the .NET code in every case, because of the level of control you have at a low level,
Nothing theoretical about it. If everything else fails, you can easily inline assembly. With C#, you can't inline even IL.
William E. Kempf wrote: I'm willing to bet that 99% of the people who enter these debates have never optimized code to those lengths.
I wouldn't be so sure. There are many areas of development where every cycle counts. Not to mention the memory consumption which is practically impossible to control with a language such as C#.
|
|
|
|
|
Nemanja Trifunovic wrote: Nothing theoretical about it. If everything else fails, you can easily inline assembly. With C#, you can't inline even IL.
Inline assembly is NOT a C++ language solution. That said, though, you're digging to deep into what I meant. When I said "theory", I meant only that there would be some code for which it's simply not possible to optimize beyond what you get out of C#. A long mathematical calculation on an integral type, for instance, is something that doesn't lend itself to the types of optimizations that would provide advantages to C++.
Nemanja Trifunovic wrote: I wouldn't be so sure. There are many areas of development where every cycle counts. Not to mention the memory consumption which is practically impossible to control with a language such as C#.
I figured I was taking this into account by stating 99% and not 100%. Folks who do have to optimize to this level probably aren't coding in either C++ or C#. They're likely coding in either C or ASM. They also have such a deep understanding of this topic, that they are not likely to read entries like this, much less comment on them. Have you read the shoot-out articles? Do you honestly think anybody commenting here has ever optimized their code to the extent that Raymond did?
William E. Kempf
|
|
|
|
|
William E. Kempf wrote: Inline assembly is NOT a C++ language solution.
Correct, but irrelevant. If I find that my C++ compiler is unable to do an optimization I know it is possible, I can easily inline the assembly and do the optimization manually. If I find myself in a similar situation with C#, I am stuck.
William E. Kempf wrote: I figured I was taking this into account by stating 99% and not 100%.
And how did you get to 99%? There are whole industries where native code is a must: embedded development, games, CAD, multimedia, you name it. I am not sure only 1% of the developers work in these industries.
In fact, until recently I worked on high-volume text processing (machine translation, translation memory, etc) and even there we just couldn't use managed code (Java or C#) even if some of us very *very* enthusiastic about it (including me for a period of time). The memory consumption was so high with any GC language we tried that it made our software unusable in practice.
William E. Kempf wrote: Have you read the shoot-out articles? Do you honestly think anybody commenting here has ever optimized their code to the extent that Raymond did?
I have read it. It is mostly about optimizing UI IO, which really shows little about the performance of the languages in which the code is written. There were similar benchmarks in the past "proving" that Java is faster than C++. In fact, it is no secret that the C++ standard IO is embarrassingly slow. Fortunatelly, it is fairly easy to use OS calls directly.
modified on Monday, March 3, 2008 1:48 PM
|
|
|
|
|
Nemanja Trifunovic wrote: Correct, but irrelevant. If I find that my C++ compiler is unable to do an optimization I know it is possible, I can easily inline the assembly and do the optimization manually. If I find myself in a similar situation with C#, I am stuck.
Not necessarily. First, you're wrong about not being able to inline IL. Reflection.Emit provides this sort of capability. This is still just IL, and not the final machine code, though. For that, you have options with P/Invoke. But at this point you've ventured into the realm of optimizations for which neither language is probably the correct one for your problem domain, IMO. Right tool for the right job, and all that.
Nemanja Trifunovic wrote: And how did you get to 99%? There are whole industries where native code is a must: embedded development, games, CAD, multimedia, you name it. I am not sure only 1% of the developers work in these industries.
As a wild guess, as clearly indicated by the "I bet" in the original statement. BTW, in none of the industries you reference is native code a "must". .NET and Java both have been successful in every single one of those industries. Specific applications within those industries I'd agree with you on, and those applications would have a much smaller percentage of developers who've worked on them. This percentage doesn't have to be 1%, for what I said to still hold true, as those developers would have had to participate in a discussion like this, and I suspect they'd have little desire to, since they already understand the concept much too deeply to care about the topic on the level that gets discussed here.
Nemanja Trifunovic wrote: I have read it. It is mostly about optimizing UI IO, which really shows little about the performance of the languages in which the code is written. There were similar benchmarks in the past "proving" that Java is faster than C++. In fact, it is no secret that the C++ standard IO is embarrassingly slow. Fortunatelly, it is fairly easy to use OS calls directly.
There was very little in those articles about IO, and certainly not in optimizing it. Read a little deeper.
William E. Kempf
|
|
|
|
|
William E. Kempf wrote: First, you're wrong about not being able to inline IL. Reflection.Emit provides this sort of capability. This is still just IL, and not the final machine code, though.
I stand corrected
William E. Kempf wrote: This is still just IL, and not the final machine code, though.
Exactly
William E. Kempf wrote: For that, you have options with P/Invoke.
Which incurs significant overhead itself.
William E. Kempf wrote: Right tool for the right job, and all that.
That's all I am saying. Managed code is more than adequate for data-centric business applications, and I am aware that most (but not 99% ) developers are in this niche. But when it comes to performance (and remember, performance is not just CPU, but also the memory), control and easy access to the system, C# is usually not the right tool for the job.
|
|
|
|
|
Nemanja Trifunovic wrote: That's all I am saying. Managed code is more than adequate for data-centric business applications, and I am aware that most (but not 99% ) developers are in this niche. But when it comes to performance (and remember, performance is not just CPU, but also the memory), control and easy access to the system, C# is usually not the right tool for the job.
That's where we'll have to agree to disagree. As I pointed out, C# has been used very effectively in every industry you claimed native was a "must". The most demanding of those would probably have been the gaming industry, where C# does admirably. Your bleeding edge games, of course, will gravitate towards C/C++, and I'm not denying that it's for performance reasons. But you're amplifying this fact well beyond what it can support as a conclusion.
William E. Kempf
|
|
|
|
|
"There's just no "clear winner" when you talk about performance. There's too many factors to take into account. C++ will perform better in some cases. .NET in others. In theory, you can optimize the C++ code to outperform the .NET code in every case, because of the level of control you have at a low level, but as demonstrated in that shoot-out, the amount of effort is often astronomical and it's VERY unlikely anyone would go to those lengths for anything but the most absolutely time critical operation. I'm willing to bet that 99% of the people who enter these debates have never optimized code to those lengths."
--Precisely, this is my point!--
Thanks William E Kempf
Thanks & Regards,
M.Mugunth Kumar
M +65 82448625
W http://mugunth.kumar.googlepages.com
B http://tech-mugunthkumar.blogspot.com (Technology Blog) *NEW
Nanyang Technological University,
Wee Kim Wee School of Communication and Information,
31 Nanyang Link, Singapore - 637718.
|
|
|
|
|