digitalmars.D - Re: D vs. C#
- bearophile <bearophileHUGS lycos.com> Oct 24 2007
- Radu <radu.racariu void.space> Oct 24 2007
- Joel Lucsy <jjlucsy gmail.com> Oct 24 2007
- bearophile <bearophileHUGS lycos.com> Oct 24 2007
- Robert Fraser <fraserofthenight gmail.com> Oct 24 2007
- Bruce Adams <tortoise_74 yeah.who.co.uk> Oct 24 2007
- "Dave" <Dave_member pathlink.com> Oct 24 2007
- Bruce Adams <tortoise_74 yeah.who.co.uk> Oct 25 2007
- "Dave" <Dave_member pathlink.com> Oct 25 2007
I like D better. But C# has some advantages too, two things I have personally seen (beside the IDE, the STD lib, the more widespread usage, the standard GUI toolkit, etc): - Using strings as keys the unordered Associative Arrays of C# (on dotnet 3.0) are up to many times faster than D AAs, expecially when the memory used by the AA becomes large (like 50 MB). - C# VM is able to parallelize code by itself, so if you have two CPU cores even small proggies with loops can end being quite faster (up to almost two times faster, in some tests I have done), and you don't need to change your sourcecode to do that (in C++ you can use OpenMP but you have to modify the code and you have to be careful, to avoid breaking your code in many interesting ways). - The VM allows you to use different languages, like IronPython, F#, etc, sometimes you can even mix them to write your languages. (Note: the shootout used Mono, not dotnet, that is probably much faster). Bye, bearophile
Oct 24 2007
bearophile wrote:- C# VM is able to parallelize code by itself, so if you have two CPU cores even small proggies with loops can end being quite faster (up to almost two times faster, in some tests I have done), and you don't need to change your sourcecode to do that (in C++ you can use OpenMP but you have to modify the code and you have to be careful, to avoid breaking your code in many interesting ways).
Some C++ compilers pretend to do that also, mainly Intel Compilers (http://www.intel.com/cd/software/products/asmo-na/eng/compilers/cwin/279578.htm). I see no reason why D can't do that also, especially with new constructs coming in 2.0.
Oct 24 2007
bearophile wrote:- C# VM is able to parallelize code by itself, so if you have two CPU cores even small proggies with loops can end being quite faster (up to almost two times faster, in some tests I have done), and you don't need to change your sourcecode to do that (in C++ you can use OpenMP but you have to modify the code and you have to be careful, to avoid breaking your code in many interesting ways).
Oh? Since when? I know for a fact it doesn't, especially since MS has a new library they are constructing for .Net 3.5. Some links are: http://msdn.microsoft.com/msdnmag/issues/07/10/PLINQ/default.aspx http://en.wikipedia.org/wiki/Task_Parallel_Library#TPL -- Joel Lucsy "The dinosaurs became extinct because they didn't have a space program." -- Larry Niven
Oct 24 2007
Joel Lucsy Wrote:Oh? Since when? I know for a fact it doesn't, especially since MS has a new library they are constructing for .Net 3.5.
I have done real tests of the nbody problem (from the Shootout site) of the C# code on an beta version of dotnet 3.0 and it runs almost two times faster than the D version (and the C++ version without parallel annotations), I have done those tests with a friend :-) I have seen with my eyes that it uses both cores of the CPU while running, while the D version uses one only. So maybe we are talking about a bit different things... There are many ways to mess things with quick tests, so I won't push this topic more :-) Bye, bearophile
Oct 24 2007
bearophile Wrote:Joel Lucsy Wrote:Oh? Since when? I know for a fact it doesn't, especially since MS has a new library they are constructing for .Net 3.5.
I have done real tests of the nbody problem (from the Shootout site) of the C# code on an beta version of dotnet 3.0 and it runs almost two times faster than the D version (and the C++ version without parallel annotations), I have done those tests with a friend :-) I have seen with my eyes that it uses both cores of the CPU while running, while the D version uses one only. So maybe we are talking about a bit different things... There are many ways to mess things with quick tests, so I won't push this topic more :-) Bye, bearophile
Indeed, automatic parallelization is a strong argument for VMs right now, since it doesn't require code modification. At the conference, Walter mentioned that D might be getting automatic parallelization of pure functions, though. I'm just afraid this won't apply to member functions, and since my programming style is so OO, it won't help me.
Oct 24 2007
Robert Fraser Wrote:bearophile Wrote:Joel Lucsy Wrote:Oh? Since when? I know for a fact it doesn't, especially since MS has a new library they are constructing for .Net 3.5.
I have done real tests of the nbody problem (from the Shootout site) of the C# code on an beta version of dotnet 3.0 and it runs almost two times faster than the D version (and the C++ version without parallel annotations), I have done those tests with a friend :-) I have seen with my eyes that it uses both cores of the CPU while running, while the D version uses one only. So maybe we are talking about a bit different things... There are many ways to mess things with quick tests, so I won't push this topic more :-) Bye, bearophile
Indeed, automatic parallelization is a strong argument for VMs right >now, since it doesn't require code modification. At the conference, >Walter mentioned that D might be getting automatic parallelization of >pure functions, though. I'm just afraid this won't apply to member >functions, and since my programming style is so OO, it won't help me.
Why is that an argument for VMs? There's no reason a compiler backend can't write code that paralelises to multiple CPUs. M$ has a lot of money and bodies to through at the problem so its managed to get something up and running quickly. We open sourcers need to pull our fingers out and leverage our synergies. :)
Oct 24 2007
"bearophile" <bearophileHUGS lycos.com> wrote in message news:ffodsg$13q2$1 digitalmars.com...Joel Lucsy Wrote:Oh? Since when? I know for a fact it doesn't, especially since MS has a new library they are constructing for .Net 3.5.
I have done real tests of the nbody problem (from the Shootout site) of the C# code on an beta version of dotnet 3.0 and it runs almost two times faster than the D version (and the C++ version without parallel annotations), I have done those tests with a friend :-) I have seen with my eyes that it uses both cores of the CPU while running, while the D version uses one only. So maybe we are talking about a bit different things... There are many ways to mess things with quick tests, so I won't push this topic more :-)
That sounds interesting - do you have a download link for the new runtime? Lately MS has been allowing the general public to download that type of stuff. I just got a dual-core machine and would like to see how it runs. Last I looked, they had a v3.0 and now v3.5 beta Framework, but that just used the v2.xxx runtime. Thanks.Bye, bearophile
Oct 24 2007
bearophile Wrote:I like D better. But C# has some advantages too, two things I have personally seen (beside the IDE, the STD lib, the more widespread usage, the standard GUI toolkit, etc): - Using strings as keys the unordered Associative Arrays of C# (on dotnet 3.0) are up to many times faster than D AAs, expecially when the memory used by the AA becomes large (like 50 MB). - C# VM is able to parallelize code by itself, so if you have two CPU cores even small proggies with loops can end being quite faster (up to almost two times faster, in some tests I have done), and you don't need to change your sourcecode to do that (in C++ you can use OpenMP but you have to modify the code and you have to be careful, to avoid breaking your code in many interesting ways). - The VM allows you to use different languages, like IronPython, F#, etc, sometimes you can even mix them to write your languages. (Note: the shootout used Mono, not dotnet, that is probably much faster). Bye, bearophile
Can you post a link? As far as I can see from my random googling M$ have a library based solution. The VM is doing nothing special. Take for example: http://msdn.microsoft.com/msdnmag/issues/07/10/Futures/default.aspx Basically they seem have a few of useful primatives (at the library level) like parallel.for and "delegate" which is more akin to unix fork() but at the thread level than to D delegates. Another useful abstraction is a scheduler though this "dispatcher" seems limited to use in UIs. Another couple of useful abstractions are futures and replicatible classes. Regards, Bruce.
Oct 25 2007
"Bruce Adams" <tortoise_74 yeah.who.co.uk> wrote in message news:ffph3r$6ji$1 digitalmars.com...bearophile Wrote:I like D better. But C# has some advantages too, two things I have personally seen (beside the IDE, the STD lib, the more widespread usage, the standard GUI toolkit, etc): - Using strings as keys the unordered Associative Arrays of C# (on dotnet 3.0) are up to many times faster than D AAs, expecially when the memory used by the AA becomes large (like 50 MB). - C# VM is able to parallelize code by itself, so if you have two CPU cores even small proggies with loops can end being quite faster (up to almost two times faster, in some tests I have done), and you don't need to change your sourcecode to do that (in C++ you can use OpenMP but you have to modify the code and you have to be careful, to avoid breaking your code in many interesting ways). - The VM allows you to use different languages, like IronPython, F#, etc, sometimes you can even mix them to write your languages. (Note: the shootout used Mono, not dotnet, that is probably much faster). Bye, bearophile
Can you post a link? As far as I can see from my random googling M$ have a library based solution. The VM is doing nothing special. Take for example: http://msdn.microsoft.com/msdnmag/issues/07/10/Futures/default.aspx Basically they seem have a few of useful primatives (at the library level) like parallel.for and "delegate" which is more akin to unix fork() but at the thread level than to D delegates. Another useful abstraction is a scheduler though this "dispatcher" seems limited to use in UIs. Another couple of useful abstractions are futures and replicatible classes.
I searched the MS site for a beta of the .NET runtime as well with no luck. I'd like to see a link also.Regards, Bruce.
Oct 25 2007