Announcement

Collapse
No announcement yet.

Miguel de Icaza Calls For More Mono, C# Games

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

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

    Comment


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


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

      Comment


      • Originally posted by Togga View Post
        (...)
        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.
        Last edited by ciplogic; 03 March 2012, 07:10 AM.

        Comment


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

          Comment


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


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


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


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


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


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

            Comment


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

              Comment


              • [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?



                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.

                Comment


                • [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?

                  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?

                  Comment


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

                    Comment


                    • 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; 06 March 2012, 09:17 AM.

                      Comment

                      Working...
                      X