Announcement

Collapse
No announcement yet.

Miguel de Icaza Calls For More Mono, C# Games

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • phoronix
    started a topic Miguel de Icaza Calls For More Mono, C# Games

    Miguel de Icaza Calls For More Mono, C# Games

    Phoronix: Miguel de Icaza Calls For More Mono, C# Games

    Miguel de Icaza presented this weekend at AltDevConf where he heavily promoted Mono and using C# for game developers...

    http://www.phoronix.com/vr.php?view=MTA1Njc

  • Togga
    replied
    Originally posted by ciplogic View Post
    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.

    Leave a comment:


  • Triv00ett
    replied
    I hope he can successfully make a living out of it.

    Leave a comment:


  • Wodehous DICOM
    replied
    For game in java, I prefer image processing in java, interesting and stable.

    Leave a comment:


  • ciplogic
    replied
    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).

    Leave a comment:


  • ciplogic
    replied
    Originally posted by XorEaxEax View Post
    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:
    Originally posted by ciplogic View Post
    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.
    Last edited by ciplogic; 03-06-2012, 09:17 AM.

    Leave a comment:


  • XorEaxEax
    replied
    Originally posted by BlackStar View Post
    ...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.

    Originally posted by BlackStar View Post
    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.

    Originally posted by BlackStar View Post
    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.

    Leave a comment:


  • ciplogic
    replied
    [QUOTE=Togga;252840]
    Originally posted by ciplogic View Post
    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?

    Leave a comment:


  • Togga
    replied
    [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.


    Originally posted by ciplogic View Post
    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?


    Originally posted by ciplogic View Post
    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.

    Leave a comment:


  • ciplogic
    replied
    Originally posted by Togga View Post
    (..)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).
    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.

    Leave a comment:

Working...
X