Page 9 of 32 FirstFirst ... 789101119 ... LastLast
Results 81 to 90 of 315

Thread: Why Mono Is Desirable For Linux

  1. #81
    Join Date
    Jun 2009
    Posts
    1,093

    Default

    Quote 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

  2. #82
    Join Date
    Dec 2010
    Location
    Calgary
    Posts
    136

    Default

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

  3. #83
    Join Date
    Jul 2009
    Posts
    351

    Default

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

  4. #84
    Join Date
    May 2012
    Location
    Sunshine State
    Posts
    303

    Default

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

  5. #85
    Join Date
    Sep 2012
    Posts
    9

    Default

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

  6. #86
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,777

    Default

    Quote 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; 09-14-2012 at 04:34 PM.

  7. #87
    Join Date
    Dec 2010
    Location
    Calgary
    Posts
    136

    Default

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

  8. #88
    Join Date
    May 2012
    Posts
    347

    Default

    Quote 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

  9. #89
    Join Date
    May 2012
    Posts
    347

    Default

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

  10. #90
    Join Date
    Sep 2012
    Posts
    12

    Default Very True

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •