What Language is used to program Distant Worlds?

[taltamir]

ORIGINAL: Kumppi

ORIGINAL: JonBrave

Whilst it's true that the end code all ends up as CIL/CLR, I don't agree at all with your assertion that the source langauge "doesn't really matter".

It doesn't really matter. C# and VB.NET produce the same IL code which in turn is compiled to native processor instructions by the just-in-time compiler when run.

no, they produce different code in the same IL which is then compiled to different instructions using the same instruction set of the processor by the just-in-time compiler.
there is a huge difference between "same language" and "same code".

heck, you get different bytecode just by switching the compiler (on the same exact C code). Compilers aren't magic or perfect.

[Kumppi]

ORIGINAL: taltamir

ORIGINAL: Kumppi

It doesn't really matter. C# and VB.NET produce the same IL code which in turn is compiled to native processor instructions by the just-in-time compiler when run.

no, they produce different code in the same IL which is then compiled to different instructions using the same instruction set of the processor by the just-in-time compiler.
there is a huge difference between "same language" and "same code".

heck, you get different bytecode just by switching the compiler (on the same exact C code). Compilers aren't magic or perfect.

There are only slight differences between the IL code outputted by the C# and VB.NET compilers. The whole point for creating IL code is that it is platform neutral unlike C/C++ compilers which compile straight to specific platforms.

[JonBrave]

ORIGINAL: Kumppi

ORIGINAL: taltamir

ORIGINAL: Kumppi

It doesn't really matter. C# and VB.NET produce the same IL code which in turn is compiled to native processor instructions by the just-in-time compiler when run.

no, they produce different code in the same IL which is then compiled to different instructions using the same instruction set of the processor by the just-in-time compiler.
there is a huge difference between "same language" and "same code".

heck, you get different bytecode just by switching the compiler (on the same exact C code). Compilers aren't magic or perfect.

There are only slight differences between the IL code outputted by the C# and VB.NET compilers. The whole point for creating IL code is that it is platform neutral unlike C/C++ compilers which compile straight to specific platforms.

I don't mean to be rude, but I am totally with taltamir and not agreeing with you or impact. The issues of the IL code are neither here nor there. To say that because two source programming languages happen to produce similar IL code means that "doesn't really make a difference" which one you use is just....

Heck, at the end of that day, every single programming language that has ever been invented ends up having to produce something which runs natively on the target, by definition, whether it is compiled or there is an interpreter (Turing machine, anyone?). That's the equivalent of common IL, but to extrapolate from that you could say it doesn't matter whether you program in assembler/COBOL/C/Prolog. But it most certainly does, because different languages are better suited to quite different tasks. F#.NET will also produce IL like VB/C#.NET, but I don't think you'll find the progammers would have chosen that...

If you looked at Distant World's code, I would guarantee that 1%(-ish) has much to do with the machine/OS/IL/.NET, while 99% will be logic and how you approach it, how you use the language to achieve your goals.

[Kumppi]

ORIGINAL: JonBrave

ORIGINAL: Kumppi

There are only slight differences between the IL code outputted by the C# and VB.NET compilers. The whole point for creating IL code is that it is platform neutral unlike C/C++ compilers which compile straight to specific platforms.

I don't mean to be rude, but I am totally with taltamir and not agreeing with you or impact. The issues of the IL code are neither here nor there. To say that because two source programming languages happen to produce similar IL code means that "doesn't really make a difference" which one you use is just....

Heck, at the end of that day, every single programming language that has ever been invented ends up having to produce something which runs natively on the target, by definition, whether it is compiled or there is an interpreter (Turing machine, anyone?). That's the equivalent of common IL, but to extrapolate from that you could say it doesn't matter whether you program in assembler/COBOL/C/Prolog. But it most certainly does, because different languages are better suited to quite different tasks. F#.NET will also produce IL like VB/C#.NET, but I don't think you'll find the progammers would have chosen that...

If you looked at Distant World's code, I would guarantee that 1%(-ish) has much to do with the machine/OS/IL/.NET, while 99% will be logic and how you approach it, how you use the language to achieve your goals.

At no point did I say that it doesn't make a difference if you use assembler/COBOL/C or prolog or ruby or php or whatever. What I said was that when run under the CLR the code produced by C# or VB.NET compilers when considering PERFORMANCE makes no difference.

So let me reiterate. When you target CLR it doesn't really make a difference if you choose C# or VB.NET. The only thing that matters is which language is better suited to do the task and most obviously which one you know.

[taltamir]

ORIGINAL: Kumppi

ORIGINAL: JonBrave

ORIGINAL: Kumppi

There are only slight differences between the IL code outputted by the C# and VB.NET compilers. The whole point for creating IL code is that it is platform neutral unlike C/C++ compilers which compile straight to specific platforms.

I don't mean to be rude, but I am totally with taltamir and not agreeing with you or impact. The issues of the IL code are neither here nor there. To say that because two source programming languages happen to produce similar IL code means that "doesn't really make a difference" which one you use is just....

Heck, at the end of that day, every single programming language that has ever been invented ends up having to produce something which runs natively on the target, by definition, whether it is compiled or there is an interpreter (Turing machine, anyone?). That's the equivalent of common IL, but to extrapolate from that you could say it doesn't matter whether you program in assembler/COBOL/C/Prolog. But it most certainly does, because different languages are better suited to quite different tasks. F#.NET will also produce IL like VB/C#.NET, but I don't think you'll find the progammers would have chosen that...

If you looked at Distant World's code, I would guarantee that 1%(-ish) has much to do with the machine/OS/IL/.NET, while 99% will be logic and how you approach it, how you use the language to achieve your goals.

At no point did I say that it doesn't make a difference if you use assembler/COBOL/C or prolog or ruby or php or whatever. What I said was that when run under the CLR the code produced by C# or VB.NET compilers when considering PERFORMANCE makes no difference.

So let me reiterate. When you target CLR it doesn't really make a difference if you choose C# or VB.NET. The only thing that matters is which language is better suited to do the task and most obviously which one you know.

and again, that is wrong. Performance is greatly impacted... not only that, a different compiler using the exact same CODE in the exact same language impacts performance.

A quick google for compiler benchmarks: http://www.willus.com/ccomp_benchmark.shtml
the results for different sample programs:
http://www.willus.com/ccomp_benchmark.shtml?p6
http://www.willus.com/ccomp_benchmark.shtml?p7
http://www.willus.com/ccomp_benchmark.shtml?p8
http://www.willus.com/ccomp_benchmark.shtml?p9
http://www.willus.com/ccomp_benchmark.shtml?p10

And all of them show MASSIVE differences between different compilers for the exact same code...

example, in the first example (C code program), normalized values for P4 performance (they used more then one P4 model to test it) is 1.01 for best compiler and 1.85 for worst. thats huge, nearly twice as fast. Also exe sizes vastly differ.
example, 3.6 GHz P4-Xeon 1MB L3... best runtime is 67.50 seconds, worst is 129.57 seconds.

[Kumppi]

ORIGINAL: taltamir

ORIGINAL: Kumppi

At no point did I say that it doesn't make a difference if you use assembler/COBOL/C or prolog or ruby or php or whatever. What I said was that when run under the CLR the code produced by C# or VB.NET compilers when considering PERFORMANCE makes no difference.

So let me reiterate. When you target CLR it doesn't really make a difference if you choose C# or VB.NET. The only thing that matters is which language is better suited to do the task and most obviously which one you know.

and again, that is wrong. Performance is greatly impacted... not only that, a different compiler using the exact same CODE in the exact same language impacts performance.

A quick google for compiler benchmarks: http://www.willus.com/ccomp_benchmark.shtml
the results for different sample programs:
http://www.willus.com/ccomp_benchmark.shtml?p6
http://www.willus.com/ccomp_benchmark.shtml?p7
http://www.willus.com/ccomp_benchmark.shtml?p8
http://www.willus.com/ccomp_benchmark.shtml?p9
http://www.willus.com/ccomp_benchmark.shtml?p10

And all of them show MASSIVE differences between different compilers for the exact same code...

example, in the first example (C code program), normalized values for P4 performance (they used more then one P4 model to test it) is 1.01 for best compiler and 1.85 for worst. thats huge, nearly twice as fast. Also exe sizes vastly differ.
example, 3.6 GHz P4-Xeon 1MB L3... best runtime is 67.50 seconds, worst is 129.57 seconds.

Oh boy. I am not talking about C/C++ code here, but code which is run UNDER CLR written in C# or VB.NET. I know very well that C or C++ code performance is impacted by the choice of compiler, but C/C++ code is not run UNDER CLR. VB.NET code vs. C# code compiled with VS 2005 is equal performance wise.

[taltamir]

Firstly, I would like to apologize, I am not familiar with VB.NET specifically and just went with a generic "all languages and compilers provide different performance results"... however I didn't realize how closely related VB.NET and C# are to each other, nor did I realize that you meant to compile both using the same related compiler (VS2005) and that the claim to identical performance was only for code in those 2 specific languages, while accepting that in general different languages have different performance metrics... This drastically alters the nature of the discussion.

that being said, "the same compiler" (VS2005) still has to use different code to compile different languages, and those are different languages (thus code will always be somewhat different), and they SHOULD still have differing performance despite their similarity, and sharing of compiler.

http://upload.wikimedia.org/wikipedia/c ... R_diag.svg
See the part where there is a C# compiler (which converts C# code to CIL) and a VB.NET compiler (which converts VB.NET code to CIL)? that is where the performance delta would be introduced, since they are bound to be different (perfection doesn't exist; and even if those were perfect compilers, the language differences come into play)

A quick google search found something interesting about that:

C# code might run slightly faster in a few circumstances; for example, the C# compilter generates code
that reclaims the memory used by objects more aggressively than under Visual Basic. However, most of the
time the difference in the performance won't be greater than 5 percent, so it's hardly an argument for
selecting one language over the other.

from Programming Microsoft Visual Basic.Net http://www.amazon.com/Programming-Micro ... 0735613753

quote taken from this discussion: http://www.vbforums.com/showthread.php?t=169894
which also indicates a performance delta between VB.NET and C#.

There is a decisive lack of performance benchmark comparisons of those two specific languages when using VS2005. I found a benchmark showing VB6 to outperform VB.NET by 81%, I found the benchmarks I posted in a previous thread, but aside from that one discussion (which DOES show a difference between VB.NET and C#) I am not finding all that much evidence either way.

What I am saying is:
1. different languages are known to produce different performance.
2. different compilers are known to produce different performance.
3. VS2005 still has to use a different compiler for VB.NET and C# code.
4. There is no reason or explanation why those two languages are an exception to said rule.
5. I actually found a benchmark supporting my claim.
6. I actually found that a book about programming in said language gives a technical reason for a performance delta between the two.

PS. If, for some reason, you had identical bytecode (CIL) produced by a VB.NET and a C# program, the fact that they share the CLR will indeed result in same native code and same performanc... however, the problem is in that IF... C# and VB.NET do NOT produce identical bytecode (CIL code) because they are different languages and use different compilers.

[Kumppi]

ORIGINAL: taltamir

that being said, "the same compiler" (VS2005) still has to use different code to compile different languages, and those are different languages (thus code will always be somewhat different), and they SHOULD still have differing performance despite their similarity, and sharing of compiler.

The consensus between C# and VB.NET is that the performance differences (usually more to do with the fact that the coder knows other language better) is so small that it doesn't make a difference. If you are writing software which must squeeze everything out of the system then you shouldn't use NET at all, but in many cases it's productivity that is the deciding factor and there NET shines.

[taltamir]

ORIGINAL: Kumppi

ORIGINAL: taltamir

that being said, "the same compiler" (VS2005) still has to use different code to compile different languages, and those are different languages (thus code will always be somewhat different), and they SHOULD still have differing performance despite their similarity, and sharing of compiler.

The consensus between C# and VB.NET is that the performance differences (usually more to do with the fact that the coder knows other language better) is so small that it doesn't make a difference. If you are writing software which must squeeze everything out of the system then you shouldn't use NET at all, but in many cases it's productivity that is the deciding factor and there NET shines.

fair enough, but that "so small as it doesn't matter" is supposedly 5% according the book I linked. And 5% performance difference is not "identical".

[Chet Guiles]

It's all Old High Klingon to me.

[JonBrave]

ORIGINAL: Chet Guiles

It's all Old High Klingon to me.

Oooo, no, no, no...! [:-] "Old High Klingdon" was a typeless language. Quite unsuitable nowadays. Much more likely to be Parallel Object-Oriented Vulcan+# [8D]

[impact]

5% can make a huge difference in game programming, where you want to squeeze everything out of your customer's computers you can get.
When I said that using VB.NET or C# wouldn't really make a difference, I was of course referring to the end result, but I assumed that this much was obvious.
That being said, the whole reason for making both languages work with the CLR is that Microsoft wanted something similar to Java (though only targeting MS platforms of course). Offering different programming languages in their VS package, they went ahead and tried to make them all work with the CLR.
The goal behind that was obvious: to make all .NET languages put out code for the CLR that wouldn't be different from each other performance-wise. So that VB programmers could now produce code running as fast as C# code.
Of course there are differences if you look at the IL code both languages put out and seeing as this approach by MS is rather "young" at this point, they still work on eliminating the performance gap, optimizing their IDEs for productivity and improving overall performance.
With VS 2010 and .NET 4 being out, I wonder if they managed to improve the performance. I haven't gotten around to reading a lot about it yet. But in my personal opinion (working with VS 2008) they have done one hell of a job so far.

[Kumppi]

5% can make a difference. Problem is that there is no 5% difference between VB.NET and C# code in VS 2005. With newer versions of Visual Studio possible performance differences between VB.NET and C# are even smaller.
I really can't comment much about the 5% difference except that the information was given in 2002. So it is pretty old.

Just a couple of pages about the differences between C# and VB.NET.

http://www.dnjonline.com/article.aspx?I ... vbvscsharp
http://stackoverflow.com/questions/1223 ... c-net-code