View previous topic :: View next topic |
Is D.NET a good idea? |
Yes. |
|
56% |
[ 18 ] |
No. |
|
28% |
[ 9 ] |
I don't care. |
|
15% |
[ 5 ] |
|
Total Votes : 32 |
|
Author |
Message |
StringCheesian
Joined: 31 Mar 2005 Posts: 17
|
Posted: Mon Apr 25, 2005 12:34 pm Post subject: |
|
|
aldacron wrote: | Your list of disadvantages falls short, as they either aren't disadvantages at all, or they are outweighed by the benefits/advantages. [...] |
Ok, I concede on every point except runtime compilation. I guess there more advantages than I thought. But if conversion to native machine code is taking up any time at runtime, then you can't call it native machine code.
aldacron wrote: | Runtime compilation can potentially cause either language to outperform a statically compiled application in some circumstances. In reality, you wind up with such a small difference in performance as to be negligible. |
Yeah, right. See The Computer Language Shootout Benchmarks and other sites like it to see how virtual machine'd languages stack up. Apparently (from any benchmarks I've seen), the reality is that runtime compilation rarely outperforms statically compiled languages, and the difference appears far greater than negligible (in some cases 1/2 the speed - yuck!). I'd say the few areas where they do perform decently aren't enough.
Also, statically compiled languages can benefit from precessor specific optimizations - all you have to do is recompile it. I'm a Gentoo Linux user, and almost every package on my linux partition is compiled with -march=athlon-xp. That's the best of both worlds - it's not being slowed down by having to run while being recompiled at the same time. |
|
Back to top |
|
|
aldacron
Joined: 05 May 2004 Posts: 1322 Location: Seoul, South Korea
|
Posted: Tue Apr 26, 2005 3:34 am Post subject: |
|
|
StringCheesian wrote: |
aldacron wrote: | Runtime compilation can potentially cause either language to outperform a statically compiled application in some circumstances. In reality, you wind up with such a small difference in performance as to be negligible. |
Yeah, right. See The Computer Language Shootout Benchmarks and other sites like it to see how virtual machine'd languages stack up. Apparently (from any benchmarks I've seen), the reality is that runtime compilation rarely outperforms statically compiled languages, and the difference appears far greater than negligible (in some cases 1/2 the speed - yuck!). I'd say the few areas where they do perform decently aren't enough.
|
I said potentially. Runtime compilation theory is certainly not new, but production implementations are still very young. If you follow the evolution of Java, each version of Hotspot has an overall performance improvement over the previous version. It's an evolutional process that hasn't yet reached it's maximum potential.
As to the Shootout, it just does not accurately reflect the potential of most of the languages involved, C# and Java included. Performance benefits from Runtime compiled languages come over the lifecycle of the program. For example, Java has two runtime modes - client and server. The Server VM spends more time analyzing the code before compiling it (this is based on the assumption that servers run for longer periods that clients - hence the naming scheme). This gives it the ability to make more intelligent optimizations than the client VM, which analyzes code over fewer iterations. As a result, the client VM almost always outperforms the server VM over short periods of time. But the Server VM very often outperforms the client VM when running an app over longer periods. So benchmarking particular algorithms is a tricky business. You must first give the runtime compiler a 'warm up' period (i.e. run the alogrithm for several iterations before timing it), otherwise you are profiling interpreted code and not natively compiled code. And even so, you will never get an accurate picture of the time an algorithm takes to execute in comparison to other languages.
Looking through some of the Java source on the Shootout site, I see they aren't warming up the VM at all. Furthermore, they are running the server VM for each benchmark. Look at these command lines:
Quote: |
/usr/lib/j2sdk1.4.2_05/bin/java -server -classpath ackermann.java_run ackermann ?A
/usr/lib/j2sdk1.4.2_05/bin/java -server -classpath wc.java_run wc ?A
/usr/lib/j2sdk1.4.2_05/bin/java -server -classpath fannkuch.java_run fannkuch ?A
/usr/lib/j2sdk1.4.2_05/bin/java -server -classpath harmonic.java_run harmonic ?A
/usr/lib/j2sdk1.4.2_05/bin/java -server -classpath heapsort.java_run heapsort ?A
|
I haven't looked at the rest, but all of those are running the server VM. Yet, look at the main loop for the 'harmonic' benchmark:
Quote: |
public static void main(String[] args) {
int n = 10000000;
if (args.length > 0) n = Integer.parseInt(args[0]);
double partialSum = 0.0;
for (int i=1; i<=n; i++) partialSum += 1.0/i;
System.out.println(formatter.format(partialSum));
}
|
There's no warmup period at all. The others I looked at do the same. So in essence, the benefits of the server VM are thrown right out the window, and what actually is being measured is interpreted bytecode. Of course it's going to be slow. Move the alogrithm into a separate method, call it from main several times, then call it once more and time it. Run it without the -server argument (as that will require even more time to 'warmup'). To be sure it has time to compile, run it a few times with the -XXPrintCompilation arg. Now you have a clearer picture of runtime compiled Java, but probably still not accurate.
Take a look here and here for more info on this topic as it relates to Java. Note that both of these articles are linked from the Shootout on the Flawed Benchmarks page. Also note that the info in the articles likely apply to languages like C# and other runtime compiled languages as well.
Quote: |
Also, statically compiled languages can benefit from precessor specific optimizations - all you have to do is recompile it. I'm a Gentoo Linux user, and almost every package on my linux partition is compiled with -march=athlon-xp. That's the best of both worlds - it's not being slowed down by having to run while being recompiled at the same time. |
Yes, I realize you can recompile and redistribute. My point was that runtime compilation cuts that out of the loop. As soon as your user upgrades his processor, the app benefits from it the next time it is run without the need for the developer to do a thing. Besides which, how many commercial applications have you seen be distributed for multiple CPU targets? The most common practice is to optimize compilation for the lowest processor you support and be done with it.
The total cost of runtime compilation isn't as high as you might think it would be when you look at the lifetime of the application. People like to pull figures out of the air - I've heard Java supporters say Java apps often run within 3?-5? of C apps, and detractors say it's more like 30? or 40?. They're all full of hot air. You can't compare performance like that unless you right the exact same program optimized for each language. What you can do is write a program in a particular language and see if it meets or exceeds your expectations.
Finally, languages like Java and C# are more succeptible to performance problems resulting from incompetence. It's very easy for a naive programmer to introduce visible GC pauses, slow startup times, and skyrocketing memory usage in Java, for example. Someone making the move to Java for the first time will likely try to code the way he did in C++ or whatever language he came from. That's a no-no. Some people get the impression that because of the GC and lack of pointers, memory leaks aren't possible. That's another no-no. Compare Josh Bloch's Effective Java with Scott Meyers' Effective C++. That alone will highlight how Java's paradigm the same as C++. Bloch's book is filled with stuff seasoned Java programers know (and a few things they might not) - things that most newcomers don't get.
So, a knowledge of how to program in a language like Java or C# (how to keep the GC happy, which GC to use - Java offers more than one - how to make life easy for the runtime compiler, what to do and what not to do, etc...) coupled with runtime compilation really can get you excellent performance. I assure you, you can meet or exceed your performance expectations the vast majority of the time. Take a look at the game Tibal Trouble. You can download and install the demo, which includes the Java 5 VM. Ask yourself the question - if they didn't advertise it on the site, would you have even guessed that it was written with Java? |
|
Back to top |
|
|
StringCheesian
Joined: 31 Mar 2005 Posts: 17
|
Posted: Tue Apr 26, 2005 11:57 am Post subject: |
|
|
I might actually like it if it converted to native code only once at install time, kind of like Gentoo but with bytecode that compiles/installs faster than source code. Then there would no slowdown at runtime.
I just find disturbing any overhead that could be avoided but isn't. |
|
Back to top |
|
|
saivert
Joined: 15 Aug 2005 Posts: 8 Location: Norway
|
Posted: Tue Aug 16, 2005 6:24 pm Post subject: I believe in D.NET |
|
|
I don't want it to be called D# (D sharp) which is what you guys call an implementation of D.NET made by Microsoft.
I wish someone a bit up in the skies here at the D department to IM with one or more MS developers (they got lots of blogs over at MSDN) and talk it out. I am sure MS will support (although not endorse) a D for .NET language because it has great potencial and face it guys, C# is based on C++ and we all know that C++ is outdated. The fact they even keep on doing the same alphabetical letter is a sign of weakness (okay that one was childish said).
I don't think D.NET is a foolish dream. I know in my heart that D.NET will become a reality one way or another. Either done by individuals or as a project together with Microsoft.
I don't know how many people actually use J# (JSharp or Java for .NET) but this is a langauge that came along pretty quickly. Even with .NET v1.0 we had a official J# compiler. Most popular language is of course VB.NET since most VB kids know this and there is no serious reason to use C# over VB.NET as long as you have access to the same assemblies.
I would really wish D a good luck in the future on both sides (.NET and native/system programming). _________________ - New at D, like it though - Attending Kongsberg Tekniske Fagskole (Computer technician course) - |
|
Back to top |
|
|
csauls
Joined: 27 Mar 2004 Posts: 278
|
Posted: Tue Aug 16, 2005 9:29 pm Post subject: |
|
|
A fellow D-er by the name of Deja Augustine was actually building a D.Net compiler as of late last year... We haven't heard anything out of it for months now, though, as far as I'm aware. Which is a shame: it was making real headway. _________________ Chris Nicholson-Sauls |
|
Back to top |
|
|
jcc7
Joined: 22 Feb 2004 Posts: 657 Location: Muskogee, OK, USA
|
Posted: Wed Aug 17, 2005 5:41 am Post subject: |
|
|
csauls wrote: | We haven't heard anything out of it for months now, though, as far as I'm aware. Which is a shame: it was making real headway. | (Originally posted at Wiki4D)
I've asked Deja about the possibility of a D.NET revival (such as a version that doesn't require Microsoft's VC++ 2005 Express Beta). If he has time this summer, he's interested in continuing the project. Since he lost the previous source to D.NET, he'd have to start again from scratch. On the other hand, he now knows a lot more about the DMD front end than since he started D.NET, so a fresh start would be beneficial. |
|
Back to top |
|
|
Shawn Liu
Joined: 09 Mar 2005 Posts: 104 Location: Shanghai, China
|
Posted: Wed Aug 17, 2005 9:35 pm Post subject: |
|
|
Absolutely NO.
If I use .Net, why not C# directly? Those features are enough in C# and the Frameworks is better. |
|
Back to top |
|
|
antonio
Joined: 23 Aug 2005 Posts: 10
|
Posted: Wed Aug 24, 2005 10:03 am Post subject: |
|
|
stjepan wrote: | I hate Virtual Machines!
I like D because it doesn't have Vm. |
I prefer to say: I hate Virtual Machines sometimes... .
I think the good way could be to implement a Standard D framework closed similar to .Net using native code... ex: a good ADO.Net native for D, I think that this is the real power of .Net: the framework... the bad idea is thah this framework is interpreted (Virtual Machine)...
Mono project is producing an alternative framework... then, its posible to produce an alternative Native framework y D... well... we only need a good debugger for speedy problems solutions... but this is only my opinion.
Antonio |
|
Back to top |
|
|
antonio
Joined: 23 Aug 2005 Posts: 10
|
Posted: Tue Aug 30, 2005 9:22 am Post subject: |
|
|
Shawn Liu wrote: | Absolutely NO.
If I use .Net, why not C# directly? Those features are enough in C# and the Frameworks is better. |
I Agree.
D needs it's own Framework
Antonio. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|