Announcement

Collapse
No announcement yet.

Why Mono Is Desirable For Linux

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

  • #81
    Originally posted by directhex View Post
    Okay. Here's one example, off the first page of "Java beats C++ benchmark" on Google. http://stackoverflow.com/questions/5...my-simple-test

    There are lots of them.

    A JITter can be very fast, y'know.
    this exactly prove my point, that is a horribly written C++ code running on VC that by default have many optimizations turned off like SIMD <--- aka that code is using x87 LOL

    take that code unroll it, add SSE/AVX, check the types, properly use templates and atomics[c++11], optimize the memory handling and use ICC or GCC with at least -O2 -march=native and -msse2 and compare it to java again

    Comment


    • #82
      Originally posted by frantaylor View Post
      Since it's under continuous development and it's C++ code, it will continue to suffer from all those problems that Microsoft is trying to solve with .NET.

      In other words Microsoft has learned NOTHING from years of experience. They still code their apps exactly the same way they did 25 years ago. All that stuff they tell us to do, they don't do it themselves. I wonder over and over again why anyone would purchase products from these people.

      If Microsoft can't use its own development tools to maintain and improve their own products, I honestly can't see the merit in pushing these development tools on other people. Why would they be useful to me when they aren't even useful to Microsoft?

      And then you can go to the node.js home page and read the GLOWING recommendation from MICROSOFT who says it's the best web development environment for their purposes. So a cobbled-together server program is WAY BETTER then THEIR OWN products. Says a LOT.
      The merit for MS is not in providing better tools or better software. The merit is in retaining customers and developers.

      If every few years MS renames all it's APIs (remember COM & ActiveX haha) and/or replaces the tool-chain then the Windows devs spend all their spare time relearning how to program Windows... and not spending any otherwise spare time learning about POSIX or X Window or even Mac OS X.

      This strategy serves MS very well.

      *NIX... well you know, pthread_create(), it don't need to change. It's already perfect.

      Comment


      • #83
        Originally posted by directhex View Post
        Okay. Here's one example, off the first page of "Java beats C++ benchmark" on Google. http://stackoverflow.com/questions/5...my-simple-test

        There are lots of them.

        A JITter can be very fast, y'know.
        JIT will NOT help you write fast loops. The JIT runtime will not fit in the processor's cache, your program will score many cache misses and the loops will slow down.

        Your processor is running at many GHz, but main RAM is terribly slow, you don't want your loops to be fetching from RAM on every instruction.

        If you carefully hand-code your loops you can fit the whole thing in the fast cache and the loop will scream.

        As was otherwise pointed out, JIT will mitigate bad code, but if the code is solid in the first place, it's not going to help.

        Use the right tool for the job! JIT gives you a VM, memory safety, and nice debugging features. It won't magically fix your bad algorithm or improve performance of an otherwise optimal program. JIT also means big runtime baggage and potential compatibility issues if the customer has a different version.

        Comment


        • #84
          C#'s fine, but I think D + Mono-D + GTKD (which now supports Gtk 3) is ultimately a better solution overall.

          Comment


          • #85
            Originally posted by frantaylor View Post
            JIT will NOT help you write fast loops. The JIT runtime will not fit in the processor's cache, your program will score many cache misses and the loops will slow down.

            Your processor is running at many GHz, but main RAM is terribly slow, you don't want your loops to be fetching from RAM on every instruction.

            If you carefully hand-code your loops you can fit the whole thing in the fast cache and the loop will scream.

            As was otherwise pointed out, JIT will mitigate bad code, but if the code is solid in the first place, it's not going to help.

            Use the right tool for the job! JIT gives you a VM, memory safety, and nice debugging features. It won't magically fix your bad algorithm or improve performance of an otherwise optimal program. JIT also means big runtime baggage and potential compatibility issues if the customer has a different version.
            ^^^This.

            The problem is that Java and .NET never quite succeeded at mitigating bad code, and automatically managing memory added as many problems as it solved.

            Java and .NET fill a void between C/C++ and interpreted languages like Python and Perl, and frankly I think that's a dying niche... There's so few good applications written in those 2 languages, they're primarily used by corporate developers who are relatively unskilled to write crappy enterprise applications.

            Comment


            • #86
              Originally posted by directhex View Post
              Qt 1.0 and GTK 1.0 are still shipping? An app built against those will build today and run?

              If not, you need to relearn/retrain every time the Mad Hatter shouts "change places!" and random APIs get thrown out of the window
              Yeah, good luck running your software that's written for the Windows for Workgroups 3.11 APIs on Windows Vista.

              Windows evolves, APIs change, so does Linux. On Linux it's actually better; you *can* run your old software from 1992 on a 2012 Linux installation. Not even Windows can beat that.
              Last edited by RealNC; 14 September 2012, 04:34 PM.

              Comment


              • #87
                Originally posted by F i L View Post
                C#'s fine, but I think D + Mono-D + GTKD (which now supports Gtk 3) is ultimately a better solution overall.
                I hear there is an port of Intercal to .NET on the way.

                Comment


                • #88
                  Originally posted by jrch2k8 View Post
                  this exactly prove my point, that is a horribly written C++ code running on VC that by default have many optimizations turned off like SIMD <--- aka that code is using x87 LOL

                  take that code unroll it, add SSE/AVX, check the types, properly use templates and atomics[c++11], optimize the memory handling and use ICC or GCC with at least -O2 -march=native and -msse2 and compare it to java again
                  You can't assume SSE2 on your executing platform. Take a Linux distribution as an example, you need to build things for the lowest common denominator. Debian's i386 version requires a mandatory i586-class processor as a minimum, for example (i.e. an original Pentium 90MHz is supported). A JITter is great for supporting wide classes of system, since it can enable run-time optimizations that GCC flags can't

                  Comment


                  • #89
                    Originally posted by RealNC View Post
                    Yeah, good luck running your software that's written for the Windows for Workgroups 3.11 APIs on Windows Vista.
                    They'll work, on 32-bit Vista.

                    Comment


                    • #90
                      Very True

                      Originally posted by Sidicas View Post
                      ...Mono is *very* important for cross-platform games from small companies.
                      This is very true. Its the reason iv'e been able to quickly and easily develop cross platform games on literally every platform with just two people using C#.
                      Other good examples of where Mono C# has become very productive is Unity3D scripts. No need to learn some specialized scripting language.

                      Comment

                      Working...
                      X