|
I avoided to use optimizations, the basic idea was to keep it generic so to make comparison between languages more meaningful. Also, I can't think of any specific optimization that applies only to C#--the code is rather plain-vanilla, classes, lists and floating point math.
|
|
|
|
|
There is really no way to make a "meaningful" comparison of speed between any language runtimes.
You will always run into situations and implementations that will favor one runtime over another. Make some changes to the code and the favor can easily fall the other way.
Really, what do you do with that data? I know of no one who picks C# or JavaScript for a project because of some "benchmark". You write code that plays the strengths of what you're using.
|
|
|
|
|
Antonino Porcino wrote: Is .NET really that slow?
No, it's not.
You might want to take the environment into consideration; V8 has optimized graphics running on the video-card. If you want to do the same from .NET, you'd have to use CUDA, DirectX or XNA.
You're also comparing something that's compiled to IL to a scripted language (JS) 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: You might want to take the environment into consideration; V8 has optimized graphics running on the video-card.
the use of graphic is minimal and doesn't justify the difference in performance. It's a 640x480 pixel, its drawing time is trascurable.
Eddy Vluggen wrote: You're also comparing something that's compiled to IL to a scripted language (JS)
exactly, what did you expect to run faster?
|
|
|
|
|
Antonino Porcino wrote: the use of graphic is minimal
Enough to make quite a difference.
Antonino Porcino wrote: exactly, what did you expect to run faster?
The JavaScript of course, but only in the V8 engine. It is running in a limited and optimized environment, and should be faster due to the optimizations[^]. You also won't be loading much native assemblies there, as they are already in the environment. Memory will already be reserved by the host.
As for the interpreter - it's a wrong assumption. The IL is run by the Virtual Machine (an interpreter). JavaScript in V8 is translated to machine code.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: Enough to make quite a difference.
By commenting out the RenderPixel() call like this
Color c = new Color(255,23,75,193);
execution time is only 2 seconds, meaning that most of the time (38 secs) is spent in calculating, not in graphics. So graphic is only 5%.
|
|
|
|
|
You're not measuring a calculation there, but the time it requires to reserve memory and create a color
1+1, that's a calculation.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Sorry if I was not clear, what I meant to show was how much it takes to do "graphics only", since you said that drawing a 640x480 is "Enough to make quite a difference".
So I commented out the raytracing calculation, keeping only the code to display pixels on screen. The result is 2 seconds meaning that graphics impact only on the 5% of the total time (40secs) in that program.
|
|
|
|
|
Antonino Porcino wrote: Sorry if I was not clear, what I meant to show was how much it takes to do
"graphics only", since you said that drawing a 640x480 is "Enough to make quite
a difference".
It does make a difference; feeding positions to a OpenGL/DirectX bound surface is rather quick. Standard bitmap-functions aren't meant for real-time graphics. Using the graphics-card makes a huge difference.
Antonino Porcino wrote: So I commented out the raytracing calculation, keeping only the code to display
pixels on screen.
Yes, but you are still comparing two different things, in a rather crude way
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
A quick look at your SimpleRaytracer.cs file shows an unnecessarily large number of class instantiations. You can start off by reducing the number of allocations you're performing. Then howabout firing some of those calculations off onto parallel threads? In other words, play to the strengths.
|
|
|
|
|
One question. Have you tested the V8 code on a none hardware accelerated browser? The Canvas element uses the GPU to draw things when the browser is hardware accelerated. As your C# code is targetting bitmaps directly (something that it's not really designed to do by default), the code is not taking advantage of the GPU.
|
|
|
|
|
yes, but the total time spent in working with the bitmap is only 5% of the total time, so it's not graphics that is causing the bottleneck (see this other reply).
I've analyzed the code, and 65% of the time is spent in clr.dll when Vector3f.operator-() operator overload is called. Don't know what that means or how to avoid it though.
|
|
|
|
|
|
no, it's just a user-defined class:
public class Vector3f {
public number x, y, z;
public Vector3f(number x = 0, number y = 0, number z = 0) {
this.x = x;
this.y = y;
this.z = z;
}
public static Vector3f operator -(Vector3f a, Vector3f b) {
return new Vector3f(a.x - b.x, a.y - b.y, a.z - b.z);
}
|
|
|
|
|
return new Vector3f(a.x - b.x, a.y - b.y, a.z - b.z);
Fetches the field value for x, after fetching object a. Fetches object b, fetches the value of the x field of that instance, and subtracts it from the other value. Does that three times. Create a new vector, and returns that.
Calculations would benefit if they were local variables. Furthermore I'm fairly certain that the "number" datatype does not exist in C#; we call that a "double".
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: Furthermore I'm fairly certain that the "number" datatype does not exist in C#; we call that a "double".
there's an using number = System.double so to make easy to switch from float to double.
|
|
|
|
|
Interesting. Did you get to the bottom of this?
.NET is fast, so something is amiss. I don't know about web stuff like V8, but this looks like code that runs on the CPU rather than the GPU. Pete might be onto something with the number of object instantiations, but these are stupidly fast. It's the GC that comes later that slows things down. I notice you swapped the class for a struct - did that make any difference?
Regards,
Rob Philpott.
|
|
|
|
|
yes there was huge increase (~50%) but still far from Java performances. And also it's not very fair to use it for the benchmark, as the other VM does not have values types (ok, I see the argument of using the best of each language).
|
|
|
|
|
I've found your big holdup. It's this line:
if(x==639) Document.canvas.Refresh(); Basically, you're forcing the user control to refresh its content here, which is slowing you down because you're refreshing on the same thread that you're performing your calculations on.
|
|
|
|
|
I just downloaded your code and ran the C# version. Running the Debug version under Visual Studio took 54 seconds. Running the Release version under Visual Studio took 43 seconds. Running the Release version from the command line took 14 seconds.
Part of the problem here is that you are running everything on the UI thread, so there is nothing at all being offloaded to the GPU.
|
|
|
|
|
I tried calculating bitmap rows on a separate thread, but it was ~2% slower (I guess for the thread preparation overhead). So the problem isn't the UI thread.
I did it sequentially (one single separate thread, no multiple threads) to make it comparable with the other versions (Java, Dart ecc..).
|
|
|
|
|
The problem IS the UI thread. If you don't believe me, which you plainly don't, comment that line out and run it again. You're doing a bare bones GDI implementation here, and this is notoriously inefficient in C#. As this is something that no sane person would ever do in C# using this pattern, you really aren't comparing like for like here. The normal way to do this would be to use unsafe code and standard techniques such as LockBits.
|
|
|
|
|
Pete O'Hanlon wrote: If you don't believe me, which you plainly don't, comment that line out and run it again.
I did that, and also made a better thing: I made a Console version of the program, where all the calculations are done "in memory". As expected, it didn't gain much: from 33 secs it went down to 31 seconds only (in this actual machine).
For me this clearly tells it's not a graphic issue, and it's not a UI thread issue.
|
|
|
|
|
And yet when I took your existing code and commented out 1 line - the Refresh line, it ran in less than 10 seconds. Oh look, a graphics and UI issue - could it possibly be that I know something of what I'm talking about, having dealt with the various vagaries of this stuff for nigh on 14 years.
It's easy for you to replicate this - comment out the Refresh call on your canvas and run your app in Release mode from the command line (don't run it inside Visual Studio).
|
|
|
|
|
Sorry, I don't want to seem crazy or stubborn, but I get different numbers here!
This one is taken with commenting out all the .Refresh() calls and run out of Visual Studio:
Picture 1: no refresh
in this other you can see the original (no comments on refresh and run out of VS) and the Console version (run from prompt):
Picture 2: original + console side by side
So to sum up:
- Original in UI thread: 18 secs
- Refresh commented: 17 secs
- Console 16: secs
these are my numbers.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
