RANDOMIZE TIMER

C# can target the web platform by the use of javascript transpilers. For years I've used "Saltarelle" (now Bridge.NET) with discrete success. It's not like writing in JavaScript directly, but if your are religious about C# it's a good compromise. Also it's a good chance to get used to HTML/CSS from a language/IDE you already know. In time it will become natural to migrate to TypeScript.

Ah, the mighty VIC-20. I still remember that special plastic smell when I first unboxed it, more than 30 years ago.

I remember it very well, I still use CTRL+INS and SHIFT+INS for copying and pasting these days!

thank you for your reply it's really appreciated :-) Agree totally with your considerations, there is lot to optimize in the code, but still that doesn't explain why the Java or the Dart version are much faster (and they don't even have structs). One could point out that it's like comparing apples vs oranges, but Java and C# are very close sharing common traits to the point that the two source codes can be compared line by line. So what's exactly the reason why .NET is so slow here? Do you have an idea?

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.

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.

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..).

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.

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).

no, it's just a user-defined class:

public class /\*struct\*/ 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);
    }

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.

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.

Eddy Vluggen wrote:

Enough to make quite a difference.

By commenting out the RenderPixel() call like this

//Color c = RenderPixel(x, y);
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%.

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?

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.

I'm struggling to understand the cause of the poor performances of the .NET virtual machine when compared to Java (JVM), DartVM or even JavaScript (V8) in this Raytracer demo. In brief: I've written a ray tracer program in various languages: C#, Dart, TypeScript and Java, that I compile both for native virtual machines (CLR, JVM, DartVM) and browsers (thanks to JavaScript compilation). Now when comparing them all, C# running natively is astonishingly slow. What Java calculates in 5 seconds, .NET takes 40 seconds, that is 8 times slower! 3x slower than Dart or JavaScript. Not only, what is really embarrassing is that C# compiled to JavaScript and running in Chrome is 2.5x faster than native C#! How is it that possible? I tried all possible compile switches but nothing seem to be able to cut the execution times. Do you have some possible explanation? Is .NET really that slow? If you like, please have a look at the Github repo and run the tests independently. There must be a flaw somewhere that I can't see. Please help me find it out.

Not having markdown is what holds me writing more articles. Using current editor is fine but too much time consuming.

Talking of C# and AngularJS, an alternative is to cross-compile C# to JavaScript (with compilers like Saltarelle). I have some projects written this way, but it's not an optimal solution because:

• you need a C# import library for Angular (that I've written myself but it's hard to cover all the package)
• Angular itself is very JavaScript oriented, with lot of hacks and tricks, doesn't fit well with C#
• At this point there is no Visual Studio integrated debugging for C#, you can only debug compiled JS code
• working with json and js in general, in C# you find yourself fighting with types, doing lot of conversions and things like that. The dynamic keyword helps but not much.

After reading so much about it, I decided to give a try to TypeScript. I needed to write a large single page webapp, so instead of writing it in C# and compiling to JavaScript (with the Saltarelle compiler), I opted to give a try to TypeScript. After all, everybody was describing an experience similar to C# or Java, so I thought, why not? I struggled one day converting an existing C# application making it work in Typescript. At the end of the day I just gave up, realizing it's not what I was looking for (that is, a language that hides all the JavaScript annoyances). What made me renounce:

• Intellisense sometimes slows down the Visual Studio editor, some other times stops working completely
• Syntax highlight is very basic, e.g. there is no special color for type names, or other semantic elements
• I really hate the ": type" syntax, it made me remember of old pascal days. You can get used to it, but you keep asking WHY??
• Autocompletion works only with the tab or enter key (and not with other symbols like (,= as in C#)
• class implementation lacks all the important features: operator overloads, extension methods and all the rest
• I found that comparing two equal "Date" variables with "==" (and not "===") results in false! Ok, it's due to JavaScript but that's horrible.
• Sometimes the compiler exits with an error without telling you what the error is, just "tsc.exe exit code 1".
• When generating a single global .js file, the compiler doesn't handle class inheritance (what class comes first), so you have to stick with multiple file only.
• Within a class, you have always to refer to "this", it's not optional like in C#. Sometimes it's annoying.
• Found myself often going to CodePlex and discovering it's a known issue

Of course there are good points too:

• debug directly within Visual Studio (break points and all the rest)
• has import types for many javascript libraries (DefinitelyTyped)
• Compared to C#, the dynamic syntax is much nicer for objects (no "new" keyword) and arrays
• I like how interfaces are handled and also the "optional" members (though I dislike the "name?" syntax)

Overall, I would strongly suggest TypeScript only to existing JavaScript users. Developers coming from the Java/C# world are more likely to be disappointed, for them the "Dart" language is more appropriate (but sadly there is no Visual Studio plugin yet). If you have tried TypeScript, what was your experience?