Miguel de Icaza Calls For More Mono, C# Games

Quote:

---

Originally Posted by ciplogic

And at the end you drag a lot of things either way: the OS libraries are in a lot of cases a lot of "baggage". Memory management, virtual memory allocation, dynamic library mapping.

---

An OS is a baggage only if your application targets an OS-less system, this is pretty rare today. You can often make away with dynamic libraries with a clever build system. Memory management can be replaced with a custom malloc/free on a static set of memory if you choose the C-route. If you drag in the.NET baggage, all these options are off. The fact is that .NET is mostly an unnecessary baggage that only brings restrictions to the table. All languages in there are restricted to the CLR and managed mode which unifies them to a point in which syntax is their only differentiator.

If you take a practical look at the systems out there almost all of them brings a C interface and a C standard library. For portability this is the obvious way to go. This buys you to be able to use new instruction-sets etc when new types of hardware arrives. Of course C will not take you all the way since the abstractions will not automatically be optimized for different types of HW (multiple cores, vector instructions, SPE:s etc). Here you need help out with higher order programs that can generate optimal solutions or find some other clever way like compile-time optimizations (see for instance ATLAS).

Additional runtime environments will eventually just be an additional burden when it comes to portability and restrictions. You should really choose them wisely, and typechecking of enums isn't even on the map to drag in Microsofts second citizen (the .NET environment).

Quote:

---

Originally Posted by ciplogic

but practice shows that the C++ headers of OpenGL are not that "competent"

---

The GL-problem, as I said, is easily solved with additional syntax checking tools/scripts and you will get both the type-check for each GL function and the leaner and nicer syntax given by C/C++ (compared to C#). If static type-checking of the compiler is your main priority, you should probably go for ADA or similar.

Quote:

---

Originally Posted by ciplogic

far as I used there are just two visual designers in C++ world that would match a decent usage

---

Are visual designers really a good way to do good UI:s? I'm provoking here, but the best UI:s I seen rarely come from visual tools. Compare for instance the output from LaTeX vs a manually written Word document. You can't be creative enough with visual tools and often both you and the tool get restricted by the tools. If you instead focus on the problem and the logic you can often dynamically create a better GUI, and you have a program where the GUI structure are not setting any restrictions.

Quote:

---

Originally Posted by ciplogic

At the end, people lived before OOP

---

Yes, and OOP is a way of design and could be done in most languages without the syntactic sugar in the "OOP languages". Likewise with "Abstract programming", "functional programming", etc. If you aim for syntax, look for instance at how Vala abstracts all C-calls to the gobject system and still doesn't require any other runtime overhead than what their C library interface does (compile-time syntax sugar).

Quote:

---

Originally Posted by ciplogic

concepts (in C# I am used to write Generics + constraints, are really great to use), full RTTI, (maybe) a GC, dynamic dispatch.

---

I do not see any feature here that motivates a VM and the .NET API. You may initially have to go an extra mile in design but that is reusable and completely worth it.

Quote:

---

Originally Posted by ciplogic

I used Ruby and if it would be a 20-30% slower than .Net, I would use it straight away (there is, and I plan to use it, is name Mirah, but I have sometimes quirks compiling it). If is to compare a better language, Ruby would be likely be it, maybe Python.

---

I think this is an excellent choise. An interpreted high level language for quick prototyping / scripting / etc and then a portable lower level language for performance. .NET is an environment that isn't particularly good in either of these directions. You can also use these high level languages to auto-generate low-level code in C for instance and you will both have customized high abstractions and performance.

Quote:

---

Originally Posted by Togga

An OS is a baggage only if your application targets an OS-less system, this is pretty rare today. You can often make away with dynamic libraries with a clever build system. Memory management can be replaced with a custom malloc/free on a static set of memory if you choose the C-route. If you drag in the.NET baggage, all these options are off. The fact is that .NET is mostly an unnecessary baggage that only brings restrictions to the table. All languages in there are restricted to the CLR and managed mode which unifies them to a point in which syntax is their only differentiator.
(...)
Additional runtime environments will eventually just be an additional burden when it comes to portability and restrictions. You should really choose them wisely, and typechecking of enums isn't even on the map to drag in Microsofts second citizen (the .NET environment).

---

You say that C# (I think you refer to it) it brings only restrictions to the table. In fact every compiler/platform brings restrictions. For example, there is no C++ GEM (Ruby world "libraries in a package manager) support, and .Net (Visual Studio basically) have something primitive (NuGet). Unnecessary, did you mean about RTTI (oreflection!?). Syntax is not only diferentiator as far as I know: F# is fairly different from C# (even both end with #), and all are different with Boo. In fact there are instructions in MSIL (for example "Tail" which will make a tail call, that you cannot call in C#, even 4.0, but is specially used for functional languages). I can agree that C# got some of the features out of every language by a little (Linq a bit of functional programming, Generics a bit of meta-programming, dynamic a bit of dynamic dispatch, and so on), and Visual Basic was gotten convergent, but even with this, combining it with frameworks (like WPF, WCF, etc.) make a way to talk in real world, that are much more different than just a syntax sugar over MSIL (I mean BAML / Xaml world). Of course any of those decisions have choices, some are good some are bad, but overall, inside the .Net package you have a lot to get. Or in Java, or in Python. The idea of "batteries included" is maybe what you think that strikes you. I mean, what bothers you? The idea that .Net is too big? The lowest cost "laptop" I find in Spain with Windows, have a Windows that includes .Net 4 (http://www.pccomponentes.com/asus_ee...0gb_10_1_.html ) and it has bundled a 320 GB disk. Windows' disk usage, around 10 GB. And you compare a 40 MB package download, that the code include by default a lot of code that other components, like Paint.Net, would not have to download. So Paint.Net download package is just some MB (low number).
At the end, I think that in a part, you are right: additional runtime environments bring restrictions. So you may use Cygwin and as cygwin provides Mono, you can target all Unixes with Mono programs. If you mean that C++ applications have any benefit to portability, compared to Mono, I'm curious of your platform to develop in, is it Qt? (which in itself is a platform, and as I worked professionaly with it, I can say that in some configurations is buggier than GTK+, in special with non-standard window-managers)

Quote:

---

The GL-problem, as I said, is easily solved with additional syntax checking tools/scripts and you will get both the type-check for each GL function and the leaner and nicer syntax given by C/C++ (compared to C#). If static type-checking of the compiler is your main priority, you should probably go for ADA or similar.
(...)

---

If static type checking it can be done just with a plugin. Don't you want this, and want a supported compiler-integrated checking? You can check Code-Contracts. As OpenTK is the de-facto wrapper for OpenGL, and gl/GL.h is the de-factor for C++, what you state is still a talk which is not yet proven.

Quote:

---

Are visual designers really a good way to do good UI:s? I'm provoking here, but the best UI:s I seen rarely come from visual tools. Compare for instance the output from LaTeX vs a manually written Word document. You can't be creative enough with visual tools and often both you and the tool get restricted by the tools. If you instead focus on the problem and the logic you can often dynamically create a better GUI, and you have a program where the GUI structure are not setting any restrictions.

---

Yes, a lot of them are generated and are good ones. Are not optimized, if you mean the "best UI" means that they will not set twice a property. Delphi/Lazarus was one of the first one that was using generated out-of-a-database (TiOPF framework) UI. It may not be optimum, it can make two extra queries, but it is functional. If you want a good looking UI, I recommend to you either Flash (I'm not a fan of it, but I had seen things made incredible out of it), that it gets out of Photoshop or WPF. WPF supports theming, accelerated controls, a lot of things that are well made (like data binding, which is really hard to achieve without a dynamic language and good RTTI, Qt have something similar, did you tried the QML - a JavaScript interpreter on top of MOC classes).
Restrictions in UI are mostly the norm, you don't want to break anything, that's why you would prefer a Visual Form Inheritance to work by default! Most UIs like OS X are restricted by code guidelines, that users care to have what they expect, not how imaginative is the designer.

Quote:

---

Yes, and OOP is a way of design and could be done in most languages without the syntactic sugar in the "OOP languages". Likewise with "Abstract programming", "functional programming", etc. If you aim for syntax, look for instance at how Vala abstracts all C-calls to the gobject system and still doesn't require any other runtime overhead than what their C library interface does (compile-time syntax sugar).
I do not see any feature here that motivates a VM and the .NET API. You may initially have to go an extra mile in design but that is reusable and completely worth it.
I think this is an excellent choise. An interpreted high level language for quick prototyping / scripting / etc and then a portable lower level language for performance. .NET is an environment that isn't particularly good in either of these directions. You can also use these high level languages to auto-generate low-level code in C for instance and you will both have customized high abstractions and performance.

---

Did you ever looked the generated Vala code? Is mapping 1:1 to C? Or by runtime overhead, you mean, nothing else than GObject? And it is a bit buggy on Windows!? Or that it doesn't have annotations in the C# sense? And it doesn't have dynamic keyword, or PLinq.
"I don't see any feature"... is fine. It still makes the point true: the abstractions pay a price a lot of times. Sometimes small, sometimes by making a language specification and understanding really huge (like C++). I mean, using a smart-phone forced us to think phones with "gestures", "post-PC era", and so on, which is really far far away from the phone that was barely digital (in the past I catched my grandma using a wheel to call to the numbers).
And I do think that even by any standard, the basic phone is still good enough for many usages, and a smartphone can be sometimes too complex to grasp how to "install application from Marketplace". They make no sense in many ways, at least for basics. But when you get used, you simply cannot look back.
Should we write only binary, as INI files or XML files are too slow to parse and are abstractions? Certainly the binary files are faster. Should we write for saving data our back-store database and not using a database? Imagine, most databases use Inter-Process communications, and the ones that don't are somewhat slow, even the performant ones, use a query engine that sometimes is using a JIT (I'm saying about Oracle query planner that uses a Java VM to optimize and generate dynamically the query conditions, using HotSpot Server).
At the end, should we all use Windows 95/NT 4.0 !? It is small (I remember that Win95 was like 40 MB on disk, Win 95 OSR 2 like 120M, NT 4 was like 100+ M), it should start instantly on today's hardware, had 64 bit support (only NT), no multiple runtimes to support, so no headaches. It did not had a (functional) browser control so no hassles with incomatible HTML. In fact we would not need ClearType, 3D Aero, and a 512 MB OS usage, when all those 3 OSes would work just fine with just 32 MB, and 64 MB would be the high end machines of their times.

Quote:

---

Originally Posted by Togga

I think this is an excellent choise. An interpreted high level language for quick prototyping / scripting / etc and then a portable lower level language for performance. .NET is an environment that isn't particularly good in either of these directions. You can also use these high level languages to auto-generate low-level code in C for instance and you will both have customized high abstractions and performance.

---

If you agree that Ruby/Python are great in interpreter for prototyping, I can say that .Net fits the deal really great here:
- Boo is an interpreted language if you use it with booi (and will get the "batteries" = a lot of utility libraries of .Net/Mono). It is Python inspired, have dynamic dyspatch. When you get to a form that you think you're happy, all you have to do is to disable the dynamic dispatch feature, and you get a boost of performance where the dyn-dispatch was running. Didn't you get enoug performance? Recompile the code with booc.exe.
Still slow (like on startup): try to compile it ahead of time, or use Mono --llvm?
- Still slow? Use C++ and call the code with P/Invoke for that critical loop (even you rarely fit the case to do it)
You can use C# in this way too, and also you have an interpreter mode, so you may feel a bit of lag when you develop rarely (like 0.2-0.3 seconds to compile small/big functions, if you call a lot of code) as sometimes it does JIT as we go. (like here)
In fact C# permits all at once: static compilation (like C++), JIT-ting, interpreting in REPL style where your code is interpreted but the typical code is JIT-ted so as you are likely to stay in a small patch of code, the exceptions and bit JIT times will not pop-up all the time.
I benchmarked once, as a response that even some myths (i.e. slow startup of non-compiled languages) like shown here. (Mono apps MonoDevelop + Banshee in 20 seconds, C++ QtCreator+AmaroK ones in 25 seconds)
May you give a circumstance where Mono or .Net it was too slow? May you give a piece code that runs so slow, that Mono doesn't worth considering?

Quote:

---

Originally Posted by BlackStar

Hey, an actual language discussion without a flamewar! Who would expect that on Phoronix?

---

Heh this thread just keeps on trucking it seems, and yes you are right it's been uncommonly civil here which is a very nice surprise :)

Quote:

---

Originally Posted by BlackStar

Haven't tried Go yet, but I've read its samples and I wasn't too impressed (like I was with Ocaml and its F# offspring, for instance). What is its "killer" feature that would convert people?

---

Well, as I said I've just looked over the language as of yet and made some short snippets to get a feel of it so I'm really not qualified to make that judgement, but for me personally the big reason I found the language interesting was that it had built-in concurrency properties (goroutines, channels).

Quote:

---

Originally Posted by BlackStar

The compiler will happily accept both versions and the error will go unnoticed unless you call glGetError() - which most people don't do, since it kills performance.

---

Well you could put the glGetError() call in a macro which is expanded into testing/logging the error or not based on a defined constant and thus could be disabled for production builds where you'd not want the performance loss.

Quote:

---

Originally Posted by ciplogic

- Boo is an interpreted language if you use it with booi (and will get the "batteries" = a lot of utility libraries of .Net/Mono).

---

Well, this is not an option for all reasons named in previous posts. If I want performance, I certaintly not choosing .NET. If I want existing Python code to go faster, i'd use PyPy or compile to native through it's LLVM backend. Both are better than dragging in a VM with a in practice non portable framework. As I said before, when I want performance, i'll go directly native with full control of the situation. I've yet not failed to get the batteries I need in C/C++.

Quote:

---

Originally Posted by ciplogic

It is Python inspired

---

Python inspired does not give all batteries Python have (like scipy/numpy). Going from one virtual machine to another doesn't add any value. Python is not my choise for performance.

Quote:

---

Originally Posted by ciplogic

May you give a circumstance where Mono or .Net it was too slow? May you give a piece code that runs so slow, that Mono doesn't worth considering?

---

Mono (and .NET) is just an unnecessary baggage which don't bring me anything of value. If I would target client applications on the web (possible valid cause for a VM), Java/javascript is the king out there and html5 is the future.

Syntactic sugar doesn't solve any real world problems.

Quote:

---

Originally Posted by ciplogic

You say that C# (I think you refer to it) it brings only restrictions to the table.

---

No, I mean .NET and the CLR, MSIL and all restrictions they impose on you along with the baggage you have to drag with you which platform you choose to target.

Quote:

---

Originally Posted by ciplogic

In fact there are instructions in MSIL (for example "Tail" which will make a tail call, that you cannot call in C#, even 4.0, but is specially used for functional languages).

---

Here you mention one of them, the restriction to MSIL. Going native, you don't have any such restrictions and could go creative all the way down to the core.

Quote:

---

Originally Posted by ciplogic

In fact every compiler/platform brings restrictions.

---

Sure. You only have to watch out for what gives you the least restrictions and/or the most possibilities. .NET for instance is itself not written in .NET.

Quote:

---

Originally Posted by ciplogic

what bothers you? The idea that .Net is too big?

---

It just don't add any value to me, just restrictions and unnecessary baggage. Bringing in a VM should be a separate architectural decision for a product not depending on "nice syntax" etc.

Quote:

---

Originally Posted by ciplogic

If you mean that C++ applications have any benefit to portability, compared to Mono, I'm curious of your platform to develop in, is it Qt?

---

QT is a really good framework even though I think that a pure C API is cleaner and that they put a little too much features under their umbrella. If you separate logic from UI well enough the UI could be anything from a script to a web-page or even automatically generated using any framework as a backend.

Quote:

---

Originally Posted by ciplogic

Yes, a lot of them are generated and are good ones. Are not optimized, if you mean the "best UI" means that they will not set twice a property.

---

I mean "UI" from a user perspective.

Quote:

---

Originally Posted by ciplogic

Did you ever looked the generated Vala code? Is mapping 1:1 to C? Or by runtime overhead, you mean, nothing else than GObject? And it is a bit buggy on Windows!? Or that it doesn't have annotations in the C# sense? And it doesn't have dynamic keyword, or PLinq.

---

Yes. As with .NET, it will not be more stable than the underlying libraries that is putting restrictions on the system. My point was that this language is not having the overhead of a virtual machine to get all features and works, wherever C works. There is a big difference getting gobject library to compile on a new platform than bring over .NET there.

I don't have much Vala-coding experience myself but I have good experience with some applications written in Vala in terms of performance and resource consumption. See for instance Shotwell : http://yorba.org/shotwell/

Quote:

---

Originally Posted by ciplogic

Should we write only binary ...
Should we write for saving data our back-store database and not using a database? ...

---

I'd say be creative and go with sound experience. If in doubt, go the route with the least restrictions (lets you move in either way), make smart simple designs (not inventing problems that aren't there) and library choises.

Quote:

---

Originally Posted by XorEaxEax

Well, as I said I've just looked over the language as of yet and made some short snippets to get a feel of it so I'm really not qualified to make that judgement, but for me personally the big reason I found the language interesting was that it had built-in concurrency properties (goroutines, channels).

---

Well, I've been toying around with Go these past few days and it has morphed into a pretty interesting little language.

The lack of object hierarchies and implicit interface implementations are surprisingly nice features! I've long campaigned in favor of implicit interfaces (if my object implements Foo() I should be able to pass it to a method accepting IFoo) and the rationale in Go makes lots of sense (more modular code). Object composition is much better aligned with game code than deep object hierarchies, so that's a big win too.

The only downside is that there's no MSIL compiler yet, so I can't easily combine it with my existing codebase (~1MLoC).

Quote:

---

Originally Posted by Togga

Yes. As with .NET, it will not be more stable than the underlying libraries that is putting restrictions on the system. My point was that this language is not having the overhead of a virtual machine to get all features and works, wherever C works. There is a big difference getting gobject library to compile on a new platform than bring over .NET there.

---

Not necessarily. You seem to be confusing the .Net BCL with the .Net VM. They are completely separate things. The .Net VM itself is written in C++, is self-contained and is quite portable - there are people who have ported it to the PSP, to Maemo and half a dozen other exotic platforms. The BCL, on the other hand, is huge. The core parts are written in C# and are portable, with some work, but other parts (like System.Windows) are inherently non-portable.

Fortunately, you need very few things to write games: System, System.Core, System.Net and System.Xml, more or less. Add an OpenGL and an OpenAL binding and you have everything you need, in a tiny, portable package (~4MB compressed).

It's not as if C++ doesn't have the same problem: by the time you add pthreads, tinyxml, sdl, a network library and a scripting library, you've reached the exact same overhead. This is stuff you need, one way or another - no matter the language.

Unfortunately, most people think that writing a .Net game requires the installation of a huge VM with hundreds of megs of stuff. That's simply not true: 4MB is all you need.

Quote:

---

I don't have much Vala-coding experience myself but I have good experience with some applications written in Vala in terms of performance and resource consumption. See for instance Shotwell : http://yorba.org/shotwell/

---

Vala is pretty nice. It's C# for people who want to use C# without the whole .Net package. This actually proves how nice a language C# really is, even if you don't like .Net itself.

Quote:

---

Originally Posted by XorEaxEax

Well you could put the glGetError() call in a macro which is expanded into testing/logging the error or not based on a defined constant and thus could be disabled for production builds where you'd not want the performance loss.

---

That's still runtime checking, not compiler checking. If I pass the wrong parameter to a function, I want to rely on the compiler to stop me. Waiting for some poor tester to report a random texture corruption bug a few days later is just not the same.

Quote:

---

Originally Posted by Togga

Mono (and .NET) is just an unnecessary baggage which don't bring me anything of value. If I would target client applications on the web (possible valid cause for a VM), Java/javascript is the king out there and html5 is the future.
Syntactic sugar doesn't solve any real world problems.

---

You're right (on syntax sugar). I do think that doesn't bring to you anything of value. The people that defend C#/Miguel/whatever are somewhat tired of the myths that grow big for emotional reasons (like: is Microsoft Project, or other matters like that). We don't hold sacred either C# or the its VM designs. In many instances we would use C/C++. If we need to make an application that makes an updater, is easier to take already made WebClient class, combine with Windows Forms framework and ask the user: a new update is available, do you want to download it? And on a separate thread to do the downloading of the upgrade. If you target original Windows XP or upper, .Net is already installed, and an application like it, would be like few KB of extra functionality. To do it in C++ would make it really harder. How would you download a file from internet to disk, if you know the URL? (I honestly don't know, call wget!? )
If you say about JS and its powers, I think that we also agree, that is the most desirable experience. In fact JS/Html5 is one of the examples that is mature yet is not so consistent as performance and support, as is Mono fares much better for that matter when compared with .Net. If you target a game, should it use CSS that is accelerated by IE9, or should you use WebGL? Should you use a computational kernel in JS to make a real-time game? Here is where JS still suffers (compared with Mono, the Firefox GC implementation does not have a too fast but soon it will GC, even being said that, it gets better and better).
JS is part of QML, which is an extra baggage too, yet it does it well enough to work with Symbian Nokia phones to desktop applications.
At the end: syntax sugar is just about abstractions. When using smart pointers, the boost::smart_ptr (if I recall it right), does increment/decrement references so the user will not miss the count. For skilled programmers, may appear to not be necessary, but when you work with multiple frameworks, is really hard to track all the references all around the application. Also many syntax sugars do solve some real world problems: Generics/templates enforce some typical mistakes that do user face. A for loop (a C one) sometimes is reverted by compiler, and some subexpressions are removed out of the loop (google for Loop invariant code motion), and the loop itself may be repeated many times to make easier auto-vectorizations and improve the branch prediction of a specific CPU. Some abstractions we are comfortable with (virtual ... = 0; code which some methods can be virtual and abstract like: virtual void Drive() = 0 { TurnWheel(); } ), or multiple inheritance, when other languages do not accept this. Which is better?
As for me is hard to choose, but anyone thinks different about what is better, so is hard to judge from outset of your particular skills that is great.
The last thing: "tail" MSIL instruction was just a power of the CLR, that made no sense for C++ world for that matter, or C# world (maybe a bit for Linq, but this is other matter), as is a functional language feature. Tail works just like "register" keyword in C, that would hint for compiler to try to put a variable into register.

Quote:

---

Originally Posted by BlackStar

Waiting for some poor tester to report a random texture corruption bug a few days later is just not the same.

---

Not really following this, you can create a macro which reports any glError codes during runtime together with which source file and line number the error took place on. You can also make it so that the checking can be disabled and thus not have any performance impact on final builds. Something like this:

Code:

---

#ifndef _GLERROR_H_
#define _GLERROR_H_

#include <stdio.h>
#include <GL/gl.h>

#define _GLERROR_ENABLED_ // comment out to disable glGetError() checking

#ifdef _GLERROR_ENABLED_
#define GLERROR() { int foo = glGetError(); if(foo != GL_NO_ERROR) printf("GLError:%d in file:%s at line:%d",foo,__FILE__,__LINE__); }
#else
#define GLERROR()
#endif

#endif

---

This would catch faulty parameters during runtime, giving you the file and line in which they occured and not force you to wait for some tester to report some texture bug. Granted it's nicer if the compiler catches the error but it's not something I would switch language for.

Quote:

---

Originally Posted by XorEaxEax

Not really following this, you can create a macro which reports any glError codes during runtime together with which source file and line number the error took place on. You can also make it so that the checking can be disabled and thus not have any performance impact on final builds. Something like this:

Code:

---

#ifndef _GLERROR_H_
#define _GLERROR_H_

#include <stdio.h>
#include <GL/gl.h>

#define _GLERROR_ENABLED_ // comment out to disable glGetError() checking

#ifdef _GLERROR_ENABLED_
#define GLERROR() { int foo = glGetError(); if(foo != GL_NO_ERROR) printf("GLError:%d in file:%s at line:%d",foo,__FILE__,__LINE__); }
#else
#define GLERROR()
#endif

#endif

---

This would catch faulty parameters during runtime, giving you the file and line in which they occured and not force you to wait for some tester to report some texture bug. Granted it's nicer if the compiler catches the error but it's not something I would switch language for.

---

(a) This relies on the programmer to insert GLERROR() calls at proper places.
(b) This only detects errors at runtime, even though they could be detected by the compiler.

These issues might not matter for trivial applications. But what if you are developing a non-trivial game and the faulty code is only executed near the end of level 5, when the player tries to enter a non-essential secret area? It might be weeks before a tester encounters and reports the issue!

Bugs like this do happen and do go unnoticed (ever played any of the Elder Scrolls series?) The larger the application, the higher the chance of obscure bugs, and the higher the value of compile-time error checking. This is precisely the reason we have moved from assembly to C, to C++ and to other things.

Btw, C#/OpenTK not only detects errors at compile-time, it also inserts GL.GetError() calls automatically when running in debug mode. This is a huge safety net that you can't really appreciate before you use actually use it. OpenGL is much smoother in C# than in any other language I've ever used.

Quote:

---

Originally Posted by BlackStar

Not necessarily. You seem to be confusing the .Net BCL with the .Net VM.

---

No. I'm not confused by this. I know I have to port everything I use including the VM and all libraries which might be a subset of .NET. The VM overhead to begin with is just not justifiable for some syntax sugar that I can get anyway if needed. .NET platform itself does not have any valuable thing to offer here, may it be 2Mb or 20Mb. Besides this, we already seen that C# is more verbose than necessary for GL calls. Here syntax doesn't even appear to be it's strong side. It's then a lose-lose situation.

Quote:

---

Originally Posted by Togga

No. I'm not confused by this. I know I have to port everything I use including the VM and all libraries which might be a subset of .NET. The VM overhead to begin with is just not justifiable for some syntax sugar that I can get anyway if needed. .NET platform itself does not have any valuable thing to offer here, may it be 2Mb or 20Mb. Besides this, we already seen that C# is more verbose than necessary for GL calls. Here syntax doesn't even appear to be it's strong side. It's then a lose-lose situation.

---

The using OS overhead to draw things is not justifiable. Find an OS to not occupy today at least 100 MB of RAM and 1.5 G of hard (this is XP) or 400 MB of RAM and 10 G of HDD (Vista/7).
Verbosity as looking for safety, you just pawned yourself by showing that enums are more verbose to solve the very some problem.
If you mean verbosity in typcal code: C++ you have to declare a lot of things twice, and even an empty class is longer in C++:
class Class {} //C# code
class Class {}; //C++
If you mean that using is longer that #include, seems not to be the case, if my counting helps.
If you mean to use type inference from C++11, auto is longer than var.
So where is shorter? class A {public: void test(); } ; void A::test() { } is longer for me than: class A { public void test() { } }

Maybe some STL would save us:

Code:

---

int myints[] = {32,71,12,45,26,80,53,33};
  vector<int> myvector (myints, myints+8);              // 32 71 12 45 26 80 53 33
  vector<int>::iterator it;

  sort (myvector.begin(), myvector.end());          //(12 32 45 71)26 80 53 33

---

Comparing with what C# offers:

Code:

---

        var myints = {32,71,12,45,26,80,53,33};
//default (using generics):
Array.Sort( myints );
//Linq
        // Query for ascending sort.
        var sortAscendingQuery =
            from item in myints orderby item select item;

---

And to not forget, because you have a GC, you don't have to write destructors in most cases, isn't so? Don't you enjoy to write them?

At the end you appear to not be consistent with your values, because you seem to appear to accept to use an inneficient hard disk data format (like using ini files or Xml), that would give to you many times slowdowns, than to use something that brings 50% of assembly speed. And if you do programming for real, maybe you would notice that disk operations are orders of magnitude slower than ever Mono could be. Mono may be two times slower, it may use some MB. How many? Not so many...

A Hello world in Mono? Some KB, under 10. A hello world in C++, give to me your numbers. Count them in many applications, and you will think twice on saved space... seems you are so concious to save disk space: start with C++, is a great place to start shed off

"I have to port everything I use including the VM and all libraries which might be a subset of .NET" Really? Do you have to port the VM?
It sounds like you are porting the compiler every time you change the computer. I pitty you for bad life you have... but most people work with mainstream compilers and platforms :)
I warmly recommend Mono/.Net
Even if you use Ubuntu/Suse/Windows XP/Vista/7 you will have support for a big set to work at least with files, console and web to make tools. You don't need to recompile a thing, is all done by Microsoft and Xamarin engineers and other contributors.

Ciplogic, why are you even replying to Togga? It's obvious he's trolling, and badly at that, too.

Here is something interesting that caught my eye today:

Quote:

---

Originally Posted by https://code.launchpad.net/~vanvugt/compiz-core/fix-940139/+merge/94715/comments/204303

The performance implication is huge. Compiz was spending most of its time in malloc/free, which was mostly due to "new PrivateRegion" and "delete PrivateRegion". So PrivateRegion had to go. Although after this fix most of compiz' CPU usage is still due to excessive malloc/free/new/deletes, at least it's no longer mostly due to CompRegion.

---

This goes to show that code with inefficient memory management will perform slow in any language. Not only that, but the relevant optimizations are pretty much identical in all languages: remove memory allocations from the fast path.

Quote:

---

Originally Posted by BlackStar

(a) This relies on the programmer to insert GLERROR() calls at proper places.
(b) This only detects errors at runtime, even though they could be detected by the compiler.

---

Yes, I wasn't arguing against that, this was directed at your statement of people not using glGetError() due to performance loss, I just wanted to show that with a macro you easily enable/disable this check and thus easily avoid the performance impact when you know the code is functional.

Quote:

---

Originally Posted by BlackStar

These issues might not matter for trivial applications. But what if you are developing a non-trivial game and the faulty code is only executed near the end of level 5, when the player tries to enter a non-essential secret area? It might be weeks before a tester encounters and reports the issue!

---

Well I can't say I've done much game programming (and even less opengl programming), in fact it was many years since I did anything remotely as such, that said I can't imagine a game where you'd write special opengl code for a secret area. As I see it you write an engine which handles all drawing, and that engine is thoroughly tested during development, a secret area just like any other part of the game is defined using tools (map editor, event editor, etc) which in turn access the drawing engine using a higher level interface and not by anyone hacking together specific opengl code for that part of the game.

Quote:

---

Originally Posted by BlackStar

This goes to show that code with inefficient memory management will perform slow in any language. Not only that, but the relevant optimizations are pretty much identical in all languages: remove memory allocations from the fast path.

---

Which proves nothing other than that you can write slow code in any language, it's how fast you can get your code which is of interest. Well written native code beats well written managed code in speed/resource usage, there's really no point in arguing this.

In areas where performance is very important managed code is indeed absent (compression, encoding, rendering, etc) due to it's performance penalities. Obviously this is not news to anyone who understands the difference between managed and unmanaged code, if managed code had it's advantages without the corresponding performance/resource usage penalty then we'd all be using managed code for everything these days. However these performance issues are real and computing power is not infinite. For a large array of problems the performance penalty makes no difference and here C#, Java, together with lots of scripting languages are popular solutions, like in the enterprise sector where once VB reigned supreme.

Personally I enjoy both sides of the spectrum, I like the ease/speed of development in languages such as Python and I also like the low level power and flexibility of languages such as C/C++, and in particular I like how I can combine them.

Quote:

---

In areas where performance is very important managed code is indeed absent (compression, encoding, rendering, etc) due to it's performance penalities.

---

You are correct here, managed code is indeed absent in compression and encoding. However, the story is a little more complex. Code like:

Code:

---

a = b + c;

---

or

Code:

---

foreach (var a in items)
    // do something

for (std::vector<foo>::const_iterator it = items.begin(); it != items.end(); it++)
    // do something

---

perform identically between C# and C++. There's no inherent disadvantage in a statically-typed managed language vs a statically-typed unmanaged language.

So why don't you see an h.264 compressor in C#? Two reasons:
(a) compressors and encoders tend to be released as reusable libraries, which means C (because the C is the only globally-understood ABI. C# and Python can both use C - but not vice versa.)
(b) SIMD optimizations.

While something like:

Code:

---

a = b + c

---

may perform identically between C# and C++, it can often be made 4x faster via 128bit vector instructions. Which is why you will often see hand-rolled assembly in the core of such libraries, rather than C++.

In other words, the distinction here is not actually managed vs unmanaged, it is high-level vs low-level. The lower the level, the more micro-optimizations you can make - and these are what make the difference in tasks such as compression and encoding.

Edit:

Quote:

---

Well I can't say I've done much game programming (and even less opengl programming), in fact it was many years since I did anything remotely as such, that said I can't imagine a game where you'd write special opengl code for a secret area. As I see it you write an engine which handles all drawing, and that engine is thoroughly tested during development, a secret area just like any other part of the game is defined using tools (map editor, event editor, etc) which in turn access the drawing engine using a higher level interface and not by anyone hacking together specific opengl code for that part of the game.

---

Pretty much. However, it could be that a specific combination of (invalid) OpenGL states only appears at a specific location in the game. Or it could be that that area contains an asset with a problematic shader. It happens, and my point was that the more you trust your compiler the better.

In fact, that's why the WebGL spec goes to such lengths to allow static verification of the code. It throws away pretty much all OpenGL ES parts that are not statically verifiable - and Google has built a WebGL compiler that checks your code and refuses to execute it when it detects anything unverifiable. (I'm pretty sure Mozilla is using the same compiler, at least on Windows). This is pretty much impossible in desktop OpenGL, where the default headers are full of untyped enums (ints) and void* casts. (Even the "hardened" headers I am using have issues due to the schizophrenic OpenGL design - but that's another discussion entirely.)

Quote:

---

Originally Posted by BlackStar

You are correct here, managed code is indeed absent in compression and encoding. However, the story is a little more complex. Code like:

Code:

---

a = b + c;

---

or

Code:

---

foreach (var a in items)
    // do something

for (std::vector<foo>::const_iterator it = items.begin(); it != items.end(); it++)
    // do something

---

perform identically between C# and C++. There's no inherent disadvantage in a statically-typed managed language vs a statically-typed unmanaged language.

---

And in fact sometimes it performs even better.
Note: thanks for notice me about Togga :) Regards and have great programming time.

Quote:

---

Originally Posted by XorEaxEax

In areas where performance is very important managed code is indeed absent (compression, encoding, rendering, etc) due to it's performance penalities.

---

In fact I want to fix just one topic: encoding and rendering (even rendering may work on Java runtime as SunFlow) are really CPU dependent, yet compression/decompression is a different matter.
Compression is written dependent by multiple dependent performance parts, like IO (most of the times), a branchy code (which depends on CPU branch predictions), it has multiple variables (so it depends on register pressure), and CPU cache saturation, and most of the times is hard to parallel them. If you take DotNetZip (http://dotnetzip.codeplex.com/) and you use compare to compress a big archive (I tried a Fedora ISO under Windows), you may be surprised that the compression runs faster from Mono (on 32 bits) than a Total Commander (32 bits). This it may be just because Total Commander uses Delphi which is known to not be *that* efficient on generating code. Also as JITs do most lilkely compile a smaller portion than all code paths do, they would likely fit better in CPU cache, so maybe just a combination of cache misses + a bit better code generator may make JIT code faster than a native compiler.
The difference is even bigger with using the same DotNetZip if you use the default settings. As most applications are compiled with 32 bits (as they need to run on most Windowses) when in .Net if you know that you don't interact with 32/64 bit world, you will get a 64 bit version where you have more registers to spare, so you will get even faster generated code.
In fact most Java tools work with JAR (which are decorated Zip files) which may work faster than the full access of the .class files as CPUs compensate the lower speed on rotating or normal disk. So they may be even faster than plain files or the impact is too little the SSD drives (like described here).

Quote:

---

Originally Posted by BlackStar

Ciplogic, why are you even replying to Togga? It's obvious he's trolling, and badly at that, too.

---

Defenitely not. But it's easier to just call people trolls than try to understand what they say...

Quote:

---

Originally Posted by ciplogic

The using OS overhead to draw things is not justifiable. Find an OS to not occupy today at least 100 MB of RAM and 1.5 G of hard (this is XP) or 400 MB of RAM and 10 G of HDD (Vista/7).

---

Well, there are always busybox/<some-embedded-os> combos out there. Pretty much all component choises means restrictions in some way. I think C gives me the least restrictions, everything outside that I choose carefully unless I just want to experiment, have limited scope, something to test or educate.

Quote:

---

Originally Posted by ciplogic

If you mean that using is longer that #include, seems not to be the case, if my counting helps.

---

Your correct. But my point with syntactic sugar is that I rather add a few bytes extra code than use unnecessary dependencies for production software.

Quote:

---

Originally Posted by ciplogic

And to not forget, because you have a GC, you don't have to write destructors in most cases, isn't so? Don't you enjoy to write them?

---

If needed, to use GC in C++ you can always do something like

Code:

---

gc_ptr<Class *> ptr = new Class();

---

You can in fact implement any memory layout this way and do not have to give up (the syntactic sugar for) multiple inheritance in the process (which is a big loss for a language that should be object oriented). The same thing can be achieved in pure C.

Quote:

---

Originally Posted by ciplogic

At the end you appear to not be consistent with your values

---

I am consistent with my values, which is to be as flexible as possible. Maybe I use a hard drive today, but I can easily move my code to a pure RAM-based solution, etc. To use Mono for a few lines of code and some syntactic sugar is not even on the table (unless it's for fun or something other outside the professional sphere). As I mentioned earlier, there are plenty of other options if you want neat syntax, but even that is not main priority for me.

Quote:

---

Originally Posted by ciplogic

A Hello world in Mono? Some KB, under 10. A hello world in C++, give to me your numbers. Count them in many applications, and you will think twice on saved space... seems you are so concious to save disk space: start with C++, is a great place to start shed off

---

Again, you're missing my point. If disk-space are tight, we're probably in an embedded device. Lets say we have an RTOS with a C-library. What consumes more space, a hello world in C or a hello world requiring the Mono stack to go along?

For me Mono and .NET really have nothing to offer. Couldn't you prove me wrong with something other than to save a few characters of code? Nobody gets happier than me if you do, since then I have learned something.

And yes, I have programmed in C# for a few years (for work besides curiosity projects to learn new things), C# customers are out there also.

Quote:

---

Originally Posted by Togga

Again, you're missing my point. If disk-space are tight, we're probably in an embedded device. Lets say we have an RTOS with a C-library. What consumes more space, a hello world in C or a hello world requiring the Mono stack to go along? For me Mono and .NET really have nothing to offer. Couldn't you prove me wrong with something other than to save a few characters of code? Nobody gets happier than me if you do, since then I have learned something.

---

So your point is, if I got it right: adding for a hello world like code an extra library is extra baggage that sometimes is not justified. And I think is nothing to argue about. For making a slow phone to work with Mono may not be worthwhile, also on a very low end tablet with 400 MHz ARM and if your application is computing intensive. On the other hand, in most cases the software does not work in a lot of situations just for those devices. If we look about language popularity, Java seems to be the most popular language, and the reason may be simply that is there by default. Either installed by OEMs, or is part of the install package, Java is a lot of times included in the package. Mono's runtime DLLs (mono.dll, mono.exe, system.dll, system.Xml.dll) on Windows are around 4 MB, and I think it can be made smaller if I would go to cygwin and pick compilations flag to disable some features that come into package. But the most important part is that Windows includes at least .Net as parts of OS (like Vista or Win7), or as an update (Windows XP). Windows 8 will have also a form of .Net 4.5 as part of WinRT platform.
So for this reason, the Hello world in WinRT world, will be just some KB on disk. It doesn't matter that .Net represents let's say 30% of Windows 8 tablet install (is smaller, but just to take as a random number to not argue about it), because the applications that we get over the internet, that would likely combine to make what Win8 represents, would not be an extra burden for developer to provide.
In this very same way is the same with Android and Java language: it is a part of the phone, is not an extra baggage, and even better, is smaller than the corresponding full compiled code, so is always smaller than a compiled application.
But if we talk for a custom solution, let's say a complex game, is legitimate to ask, what should be picked: a C/C++ code, or my application with an embedded VM. And the answer I think is always: depends. As for me, if the VM is not running in an interpreter, and you have a profiler (so you can write well the slow parts), and is included as part of the OS, I think is better to target the VM. Looking for leaks is always ugly. If we talk with higher end tablets, 5 MB extra for an application like this Android one (44 MB download size) is likely to not be noticed. In most cases because Mono have (more functionality) and the generics compile at runtime, so not many template expansions would make huge binaries, so you may have a smaller application to start with. Also MSIL is more compact than the binary (Dalvik presentation states that Dalvik is likely 6x times smaller than the tracing JIT generated code, a GCC like compiler can generate even bigger code).
At the end, if the generated binary code can get like 5x bigger than the "high level" MSIL/Dalvik or JVM bytecode, as bigger is the application as bigger are the savings. At the end there is one last thing: Android would "reincarnate" in more platforms/hardware combinations like: MIPS, x86. Is impossible to target with a static approach any future CPU. So the easiest way is still to write Java, or may use Mono and just recompile, and let Xamarin to hassle with GCC flags and issues like this.

Quote:

---

Originally Posted by ciplogic

Mono's runtime DLLs (mono.dll, mono.exe, system.dll, system.Xml.dll) on Windows are around 4 MB

---

Here you "forget" the fact that if you have to do something besides just running the code you must bring in additional frameworks (ADO,GUI,...), which in most cases (where performance matters) just are wrappers against C frameworks or written in C. You also may end up writing wrappers around existing C libraries.

Also, do not forget that you today easily can target a VM with C/C++ using for instance LLVM, adding one JIT to the target but requires no additional "framework", just the usual C libraries installed or linked to the JIT.

Well, lets summarize .NET:
* you have to go "all in" .NET since calling .NET components from the outside is a real pain
* you are tied to a GC (with platform dependent implementation)
* you are tied to an object oriented design with no multiple inheritance
* you have to bring the .NET runtime _AND_ libraries to every platform you target
* MSIL and CLR/JIT restricts what you can do and how creative solutions you can invent
* low end platforms are not suitable for .NET
* Reduced number of languages to choose from
* Languages other than the standard # must be specialized and restricted to .NET (you can't just use upstream compilers and libraries)

And we only had some syntactic sugar on the positive side?

I don't count the JIT or the GC on the positive side here as you can use them in most other languages as well (f.i. C/C++) and they are just a burden if you don't need it.

Compiled binary size might be a factor if MSIL should be much smaller than other intermediate formats (LLVM) or compressions. I don't know this but in practice however, the additional size for a register based VM or native code is usually worth it.

Quote:

---

Originally Posted by ciplogic

Android would "reincarnate" in more platforms/hardware combinations like: MIPS, x86. Is impossible to target with a static approach any future CPU.

---

C/C++/etc isn't any more "static" than C#, they are just different languages. But if you interpret ".NET" as dynamic, this is mostly just bullshit since in general, the more abstractions you have, the harder it is to optimize for new types of situations. And what if the GC is the worst component here?

Dont forget, when a new HW platform arrives, the case has been that the HW vendors have worked very hard to make a C compiler and libraries up and running (which Mono needs anyway). If you stuck with .NET you may also have to wait for Miguel to work some additional overtime...

I do not know why you're pushing .NET/Mono so hardcore, it has no obvious advantages, some obvious disadvantages. The problem space out there is in general so complex that you can't just stick with one solution. Given this and that it's always tough to predict the future the rule should be "be humble and choose the least restrictive (for future changes) tools for the problem". If you ask me, i'm starting to smell pure marketing...

Quote:

---

Originally Posted by Togga

(...)
And we only had some syntactic sugar on the positive side?
(...)
I do not know why you're pushing .NET/Mono so hardcore, it has no obvious advantages, some obvious disadvantages. The problem space out there is in general so complex that you can't just stick with one solution. Given this and that it's always tough to predict the future the rule should be "be humble and choose the least restrictive (for future changes) tools for the problem". If you ask me, i'm starting to smell pure marketing...

---

I said to you, I don't push .Net/Mono so hardcore. If you noticed, I give real numbers most of the time, I don't try to over-simplify the advantages of a language to another. I do see C++ advantages at times, and for example when I benchmarked Paint.Net, Gimp and Pinta, I've notied that if it would be on a single core machine certainly Gimp would be the fastest. So I said is a too simple to judge the idea of C#/Mono is slow just because C# code generator gives a code that may be 15 % slower when is also possible that C# can get extra performance using all cores.
I also worked a lot of years in C++, in CAD, aviation and such. CAD I can say that doesn't need more than .Net's performance, because all CAD packages include .Net plugin support. And even there is a performance hit, there is not such of a hit. Aviation, is very performance dependant, yet it does develop most of things in: C++ (of course), Ada and ... Java. And if you think that is just because Java is too slow was adopted later, as far as I know from inside, it was that there was not enough expertise to work with Java, and when there were more people knowing it, Java become popular (was the second option as popularity, the first being still C++).
I never worked in embeded, even I made (somewhat) programs for Android phone(s), and one of them there is a chess engine (is not mine, is my brother's one). It worked visibly slow with the interpreter, it answers too fast in the Android JIT. Means to wait for the next move it is in range of 0.1 - 0.2 seconds. I know, sometimes this range could be improved further using C++, but to use C++ for example you have to raise the platform requirements to Android 2.1 (talking about restrictions), as is the first platform that expose the JNI to endusers.
Also I think that is naive to think just syntactic sugar a Mono platform, as most people think about C# at least as a language with batteries (which you simply seem to ignore it), and the integration of an extra library in most times is way easier (adding a reference to an assemby means that you don't have to set: headers, environment variables and linker libraries).
As for me, the most important things that I love about C# is closer to Python world than C++ could be, it gives adequate performance for most tasks, easier than Java interoperation with C++ (in fact is somewhat easier than C++ way as a lot of times, when you export things in C++ from a DLL you have to set macros, for calling convention like __stdcall for Windows, __cdecl for unixes, extern "C" and so on).
The restrictions (if you mean that you an double delete a pointer, or you get over an array size) sometimes I would argue are fairly good to have. You can achieve this with STL too, but if you work with big applications and you don't put const vector<...> & everywhere, or vector <...>& like a lot of beginners don't, you will get a slower performing application than the C# equivalent, regardless of your expectations of C++ being the fastest. I do know that most operations with string/pointer arithmetics for example can be really a great thing you may achieve in C world (if you work in this world), but don't forget that at least C# gives to you the unsafe mode, which makes possible to do pointer arithmetic for image manipulations (this is the Pinta's code with effects: they get a pointer to every row and they process pixels of that row).
At the end, one thing I agree with you: most CAD systems were written like 20 to 30 years ago and they just added features. As Java/C# is fairly new for these codebases, they were added later. But people making plugins for them they needed C/C++ regardless of CAD's vendor preference. The problems you may need to solve need to talk a language that most things do know. This makes clear that most of tools have to expose C (I think C is "lingua franca" of interoperability, not C++, and luckily C# can interact with it directly, and Java 7 also made this possible via a decorated interface over libFfi). Also, as the maturity of the codebases is a big elephant for most companies, to work with a very cool platform but without support, may be really hard way to go. So C I can see it at least the frontend to expose a lot of functionality if you want to work for future with. If in the context of games, if you make a library that you want to have as many customers, you may write it into C/C++ and expose a C frontend and this part is really great.
If you talk anyway for tools, like the level designer, the "sugar" is in tooling, that lets you make fast UIs, process easily xmls, connect to database, developers may want to write it in let's say Java. The engine of the game can be exported in a lib.so and embedded in a window. This also is better to isolate when the problems are with engine and when are with tooling. The talking: why Java and why not Python, makes no sense here, in the point of: yes, Python is great is another VM. Is not to "demonize" the solution of Java, but Java would bring close to C speed (let's say even with a penalty, but if you will have a loop to write and you want that the loop to be fast, you will simply write in Java, and not write in C and import it as a Pyhton extension, because is too slow).
If you talk about most of tasks, at least where I'm working (I work in C#, but I like it, more than the Delphi coding that I do at times), most of the times to increase performance is simply to put it on a separate thread. This was talked earlier but as machines have multiple cores and is easy(er) to use from a C# like language (Go can be another), the performance loss from C++ code generator is more than compesnated by using (more) of the cores that the machine it has.

Quote:

---

Originally Posted by Togga

Well, lets summarize .NET:
* you have to go "all in" .NET since calling .NET components from the outside is a real pain
* you are tied to a GC (with platform dependent implementation)
* you are tied to an object oriented design with no multiple inheritance
* you have to bring the .NET runtime _AND_ libraries to every platform you target
* MSIL and CLR/JIT restricts what you can do and how creative solutions you can invent
* low end platforms are not suitable for .NET
* Reduced number of languages to choose from
* Languages other than the standard # must be specialized and restricted to .NET (you can't just use upstream compilers and libraries)

---

1. All in? As opposed to? Fundamentally, there is no platform today that you get to pick and choose from; examples are Gnome and KDE.
2. Yeah, #1
3. Negative and it's been proven a well thought out design doesn't need that mess.
4. #1 again.
5. So does Java, C++, and everything else. Those are the boundries.
6. Malarkey, .Net has been out for more than 10 years. My P3 Celeron / 256MB ram ran it with no problems. Quake 2 was ported to it.
7. F#, C#, C++, Python, VB, and you can even program in the native assembler. That's more than most Linux distributions ship with.
8. Upstream is a pipe dream; haven't you learned developers only listen to money stuffed in their ears. Unity, Gnome Shell and KDE...

When you graduate from the university and attain that first real job, come back and update your post. Reflect on lessons learned.
Let us know how rewriting spaghetti code has changed your mentally. When you don't have 6 months to embrace a multiple inherited
monster strewn about 6 levels of directory paths let us know how many bottles of Bismuth you went through before you switched jobs.

Respectfully,.

Quote:

---

Originally Posted by ciplogic

as most people think about C# at least as a language with batteries (which you simply seem to ignore it)

---

I've used C# for a few years and I fail to see more batteries there than using C/C++ libraries. There's lots of batteries for C and C++ out there. As for language features in C#, it looks good for a beginner but in long term the restrictions (see previous comment) comes and bite you. If you have experience, you will have plenty of trix down the sleeve with the languages that put the least restrictions on you. That said, a beginner will probably have a shorter time to market with syntactic sugar and less possibilities to screw up designs, memory handling etc. But for professionals, it's a completely different ball-game. If you're a beginner with even a slight ambition in programming there is really no short-cuts of learning about programming related problems and how that affect your product at it's runtime environment.

Quote:

---

Originally Posted by ciplogic

and the integration of an extra library in most times is way easier

---

This goes for all libraries that adds features. GCD makes concurrency handling easier, pthreads library makes threads easier, etc.

Quote:

---

Originally Posted by ciplogic

As for me, the most important things that I love about C# is closer to Python world than C++ could be

---

Python is a nice scripting language, especially strong for scientific computing and very good interaction with C. Now with a JIT compiler etc. I tend to use it for support functions. Could also be handy for GUI's.


Syntax is nice, but you can write beautiful programs in many languages :-) For one-file-scripts though i think Python can have a readability advantage (if done right).

Quote:

---

Originally Posted by ciplogic

and you don't put const vector<...> & everywhere, or vector <...>& like a lot of beginners don't, you will get a slower performing application than the C# equivalent

---

That may be an argument for a beginner which doesn't apply to me. These type of performance problems could be taken by static code analyzers. Beginners can screw up in any environment, for instance have severe performance bottlenecks in C# due to unnecessary boxing/unboxing without even knowing about it.

Quote:

---

Originally Posted by ciplogic

And if you think that is just because Java is too slow
regardless of your expectations of C++ being the fastest.

---

A Language is in itself not slow, it's the environment the product operates in and the quality of the tools targeting that environment.


[QUOTE=ciplogic;252768]

Quote:

---

Originally Posted by ciplogic

I think C is "lingua franca" of interoperability, not C++, and luckily C# can interact with it directly

---

My experience is that C# C interaction is really only one-way (ie no INTERaction). Calling .NET components from C is not an easy feat.

If we take the Python example we can pretty easy do object oriented programming where we make an C class inherit from a Python class which inherits from a C class etc. Neither runtime environment knows in which language the object is implemented in, just that it has an C interface. This is nice in multiple scenarios, like testing, extensions, etc.

That is good C interaction and can be quite performant if you put an JIT on the Python side of things. These kind of interactions are very hard to do with a language like C# where you eventually have to go all in or all out .NET to bring down complexity of the interactions.

Quote:

---

Originally Posted by ciplogic

most of the times to increase performance is simply to put it on a separate thread. This was talked earlier but as machines have multiple cores and is easy(er) to use from a C# like language (Go can be another),

---

And this goes for all languages that are able to reach OS threading functionality.

Quote:

---

Originally Posted by Togga

(..)But for professionals, it's a completely different ball-game. If you're a beginner with even a slight ambition in programming there is really no short-cuts of learning about programming related problems and how that affect your product at it's runtime environment.

---

There are a lot of C# professionals, and biting you is a random issue. A lot of programs do need to be productive, not necessarily performance driven. C# gives good performance (you didn't come with numbers, what is so slow to you anyway!?) and gives productivity too (seems you agree with this at least).

Quote:

---

My experience is that C# C interaction is really only one-way (ie no INTERaction). Calling .NET components from C is not an easy feat.
If we take the Python example we can pretty easy do object oriented programming where we make an C class inherit from a Python class which inherits from a C class etc. Neither runtime environment knows in which language the object is implemented in, just that it has an C interface. This is nice in multiple scenarios, like testing, extensions, etc.
That is good C interaction and can be quite performant if you put an JIT on the Python side of things. These kind of interactions are very hard to do with a language like C# where you eventually have to go all in or all out .NET to bring down complexity of the interactions.
And this goes for all languages that are able to reach OS threading functionality.

---

About no way to interact, I think you miss the point, it is done already (like these Qt wrappers). It is possible to interact both ways with C, in fact there is no boxing for most primitive types. The calling callback is really the way of Windows.Forms was implemented in Mono: the libGdi.so is implemented using Gtk+ and Cairo as a C library and Windows.Forms is implemented in managed language (C#) using both way interaction. Mono Windows.Forms is buggy but shows that is done to work with real applications.
So you said: 2 way interaction is possible, you can share pointers (Pinta does it, like here, where:

Code:

---

ColorBgra* dstPtr = dest.GetPointAddressUnchecked (dst_dataptr, dst_width, rect.Left, y);

---

is a pointer to a Cairo C surface row and the pixels are written in place.
It works and it works well.

[QUOTE=ciplogic;252796]C# gives good performance (you didn't come with numbers, what is so slow to you anyway!?) [/CODE]

Straw-man-argument. Where did I say slow? I'm talking about restrictions and control. Restrictions ties my hand on the back and control I need to solve specific runtime problems.

Again. C# itself is not fast/slow, its a computer language. What's fast/slow is the runtime environment which depends on the quality of the compilers.


[QUOTE=ciplogic;252796]About no way to interact, I think you miss the point, it is done already (like these Qt wrappers). [/CODE]

This is a wrapper for the QT library, not exactly the interaction I'm talking about. And this basically goes managed to native with managed having full control over the QT libraries, which is trivial.


[QUOTE=ciplogic;252796]The calling callback is really the way of Windows.Forms was implemented in Mono: the libGdi.so is implemented using Gtk+ and Cairo as a C library and Windows.Forms is implemented in managed language (C#) using both way interaction.[/CODE]

Another usage of libraries controlled _FROM_ .NET.

Quote:

---

Originally Posted by ciplogic

So you said: 2 way interaction is possible, you can share pointers (Pinta does it, like here, where:

Code:

---

ColorBgra* dstPtr = dest.GetPointAddressUnchecked (dst_dataptr, dst_width, rect.Left, y);

---

is a pointer to a Cairo C surface row and the pixels are written in place.
It works and it works well.

---

This is finally a native to .NET example, and of course it's possible. But is it cross-platform? Is it standard, could I just recompile against Windows .NET?

http://www.mono-project.com/Embedding_Mono

Would you implement a class inheritance across languages (native, managed) for fast-path code using these constructs?

Quote:

---

Originally Posted by ciplogic

It is possible to interact both ways with C, in fact there is no boxing for most primitive types.

---

Here's another issue to my list, I mentioned it earlier as an .NET internal problem but thanks to pointing this out.

You have to realize that subjective statements like "not slow" , "not memory hungry", "no large footprint", etc are not selling features for Mono, they seems at best are defensive statements for "accusations". .NET have obvious disadvantages, what you fail to do is justify the choise of .NET in the first place. I am a seasoned programmer, intrested in new tecniques and have used .NET extensively in the past.

.NET for me is like every other library out there that provides you with functionality. I can't say I program faster in C# compared to lisp, prolog, Java, C++ or whatever. Maybe for small specific examples one language stands out but overall for a big project there are other factors that are more important.

What speaks volumes for comparisons is identical products in two environments. We seen what happend Gnote vs Tomboy, both performance-wise, development-time-wise and not to mention the reactions from Mono community. It really put "vapor-ware"-stamp on Mono. And for .NET in general we know C++ is MS first choise internally and is now "going native" for W8 externally. .NET is ice cold right now.

[QUOTE=Togga;252840]

Quote:

---

Originally Posted by ciplogic

The calling callback is really the way of Windows.Forms was implemented in Mono: the libGdi.so is implemented using Gtk+ and Cairo as a C library and Windows.Forms is implemented in managed language (C#) using both way interaction.[/CODE]
Another usage of libraries controlled _FROM_ .NET.

This is finally a native to .NET example, and of course it's possible. But is it cross-platform? Is it standard, could I just recompile against Windows .NET?
http://www.mono-project.com/Embedding_Mono
Would you implement a class inheritance across languages (native, managed) for fast-path code using these constructs?

Here's another issue to my list, I mentioned it earlier as an .NET internal problem but thanks to pointing this out.

What speaks volumes for comparisons is identical products in two environments. We seen what happend Gnote vs Tomboy, both performance-wise, development-time-wise and not to mention the reactions from Mono community. It really put "vapor-ware"-stamp on Mono. And for .NET in general we know C++ is MS first choise internally and is now "going native" for W8 externally. .NET is ice cold right now.

---

The C "controlled from .Net" is a fair statement, but C runtime can get pointers to functions that will eventually call delegates from C# side, so is a two way interaction. If you want to do it in a way that C/C++ code have the main function, I fully agree is harder, but there are still other mechanisms (like DBus) to make the communication easier.
The code sample works in Pinta codebase and works over 3 main platforms and the restriction is where Cairo and Mono can be ported (is a C limitation). If you make C surface, you can share the pointer in C# and use unsafe code it would work in all Mono/.Net platforms are accessible.
In fact is really hard to call giving you have a pointer to a C++ class, to call a function using a C compiler. Probably the code would be like: (VTableFunc1ParamInt)(*instance)[3])(instance. 2); it would be probably the way to do a virtual call. In this very same way is very hard to do an ObjectiveC to C++ calls (or I did not managed, excluding than through C).
Comparisons with similar products are many to turn the balance backward: Eclipse (using Java) is (one of) the best IDEs to date. If you want a lighter one, MonoDevelop is more featured than Anjuta (to put them in the same class of applications, NetBeans or Visual Studio is better than QtCreator or KDevelop. Most IntelliJ tools (which are all managed) are to some extend better than their counterparts (may we argue if XCode is better than the new ObjectiveC version 1 from IntelliJ, but overall is better).

There are many features that people are used to make, and they are abstractions. As I said previously, are people that can live without dependency injection (that is hard to do it without annotations), some algorithms are harder to do without a GC (most of multi-threaded ones), the code is a bit smaller so is less prone to errors. I am used to use Linq, and people can iterate over collections without Linq, without iterators and can write code without lamdas (which luckily are a part of C++11). ParallelLinq (Parallel.ForEach) is too easy to be used and is nice to do it. If you want to call a web service, this functionality is embedded in all C#/.Net implementations, I don't know other way than through Qt (which you can agree is not standard) to be cross-platform. Dynamic calls can be avoided and late-binding may not be that important, but some web frameworks (like Razor/MVC3) make the web programming much more easier. Linq makes Xml, databases and xml processing to have all time adequate performance because their back implementation is a decent one. Maybe some skilled programmer can get a better database connection code. Data binding is another killer feature for me (with WPF). I define a property that is binded to property "Name", and every time I add an object in a list, via reflection the WPF List is filled with items of property Name (more-or-less like Go's implicit interfaces). When you go to C/C++ world, I don't know something equivalent (maybe Qt has it, I don't know about ObjC), but would make it nice to have, isn't so?

Quote:

---

Originally Posted by BlackStar

...perform identically between C# and C++. There's no inherent disadvantage in a statically-typed managed language vs a statically-typed unmanaged language.

---

Yes there is, we have the garbage collector logic which does eat cpu cycles even if it doesn't trigger a cleanup sweep even for a simple example like this. And in reality code is not as trivial as your examples and here we have other optimization possibilities like pointer arithmetic which can't be used in managed code unless you temporarily go into unsafe mode which is expensive, just like it's expensive to call external unmanaged code from the vm, not to mention all the managed code boundary checks.

Even looking at the pure number crunching benchmarks over at Language Shootout shows that managed code languages like Mono trails unmanaged code by quite a margin.

Quote:

---

Originally Posted by BlackStar

In other words, the distinction here is not actually managed vs unmanaged, it is high-level vs low-level. The lower the level, the more micro-optimizations you can make - and these are what make the difference in tasks such as compression and encoding.

---

Ah but even when you have to functionally identical pieces of code there's still the overhead of the GC, looking past that you do have more optimization flexibility in native code than in managed code again due to the contraints on memory manipulation through pointers placed upon you by the managed code VM, so yes C/C++ allows you more 'low-level' opportunities.

Quote:

---

Originally Posted by BlackStar

It throws away pretty much all OpenGL ES parts that are not statically verifiable - and Google has built a WebGL compiler that checks your code and refuses to execute it when it detects anything unverifiable.

---

Yes but that is done in order to properly sandbox the WebGL applications in order to avoid WebGL exploits through the browser.

Again, I am not against managed code, or garbage collecting, I do however realize the performance implications which come with them. I use Python and I will most certainly use Go in the future (hopefully even at work), but I will also continue to use C and C++ for areas where performance/resource usage is important.

Quote:

---

Originally Posted by XorEaxEax

Ah but even when you have to functionally identical pieces of code there's still the overhead of the GC, looking past that you do have more optimization flexibility in native code than in managed code again due to the contraints on memory manipulation through pointers placed upon you by the managed code VM, so yes C/C++ allows you more 'low-level' opportunities.

---

For identical functionality C++ with STL is slower than .Net. There are many papers confirming this, and I was even saying in a previous post:

Quote:

---

Originally Posted by ciplogic

And in fact sometimes it performs even better.
Note: thanks for notice me about Togga :) Regards and have great programming time.

---

The reason is that the .Net JIT can and do more bounds checks removal than C++ does. There are other sources for this.
Another functionality where C++ is known to be slower is in allocation of memory compared with a generational GC (which luckily Mono eventually got one). The malloc/new routine is so slow, that most of high performance libraries that profiling shows that allocation is a bottleneck, they let you override it, for example in this CAD library.
You can test it yourself: create a lot of small objects using new/delete (or malloc/free), and do a lot of small objects in C# or Java. You may be surprised that is not uncommon to see 6x speedup to the GC side of things. And the reason is simple: the small heap that is moved (the slowest part of the GC) just if is referenced. If you make a lot of small objects and you don't reference them a bit later, they are not moved and is just a scan of the stack (which can have let's say 1MB in size).
Another area where .Net or Java may be faster is that when the JIT gets an improvement. I'm not sure if you know about SSA form, which is a linear easy to optimize on intermediate representation, but some older mainstream compilers (like FreePascal, or GCC 3.x) do not have. This would mean that some cases of Dead-Code-Elimination and sparse conditional constant propagation (Wikipedia article) may happen in an improved JIT, but would not happen in the static compiled code. So to get a speedup, you may need to upgrade Mono, and get the speedups that your old game may not benefit. SSA form optimizations were implemented in .Net too (version 3.5 SP1), maybe a bit too late (like year 2009, compared with first GCC 4.x series to be at least 5 years before) but is given for free, so no one would complain. At the end, Mono, .Net and Java at least they inline much more aggressively some parts of code, that it is nice to have in real OOP code, so a similar written code is not that surprising to be faster in a JIT.
JITs have a slow area in most of the cases and this is the "short time to deliver", which makes that two optimizations most time to be skipped: loop unrolling (sometimes combined with auto-vectorization), because duplicates a lot of code and will take even more time to compile all new code, just Java's HotSpot server does it), and a better register allocator (most of VMs use Linear Scan Register Allocator) which is the "de-factor" register allocator for most VMs: Java -client, .Net, Mono, Tamarin VM (Flash VM), Android JIT.
Edit: Here is a balanced article that tests (old versions) of STL and C#/.Net/Mono.

As Miguel talk was published in his blog, in full, it seems that he showed ways how games can use GC nicely, based on heuristics so it would make it predictable. In short, what it does, it simply states that you can do GC.Collect(0); every 1-2 seconds, and you can have great performance and no scary pauses. Also, it showed a way to embed Mono runtime and explained how evolving C# language can solve hard problems (like state machines) with Async C# 5.0 features, making your program to be responsive even it does heavy lifting. It also states a thing that the title of the Phoronix article misses, is that it called at least for scripting to use C#. For me is really a great talk. The second hour is about a real game that was written just in C# and do heavy computations (like aerodynamics simulation) and it works on WinPhone and iPad using MonoTouch and that MonoTouch gave always adequate performance for his game (Infinite Flights).

For game in java, I prefer image processing in java, interesting and stable.

I hope he can successfully make a living out of it.http://www.govazd.info/28.jpghttp://www.govazd.info/02.jpghttp://www.govazd.info/03.jpghttp://www.govazd.info/05.jpghttp://www.govazd.info/04.jpghttp://www.govazd.info/29.jpg

Quote:

---

Originally Posted by ciplogic

As Miguel talk was published in his blog, in full, it seems that he showed ways how games can use GC nicely, based on heuristics so it would make it predictable. In short, what it does, it simply states that you can do GC.Collect(0); every 1-2 seconds, and you can have great performance and no scary pauses. Also, it showed a way to embed Mono runtime and explained how evolving C# language can solve hard problems (like state machines) with Async C# 5.0 features, making your program to be responsive even it does heavy lifting. It also states a thing that the title of the Phoronix article misses, is that it called at least for scripting to use C#. For me is really a great talk. The second hour is about a real game that was written just in C# and do heavy computations (like aerodynamics simulation) and it works on WinPhone and iPad using MonoTouch and that MonoTouch gave always adequate performance for his game (Infinite Flights).

---

In short, Miguel tries to find workarounds for some of the issues he impses with C#. This is a classic game of crossing the river for water. Thank god, even Microsoft is throwing C# on the scrapyard nowadays.