Stachel

Members
  • Content count

    21
  • Joined

  • Last visited

Community Reputation

100 Neutral

About Stachel

  • Rank
    Member
  1. This is a version of the Spout game written in the D programming language. http://distanthumans.info/programming/D/spout/spout.php
  2. Unity my c++ d c# benchmark!

    Quote:Original post by Raghar Are you saing that there are CPUs where division isn't 80 cycles monstrosity, and multiplication 1 - 1.5 cycle sweety operation?Yes. The 386/387 CPU combination and the 486 have integer division faster than float multiply according to clock cycle counts. Not to mention any processor that doesn't have hardware floating point (seen in embedded processors). It isn't just the multiply, there's the conversion to and from float to add in, plus resetting the rounding mode. I tried this change on my machine. Despite CPU instruction timings saying that the floating multiply should be faster, the actual benchmark timing shows it to be slower. I can't explain this other than the fact that for modern CPUs the cycle counts aren't the whole story. It probably has to do with some internal pipelining/scheduling issue.
  3. Unity my c++ d c# benchmark!

    Quote:Original post by Aldacron Quote:Original post by StachelIt's not about writing a benchmark that favors the way Java works. It's about writing a benchmark that functionally resembles a real application.I'm not sure what your point is. For a real-world application, a Java programmer would code in a manner that favors the way Java works. If a benchmark doesn't reflect that, then it isn't accurate.Think of it like a test in school. There's teaching the test so the students can pass it, then there's teaching knowledge so passing the test falls out naturally. For a benchmark, consider that D supports inline assembler. That means one could write the Pi benchmark entirely in hand-optimized assembler, and that would technically be writing it in D. Nothing could beat that for speed. But is that a reasonable benchmark for D? I'd sure cry foul. I didn't see any special tweaking in the D or C versions of Pi. For the Java benchmark, it's been tweaked to replace (x / 10) with (x * .1f). That's faster on some CPUs, but slower on others. Doesn't that mean the Java JIT should do this transformation on its own because after all, isn't the great strength of the JIT being able to adapt to the particular CPU? If I have to bend my otherwise straightforward Java code around shortcomings in its JIT, that doesn't reflect well on the Java implementation, and it's fair for a benchmark to point that out. If the Java implementation is written to do a good job with straightforward Java source code, then doing well on a benchmark will fall out naturally. I'm not interested in benchmarks custom carefully designed to avoid weaknesses in an implementation, and only show its strength. It's like posting a picture of the good side of your car for sale on ebay, and neglecting to mention that the other side is bashed in and the car won't drive straight. You'll also find that if you do tweaks like (x * .1f), supposedly portable Java source is going to do very badly on some CPUs, and those tweaks may actually sabotage performance if the Java implementation improves. Write benchmarks in a manner that's straightforward to the language being used. Straightforward code is what the language implementors work hardest at improving performance for, so you're not likely to be left in a backwater with oddities like (x * .1f). "Optimizations" like that were once popular with C, and they did work, but with modern compilers such things perform worse than the original unoptimized code.
  4. Unity my c++ d c# benchmark!

    Quote:Original post by MaulingMonkey For all you know, this is significantly faster than the equivilant C/C++ due to optimizaitons based on input data which absolutely could not be made in the equivilant staticly compiled program (because, as that first article mentions, Java is able to make profile guided assumptions, even when those assumptions may later prove invalid for the general case!). For all you know, it's been running faster than the static equivilant for all those hours!I read about the profile guided assumptions, and the theory that JITs can therefore produce faster code. But the results always seem to be missing in action. Here's one set of benchmarks comparing Java with C++: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=java&lang2=gpp Score 1 out of 17 for Java.
  5. Unity my c++ d c# benchmark!

    Quote:Original post by Anonymous Poster Quote:Original post by Stachel Only under the very best of ideal conditions can Java hope to approach static compilation results, and for that the Java app has to run for hours first.Um. Kambiz ran his test for 15 seconds and it was as fast as the statically compiled C version (The C version didn't have decimals shown so the result can be on range 15-15.99). So much for "approaching" the results or "very best ideal conditions" (just a random test written originally for D[*]) or even "running for hours first"... [*] And slightly altered by Promit for .NET The running for hours bit comes from the article cited: "Timing measurements in the face of continuous recompilation can be quite noisy and misleading, and it is often necessary to run Java code for quite a long time (I've seen anecdotes of speedups hours or even days after a program starts running) before obtaining useful performance data." The author, Brian Goetz, is an expert in the field. Secondly, my cited post was not about that particular benchmark, but about Java benchmarking in general, and it was based on the Goetz article. I stated that quite clearly.
  6. Unity my c++ d c# benchmark!

    Quote:Original post by Aldacron Quote:Original post by DaveJFAhhh, the marketing folks have been at it again... That's been promulgated for years by Sun and the Java lobby, and for a few micro-benchmarks, it may even be true <g> Real-life code (especially game code) usually doesn't seem to follow. Not true at all. You can write Java benchmarks and run them differently to see the effects of JIT compilation. Even running with different versions of the JVM will show improvements. The problem is that most people who write Java benchmarks are benchmarking the wrong thing.I'm not so sure of that. It's not about writing a benchmark that favors the way Java works. It's about writing a benchmark that functionally resembles a real application. Quote:JIT compilation doesn't happen instantly. The JVM first runs code in interpreted mode. It will only start compiling after a certain number of executions. Benchmarks that don't take this into account are flawed. If you run a timed loop for a few thousand iterations, you might be getting only interpreted mode -- which is nowhere near being a realistic benchmark. Maybe you will get a mix of interpreted mode and compiled mode, but in that case your results will be skewed by the compilation time. Read more about how to properly benchmark Java in this article and this article.I read the article. What I inferred from it is that Java benchmark results are erratic and often unpredictable, and that the erratic and unpredictable parts always seem to result in slower programs. Only under the very best of ideal conditions can Java hope to approach static compilation results, and for that the Java app has to run for hours first. Even worse than what that does to app speeds, is the corollary that the programmer is going to have a hard time optimizing the algorithms, because he can't get repeatable timings from one run to the next. He can't tell if his algorithm changes are making things better or worse.
  7. Unity my c++ d c# benchmark!

    Quote:Original post by cody nice benchmark. but of course it doesnt cover all performance relevant aspects.Here's a benchmark showing that low level code generation doesn't always matter, sometimes higher level features matter much more: http://www.digitalmars.com/d/cppstrings.d Scroll down to see the benchmark.
  8. Unity my c++ d c# benchmark!

    Quote:Original post by Promit Quote:Original post by Stachel Quote:This is a problem that we can expect to vanish in the next...oh, I don't know, let's say something vague like the next 5-10 years.Or maybe in the next update, if it is an easily correctible problem?It's a damn lucky day when an optimizer problem is easily corrected -- optimization is dangerous business. Though I was actually referring more to the JITted languages. I would agree that just sticking a programmer on an optimizer and expecting him to make non-breaking improvements is unreasonable. But for the experts who do work on them, they may very well be easily corrected. Quote:Quote:C is at a disadvantage with heavy numerical work because of the aliasing problem. It's why Fortran is still preferred (and to be sure, Fortran compilers have gotten the benefit of decades of optimization work by legions of very smart programmers).Looking at the assembly output of the C version, I don't see anything that can be fixed here -- what you're saying may be true for more complex mathematical work, but for this program, the C version is as fast as it gets without hitting machine specific code. Where Fortran shines is its ability to replace entire loops with parallel vectorized code. With C's aliasing problem, such transformations are very nearly impossible, though the new restrict pointer type may help. Quote:Quote:I don't know much about the intrinsics to support MMX, but since DMD already has built in intrinsics for some functions (like sin(), cos(), etc.), then adding more doesn't seem like it would be any more of a problem than it would be to add intrinsics to C. D has an inline assembler with support for MMX, so those instructions can be gotten at that way.Intrinsic support itself is relatively easy to do. The real benefit of intrinsic support is that the optimizer can be conscious of your "assembly" when you use them, and that's a more difficult challenge. It's not an insurmountable challenge -- VC and GCC do it, after all. I'd put my hopes on GDC rather than DMD here. That makes sense. GDC does leverage all the ongoing work done with gcc. There's no technical reason D should be at a disadvantage relative to C. Quote:Quote:The substantial difference here is little more than an optimization folding /% into one instruction rather than two. I don't see any reason why C, C++, D, Java, or C# cannot do that, nor does it seem like a particularly hard optimization to do. All you're seeing is the result of a special case put into the optimizer, not any fundamental language difference.Sure (with the exception of support for vectorized instruction sets, which Java and C# lack). The problem is that introducing a lot of these features into the compiler is difficult to do well, and requires extensive testing. I can't claim to know why CLR can't do this optimization. There's no reason D can't do it, but it doesn't, which leads back into the original objection I expressed in the other thread -- D lacks developer support and maturity that the other languages, C and C++ in particular, have. Without that, they're screwed. This is why D is obviously built to leverage existing technology. Both DMD and GDC are built on top of well developed C compilers. C libraries are directly accessible from D. C header files can be mechanically converted to D. I think you place too much of a store on the /% optimization; in my experiments DMD will do that optimization in other circumstances.
  9. Unity my c++ d c# benchmark!

    Quote:Original post by Promit On later reflection, I decided that DMD probably botches this somewhat machine specific optimization in exactly the same way. Examining the assembler output of DMD shows what you suspect is true. Strangely, in other cases, DMD does do that optimization. So it looks like a compiler problem that can be easily corrected. Quote:This is a problem that we can expect to vanish in the next...oh, I don't know, let's say something vague like the next 5-10 years.Or maybe in the next update, if it is an easily correctible problem? Quote:It's pretty obvious that math performance is hardly ideal in the managed world -- and as I said at the beginning, we're playing on C's home turf. We can't win here. C is at a disadvantage with heavy numerical work because of the aliasing problem. It's why Fortran is still preferred (and to be sure, Fortran compilers have gotten the benefit of decades of optimization work by legions of very smart programmers). Quote:Lastly, realize that if someone were to break out the MMX intrinsics, everything except C would be seriously screwed. You'd be looking at times for the C code that were about 1/4 to 1/3 what they are now. DMD, C#, and Java wouldn't be able to touch that -- and we can't even do autovectorization like that statically, let alone in a JITter. I don't know much about the intrinsics to support MMX, but since DMD already has built in intrinsics for some functions (like sin(), cos(), etc.), then adding more doesn't seem like it would be any more of a problem than it would be to add intrinsics to C. D has an inline assembler with support for MMX, so those instructions can be gotten at that way. Quote:Let's be frank. The non-C languages here all manage to make a positively lame turnout. DMD, C#, and Java are all very respectable after my modifications, and certainly adequate for nearly all real world applications, but it took extra work to get there. In my case it was only 15 minutes because I knew what I was doing -- for a less experienced developer, or more complex code, the story could get much worse. There are lots of situations where C# and Java can outperform C/C++ code, but tight math and array accesses are obviously not one of them. The substantial difference here is little more than an optimization folding /% into one instruction rather than two. I don't see any reason why C, C++, D, Java, or C# cannot do that, nor does it seem like a particularly hard optimization to do. All you're seeing is the result of a special case put into the optimizer, not any fundamental language difference.
  10. Unity my c++ d c# benchmark!

    Quote:Original post by h3r3tic Looks like DMD is missing some optimization oportunities in the div and mul functions.I did a little experimenting and found out that the performance hinges upon whether the / and % operations are done together with one divide instruction, or separately with two. Doing them separately nearly doubles the benchmark time. The divide instruction is one expensive operation. All the benchmark does is test whether that optimization is being done or not. The DMD and C# compilers are deficient in not doing it, but that isn't a deficiency in the languages, just their compiler implementations.
  11. Unity my c++ d c# benchmark!

    Quote:Original post by Kambiz I'm just surprised a little: I thought that D shouldn't be much slower than c++ and I thought that c# would be much faster. Maybe there is some optimization option I have not used(?) What do you think about the results? Interesting, but you're comparing the Microsoft C++ optimizer with the Digital Mars C++ optimizer. DMD, the Digital Mars D compiler, is built using the Digital Mars C++ optimizer. To compare apples-apples, it makes sense to compare DMD versus DMC++, or GDC versus g++, as then the optimizer and code generator would be the same for each language. I tried DMD and DMC++, and got essentially the same times for each.
  12. Quote:Original post by Telastyn In VS2005 at least, you can collapse C# code to definitions so it looks exactly like a c++ header, only without the compilation annoyances and logistical hooplah.In D programming, you can either use headers or not. Most projects would probably not bother with headers, just import the (complete) module directly. For a library, strip out the module implementation leaving just the declarations. The D compiler can do this, generating a header module directly from a regular module. There's a program to automatically translate a C .h header file to a D import. It'd be cool if there was one for C++ headers, too, but alas.
  13. Quote:Original post by Promit Quote:Original post by Stachel D does have an advantage, because (as I wrote) it is reasonably feasible to get it to work on any platform that gcc supports, which is much wider than mono's. If a manufacturer has C support, it is more than likely going to be gcc, so a code generator is available for D. It is not credible for a developer to write their own JIT for mono.It isn't feasible, reasonable, or smart for a developer to port D to their target platform (or Mono, or JVM, or anything else). You're seriously underestimating the amount of work required. Since GDC works with the gcc toolkit, getting D to a new platform that gcc already supports is a matter of recompiling it. As I said, I'm sure there'll probably be a few tweaks and glitches in the process to take care of, but that's nothing like needing the time and expertise to write a JIT. If it isn't feasible or reasonable, then existing GDC multiplatform support would never have happened. If you want to see such in action, there's a D.gnu newsgroup on the digital mars site where the developers discuss it. As posted there, porting to 64 bit linux required a few pages of patches. It's not that big a deal to do a port. If you still think it's on the level of complexity of porting JVM or mono, please explain why.
  14. Quote:Original post by Promit Quote:Original post by Promit Quote:As for me, I wouldn't use C# for the simple reason that it attaches me at the hip to one platform. What if you write the next big game hit in C#, and want to move it to the new Nintendo/Sony Gee-Whiz game box which has no .net on it?That's legitimate. [...] Now don't get me wrong, the above story applies almost verbatim to C#, just with Mono instead of GDC. That's exactly why professional development is is not using C#; being locked out of consoles is not acceptable. However, D doesn't really have an advantage in this area, nor does Java or anything other than the native language which the manufacturer is supporting -- which is always C++.You'd think people would at least read the things I write. But no, instead I'm assigned the opinions people think I'm supposed to have. I never even implied C# was suitable for professional game development. No languages other than C or C++ are, and there's no indication that their momentum will run out any time soon. (What I did imply is that as far as performance goes, C# is comfortably fast enough for professional game development.) D does have an advantage, because (as I wrote) it is reasonably feasible to get it to work on any platform that gcc supports, which is much wider than mono's. If a manufacturer has C support, it is more than likely going to be gcc, so a code generator is available for D. It is not credible for a developer to write their own JIT for mono.
  15. Quote:Original post by Conner McCloud By the way, I'm not sure if you're aware of this, but generally speaking the correct spelling is C++. I know its easy to get confused, what with + being pronounced plus and all. The trouble is, for some reason the pluses don't appear, so it looked like I was writing just plain C with a blank after it in the preview window. I don't know what the problem is with the forum software. I suppose some kind of escape is necessary, but I don't know what it is. So rather than be misunderstood, I wrote it as 'plus'.