D - Performance.
- Evan McClanahan <evan dontSPAMaltarinteractive.com> Oct 04 2002
- Burton Radons <loth users.sourceforge.net> Oct 04 2002
- Evan McClanahan <evan dontSPAMaltarinteractive.com> Oct 05 2002
- "Walter" <walter digitalmars.com> Oct 05 2002
- Burton Radons <loth users.sourceforge.net> Oct 05 2002
- "Dario" <supdar yahoo.com> Oct 07 2002
- "Dario" <supdar yahoo.com> Oct 07 2002
- "Walter" <walter digitalmars.com> Oct 07 2002
- Burton Radons <loth users.sourceforge.net> Oct 04 2002
- "Walter" <walter digitalmars.com> Oct 04 2002
I ported some C++ code (Mersienne Twister random number generator) to D. It's running at about 70-75% of the speed of the C++ version. Is this because of the alpha-ness of the code generator, or are there some general D optimization tips that I could take advantage of? I've already disabled the GC for the section involved. My version of DMD is .43 and the C++ version is compiled by MSC++ 6. Evan
Oct 04 2002
Evan McClanahan wrote:I ported some C++ code (Mersienne Twister random number generator) to D. It's running at about 70-75% of the speed of the C++ version. Is this because of the alpha-ness of the code generator, or are there some general D optimization tips that I could take advantage of? I've already disabled the GC for the section involved. My version of DMD is .43 and the C++ version is compiled by MSC++ 6.
Are you making sure that nonvirtual methods are converted over properly using the final property? That you're not using -g, and are using -O? Any speed problems, in any case, are not intrinsic to the language.
Oct 04 2002
Burton Radons wrote:Are you making sure that nonvirtual methods are converted over properly using the final property? That you're not using -g, and are using -O? Any speed problems, in any case, are not intrinsic to the language.
Thanks. Final was the problem. I didn't even know that it was a keyword in the language. Not being a Java programmer, I didn't really even have the concept. Google served me well here, but it would be nice if it was final was described in the actual D documentation. In any case, I've learned something and now it's the C++ version that's running at 75% of the speed of the D program, around 14.5m random numbers per second, nearly the speed of the most highly optimized C++ version that I've seen, all without much optimizing. Mine is about 3 times easier to read, as well. Thanks for all the suggestions. Evan
Oct 05 2002
"Evan McClanahan" <evan dontSPAMaltarinteractive.com> wrote in message news:annnb4$1tf8$1 digitaldaemon.com...Thanks. Final was the problem. I didn't even know that it was a keyword in the language. Not being a Java programmer, I didn't really even have the concept. Google served me well here, but it would be nice if it was final was described in the actual D documentation. In any case, I've learned something and now it's the C++ version that's running at 75% of the speed of the D program, around 14.5m random numbers per second, nearly the speed of the most highly optimized C++ version that I've seen, all without much optimizing. Mine is about 3 times easier to read, as well. Thanks for all the suggestions.
Cool! Could your program be turned into a 'benchmark' program we can publish?
Oct 05 2002
Evan McClanahan <evan dontSPAMaltarinteractive.com> Walter wrote:"Evan McClanahan" <evan dontSPAMaltarinteractive.com> wrote in message news:annnb4$1tf8$1 digitaldaemon.com...Thanks. Final was the problem. I didn't even know that it was a keyword in the language. Not being a Java programmer, I didn't really even have the concept. Google served me well here, but it would be nice if it was final was described in the actual D documentation. In any case, I've learned something and now it's the C++ version that's running at 75% of the speed of the D program, around 14.5m random numbers per second, nearly the speed of the most highly optimized C++ version that I've seen, all without much optimizing. Mine is about 3 times easier to read, as well. Thanks for all the suggestions.
Cool! Could your program be turned into a 'benchmark' program we can publish?
It isn't really that useful as a benchmark, I was just looking at generic compiler speed. It's interesting in that it does a number of quite small operations tempering the result of a table, and then after a set number of instructions, rerandomizes the table, so there are two quite distinct behaviors in the one algorthm. It's interesting to see what happens with it in terms of speed, but I'm not sure how good a benchmark it would make. See my reply to Burton for more info. Evan
Oct 06 2002
Evan McClanahan wrote:Burton Radons wrote:Are you making sure that nonvirtual methods are converted over properly using the final property? That you're not using -g, and are using -O? Any speed problems, in any case, are not intrinsic to the language.
Thanks. Final was the problem. I didn't even know that it was a keyword in the language. Not being a Java programmer, I didn't really even have the concept. Google served me well here, but it would be nice if it was final was described in the actual D documentation. In any case, I've learned something and now it's the C++ version that's running at 75% of the speed of the D program, around 14.5m random numbers per second, nearly the speed of the most highly optimized C++ version that I've seen, all without much optimizing. Mine is about 3 times easier to read, as well. Thanks for all the suggestions.
Excellent. It's just an inverted default - C++ defaults to final, D defaults to virtual, but it should be described, as Walter implies that the compiler can optimise virtual methods when he obviously means final. In DLI it would run at 5% the speed. ;-) Could it be eligible for Phobos (BSD or LGPL)? Walter's implementation is, uh, rather limited (as useless as C's) and I have a port of Python's Random class, but it doesn't have claims for speed or such a long period (it's only 6.954e12, not 1e6001). Python's interface with Mersenne Twister RNG would be both fast and convenient.
Oct 05 2002
Burton Radons wrote:Excellent. It's just an inverted default - C++ defaults to final, D defaults to virtual, but it should be described, as Walter implies that the compiler can optimise virtual methods when he obviously means final. In DLI it would run at 5% the speed. ;-) Could it be eligible for Phobos (BSD or LGPL)? Walter's implementation is, uh, rather limited (as useless as C's) and I have a port of Python's Random class, but it doesn't have claims for speed or such a long period (it's only 6.954e12, not 1e6001). Python's interface with Mersenne Twister RNG would be both fast and convenient.
Here is the homepage for the researchers who came up with the algorithm: http://www.math.keio.ac.jp/~matumoto/emt.html They have a BSD license on the code, so it should be fine. Give me a little while to clean it up and add invariants and tests and such, and I'd be more than willing to donate it. For the time being, it's rather messy, uncommented, and a tad inconsistent in style. Not to mention that I don't have the license boilerplate in there. I'll also take a look at the Python interface and see what I can do to make it conformant to that, unless someone has some major disagreements. Evan
Oct 06 2002
Evan McClanahan wrote:such a long period (it's only 6.954e12, not 1e6001). Python's interface with Mersenne Twister RNG would be both fast and convenient.
Not 100% sure about how to structure this though. Rework the current rand into a baseclass, and make MTrandom a subclass? Make MTrandom the lowest level random? This might hose people who need better constrained execution times more than a good source of randomness. Also, I can imliment all of the statistics functions at the end of the python spec for random, but: - Can't really test them, as I don't know what they mean, for the most part. - Are they really needed? - Having them there shys away somewhat from the whole goal of something simple, fast, and good to replace C's rand. Let me know what you think. Evan
Oct 06 2002
I quote from the D programming language specification:
"Templates cannot be used to add non-static members or functions to
classes."
I guess that this cannot be done because the compiler will have problems to
decide if a method should be virtual or not.
Can we add final methods to a class? I can't see a reason why we shouldn't.
e.g.:
class C
{
template insideC(T, U)
{
final func(out T a, in U b) {a = cast(T) b;}
}}
instance insideC(int, float), insideC(float, int), insideC(byte, bit);
Oct 07 2002
I realized that what I've written is nosense... What I meant is a way to provide a quick method to add methods to a class using templates. In the example you see a kinda anonymous template instances (to be accessed as: C c; c.func(12, 12.0);). But maybe it doesn't fit well in the language.I quote from the D programming language specification: "Templates cannot be used to add non-static members or functions to classes." I guess that this cannot be done because the compiler will have problems
decide if a method should be virtual or not. Can we add final methods to a class? I can't see a reason why we
e.g.: class C { template insideC(T, U) { final func(out T a, in U b) {a = cast(T) b;} }} instance insideC(int, float), insideC(float, int), insideC(byte, bit);
Oct 07 2002
"Dario" <supdar yahoo.com> wrote in message news:ans1pv$pch$1 digitaldaemon.com...I realized that what I've written is nosense... What I meant is a way to provide a quick method to add methods to a class using templates. In the example you see a kinda anonymous template
(to be accessed as: C c; c.func(12, 12.0);). But maybe it doesn't fit well in the language.
You can add methods, they'll just need to be static.
Oct 07 2002
Evan McClanahan wrote:I ported some C++ code (Mersienne Twister random number generator) to D. It's running at about 70-75% of the speed of the C++ version. Is this because of the alpha-ness of the code generator, or are there some general D optimization tips that I could take advantage of? I've already disabled the GC for the section involved. My version of DMD is .43 and the C++ version is compiled by MSC++ 6.
Oh, and that you're using the right types. Not accidentally using long when you mean int, that sort of thing (long divide is incredibly expensive, but they're all at least three times as long as the int form).
Oct 04 2002
"Evan McClanahan" <evan dontSPAMaltarinteractive.com> wrote in message news:ankece$q3p$1 digitaldaemon.com...I ported some C++ code (Mersienne Twister random number generator) to D. It's running at about 70-75% of the speed of the C++ version. Is this because of the alpha-ness of the code generator, or are there some general D optimization tips that I could take advantage of? I've already disabled the GC for the section involved. My version of DMD is .43 and the C++ version is compiled by MSC++ 6.
Some possibilities: 1) The D runtime library is currently build with full debug on, which is quite a bit slower than optimal. 2) Are you comparing it with DMC++, or another C++ compiler? DMC++ and DMD share the optimizer/code generator, so that will give an apples-apples comparison of the languages rather than the vagaries of the implementation. 3) Without seeing the code, it is possible that it isn't written to take advantage of D's code gen strengths. 4) Make sure you're compiling with -release.
Oct 04 2002