Announcement

Collapse
No announcement yet.

Phalanger: Stuffing PHP With Mono, .NET

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

  • #21
    Originally posted by ciplogic View Post
    Why spamming here?
    Because I didn't get the answer I want.

    Mono/.Net applications that performance matter and is good enough:
    - MonoDevelop/SharpDevelop
    - Paint.Net/Pinta
    - Xsp/Asp.Net ones
    - SecondLife scripts, Sims 3 scripts
    - Mono for Android (faster than the default platform) / MonoTouch: is good enough for an iPhone/iPad
    - Phalanger: fastest PHP implementation to date
    - Gnome-Do, is one of the fastest way to start an application
    Excluding Gnome-Do, all of those projects are not toy projects, doesn't seem to you so?
    That are clearly toy projects excluding the first one. Such applications, scripts are rather easy to do and didn't bring any advantage to Linux. Something like 3DS Max, MS Office, Photoshop will made a difference and prove mono is more useful than others.

    Comment


    • #22
      Originally posted by XorEaxEax View Post
      Enough with this bullshit that writing native code is so hard, it's not. Your entire OS is written in unmanaged code, the VAST majority of software you use on your computer is written in unmanaged code. Compilers, encoders/decoders, archivers, browsers, text editors!, window managers, drivers, 3d programs, version controls systems, emulators, p2p programs, image editors, etc ad infinitum, heck I just came across this yesterday where a note application (admittedly with lots of features) went from managed code to native because they couldn't get good enough performance from managed code in even such an app!. http://blog.evernote.com/2010/10/26/...ndows-is-here/
      I firstly want to appreciate your positive spin on the last paragraph. Also I'm wanting to say that some parts you told are wrong: yes, templates are hard(er) than most generics implementation, also the argument "Ad Populum" is not enough to prove any point. It may really be that "VAST majority" of software is written in "unmanaged code", but a lot of it is not written in non-managed code. A lot of developers write non-desktop applications and they use either an interpreter (PHP, Python, Perl), or they use scripting for configuring (Python or Ruby), they can be a DB, and write DDL/SQL. If you think as Google Docs as an application, it is basically written in Java and there is a Java compiler that rewrite it in JavaScript.
      - Compilers: Mono's DMCS, GMCS, MCS are written in C#. ECJ (Eclipse Java's compiler) is written in yes, Java. In fact there is no CUDA compiler written in shader languages does not prove that there is the performance issue using shaders.
      - there are archivers/extracters that are written in managed languages, JVM depends on archived Zip files and it does most of the time using Java snippets. In most cases the performance of Java/C# working with archiving is at least OK. Most people would not use Java based archiver because is not named: WinZip, WinACE, etc. and is a customs issue, not necessarily a VM issue
      - browsers, renderers and encoders are really where is hard to use a VM language when you want fine grained performance, drivers too, so they tend to be written in C/C++.
      Yet, there are places where JVM for example was used as an optimizer (the query planner of Oracle DBs is using a JVM, because HotSpot can optimize the query computation equation. It is great to get a runtime compiler that optimize the code based on DBA's patterns, not static precompiled templates.
      At the end, Evernote was complaining for an issue that is not dependant on .Net managed side, they complained on drivers that have issues with WPF drivers or WPF design. I can argue that C/C++ side was too hard of the WPF. WPF (Windows Presentation Foundation) have a COM/C++ fundations which provide a mini-framework of accelerated UI on top of DirectX 9. Combinations of bad performance of DirectX 9 + XP/Vista/Win7 with integrated video cards was the issue, wasn't it? Did I read other article? In fact, how could Microsoft use WPF in their IDE, if it was so blurry and slow? Why SharpDevelop uses it too? I think that maybe most of those issues were fixed either as a part of WPF (from .Net 4) or by video drivers providers. The startup time complained also was because WPF loads much more things (like DirectX9 on Win Vista/7 is not loaded as a default framework, so there is the need to load more libraries), and memory is likely to be related on the same issue.
      In fact the XWT (the new cross-platform API for MonoDevelop and maybe Mono) is based on WPF on Windows, Gtk# and Cocoa# and it will use the WPF designer for designing UIs.

      Comment


      • #23
        Originally posted by kraftman View Post
        That are clearly toy projects excluding the first one. Such applications, scripts are rather easy to do and didn't bring any advantage to Linux. Something like 3DS Max, MS Office, Photoshop will made a difference and prove mono is more useful than others.
        In fact MS Office plugins are easier to be targeted with .Net plugins (did you worked with its SDK!?), because Office 2010 have 64 bit support, so you have to support 2 platforms instead of one. LibreOffice supports a much slower Python as a development platform, if used balanced it is a great thing to have.
        In fact Mono's platform is mostly written in C# 55%, Xml 33% and have a lot of functionality. C language!? Just 7%.
        A lot of old software packages don't support Mono/Java for other reasons than performance. Pinta/Paint.Net proves that there is no showstopper to use Mono/.Net as a Photoshop replacement. It may be added more functionality as years pass, but I agree, is not a full replacement.
        If you mean huge applications that are written in Java, and are invaluable for a lot of developers, IDE's like IntelliJ IDEA bring static code analisys, and is done "for free". Or Eclipse for that matter. Is hard to imagine (excluding XCode and QtCreator) big IDEs without a VM support to one level or another. Qt platform for example uses QML which embeds a JavaScript VM by default to define UIs.
        AutoCAD for example have .Net plugin support, and no one attacks it. I mean a lot of CAD tools for example have .Net support. Why not written at all in C#? Because C# appeared at least 10 years too late. Is like asking why no major framework is using C++ x11, or why even GCC has no 100% passing of C++ 11 features. People use platforms if are needed, when are needed.
        3DSMax could be written in .Net and it has in its SDK C# support. Not all of course, there is no need in life to write everything in C++ for that matter, at the end any developer in C++ would use some pointer arithmetic for a string processing, or some assembly optimized routine for a matrix multiplication, but most of the code certainly would be written in a high level code style, isn't so?
        Last edited by ciplogic; 07 March 2012, 06:01 AM. Reason: 3ds Max links to .Net SDK

        Comment


        • #24
          Originally posted by XorEaxEax View Post
          Enough with this bullshit that writing native code is so hard, it's not. Your entire OS is written in unmanaged code, the VAST majority of software you use on your computer is written in unmanaged code. Compilers, encoders/decoders, archivers, browsers, text editors!, window managers, drivers, 3d programs, version controls systems, emulators, p2p programs, image editors, etc ad infinitum, heck I just came across this yesterday where a note application (admittedly with lots of features) went from managed code to native because they couldn't get good enough performance from managed code in even such an app!. http://blog.evernote.com/2010/10/26/...ndows-is-here/
          Aha, and the only kind of apps that exist in our universe is consumer apps. No business apps. I could give you examples of non-native apps in any area anyway. And the OS is not a too good example, obviously it will be more or less native, but that's just irrelevant, we're talking about application development, not OS development.

          Originally posted by XorEaxEax
          What we see here is the lazy enterprise developer mentality with the classical crap like 'oh, memory is cheap', 'so what if it's slower just throw better hardware at it' comments. Looking past this crappy attitude there are indeed advantages in development speed with garbage collected code running in a VM, however it comes with a price of more memory usage (due to managing it's own heap) and a loss of performance. I remember being shocked at the difference in performance between Shotwell (vala) and F-Spot (Mono) when managing images, that may not entirely be due to managed vs unmanaged code since there could be different algorithms at play aswell but it certainly isn't a good advertisment for managed code.
          It's not lazyness, it's the need for rapid development. An enterprise calls you that they need something big withing 6 months, but ohwait, that won't be enough coz you're still too busy with your memory allocations, buffer overflows and character pointer manipulations (what is string? i donno that!). But hey, it's definitely worth it coz you can save like 30% of memory (thus a few bucks), even though developing that crap costed thousands of dollars more due to programmer salary, hurray. What a gain. Speed is not a concern, this article is the proof. And yeah, you can write crappy code in any language, but that's not the language's fault.

          Originally posted by XorEaxEax
          So no, I'm not surprised that managed code languages like Java/C# is finding it difficult to penetrate the home desktop. Even on windows where the .NET runtime has come preinstalled in the last two OS incarnations. End users will prefer the faster and less memory demanding versions of applications, and native application developers (despite what managed code advocates try to claim) are not crippled by manual memory management. And in the areas where performance have little to no impact we often see scripting languages like Python, Lua, heck even bash scripts being used instead.

          Personally I'm happy that Java/C# has failed to make an impact on the user desktop, it means my current RAM and CPU power allows me to do more with my computer when I'm running several browser instances, inkscape, blender, text editors while also compiling code and encoding some test render animation in x264 to show a buddy. I love the performance and memory efficiency I get with these native code applications and I can only assume that so does their authors.
          Select python, perl and mono for deletion in Synaptic. It will tell you what additional packages will be removed due to dependencies. According to your hateful comments you'll be surprised by their numbers.

          You may also uninstall/disable .Net on Windows. Another surprise.

          Or install Windows 8 and see the Windows Store. Lot of non-native apps. It must be a paradoxon, they just can't work. You DO need that additional 200kB of free memory, otherwise that's just lazy programmers and resource-hungry apps. Ewww.

          You may also try flaccl, which is a flac encoder written in .Net, and guess what, it's faster than the stock encoder because it's smarter. Or the phalanger stuff. Whatever, I could search for examples all day, it won't convince you. Cuz you know best.

          But I understand that even though all your points are invalid, you prefer to use native code EVERYWHERE because you select your tools by feelings, not by rationale.

          Comment


          • #25
            Originally posted by anarki2 View Post
            Aha, and the only kind of apps that exist in our universe is consumer apps. No business apps. I could give you examples of non-native apps in any area anyway.
            No of course not, for the type of rapid development apps often requested in the enterprise sector managed code does perfectly fine, there's a reason VB used to rule there, now it's Java/C#.

            Originally posted by anarki2 View Post
            And the OS is not a too good example, obviously it will be more or less native, but that's just irrelevant, we're talking about application development, not OS development.
            That's not what I used to hear from managed code afficionados back when Singularity made the news, suddenly Microsoft was going to go all managed code top to bottom... Of course it ended with Microsoft passing Singularity off to academia. Now we're seeing a 'going native' marketing push from Microsoft for VS 2012 highlighting C++11.

            Originally posted by anarki2 View Post
            And yeah, you can write crappy code in any language, but that's not the language's fault.
            Here we agree fully, I'm not saying you can't write great managed code, only that it will almost certainly use more resources (CPU/RAM) than equally great native code. The VM and garbage collecting is a convenience for the programmer but it's not magic, it comes with a cost.

            Originally posted by anarki2 View Post
            Select python, perl and mono for deletion in Synaptic. It will tell you what additional packages will be removed due to dependencies. According to your hateful comments you'll be surprised by their numbers.
            I know full and well how much Python is used (but hardly for performance dependant code), I am programming Python (along with C/C++) for a living. The only thing I ever had on my machine which required mono was f-spot, which nowadays has been replaced by the much faster shotwell (and thus no more need for mono on my system).

            Originally posted by anarki2 View Post
            You may also uninstall/disable .Net on Windows. Another surprise.
            What relevance does this have to the discussion?

            Originally posted by anarki2 View Post
            You may also try flaccl, which is a flac encoder written in .Net, and guess what, it's faster than the stock encoder because it's smarter.
            It's faster than the stock encoder since it uses opencl for gpu encoding, not because it runs on .NET. It could likely be written in Python and opencl and it would be faster than the stock version since it's the opencl code which makes it faster.

            Originally posted by anarki2 View Post
            But I understand that even though all your points are invalid, you prefer to use native code EVERYWHERE because you select your tools by feelings, not by rationale.
            Choosing applications which runs faster and uses less memory is not a rational choice? That was what made me replace f-spot with shotwell. I also use alot of Python scripts on my machine, but not for stuff where performance counts. Again I am happy that native applications prevails on the end user desktop since they are less resource hungry than managed apps are and therefore I can get more out of my computer hardware when running said native apps. Obviously if I want to run something and there's only a managed code version available with the necessary features I will run that (which is why I used to run f-spot to begin with).

            Comment


            • #26
              Originally posted by ciplogic View Post
              If you think as Google Docs as an application, it is basically written in Java and there is a Java compiler that rewrite it in JavaScript.
              AFAIK Google Docs the backend runs Java on big machines somewhere in GoogleDome while the only thing running on the end users machine is the javascript frontend (gui if you like).

              Also I'm not saying that there is no managed code alternatives to any of the software I listed, I was arguing against the often used claim by managed code advocates that native code with manual memory management is so very difficult by pointing out that the vast majority of software on the desktop is native code.

              Originally posted by ciplogic View Post
              Most people would not use Java based archiver because is not named: WinZip, WinACE, etc.
              I'm certain there are unpackers for zip, rar (does anyone use ACE these days? can't remember seeing such an archive in years) for Java and C#, I know there are for 7z, however unless you need to interact with such archives from within Java or C# code why would you ever want to use a managed code version of such an archiver? It will use more ram and be slower than the native code version. I'm certain even 'most people' would see no point in that.

              Originally posted by ciplogic View Post
              At the end, Evernote was complaining for an issue that is not dependant on .Net managed side, they complained on drivers that have issues with WPF drivers or WPF design.
              They were also complaining about 'slow startup times, large memory footprint'.

              Originally posted by ciplogic View Post
              Why not written at all in C#? Because C# appeared at least 10 years too late. Is like asking why no major framework is using C++ x11, or why even GCC has no 100% passing of C++ 11 features.
              C# appeared in 2001, Java in 1995, C++ 11 was finalized in 2011, pretty worthless comparison. Both C# and Java has had lots of time to make an impact on the end user desktop.

              Comment


              • #27
                Originally posted by XorEaxEax View Post
                I'm certain there are unpackers for zip, rar (does anyone use ACE these days? can't remember seeing such an archive in years) for Java and C#, I know there are for 7z, however unless you need to interact with such archives from within Java or C# code why would you ever want to use a managed code version of such an archiver? It will use more ram and be slower than the native code version. I'm certain even 'most people' would see no point in that.
                About unpackers, and such there are WPF/.Net applications that are good enough (like these ones). In fact as I know people don't ask: is it written in .Net!? Or: does it work reasonably fast and do all features that I do need!? This is why the most people I know use Total Commander at home (written in Delphi, and 64 bit in Lazarus) even it unpacks slower than a C++ or C# version would do. People don't do benchmarks and rarely care.
                They were also complaining about 'slow startup times, large memory footprint'.
                EverNote was complaining of loading WPF subsystem (which is the CoreCLR one) which uses more memory and IO (like loading DLLs) than a typical application. In fact a simple OpenGL appplication + a library that handles the UI + a small JIT (like Adobe AIR - similar in abstractions as WPF) can use more memory and load a bit slower than a C/C++ application. They did not complain that: "after starting up, WPF applications and EverNote appear to be slugghish, or maybe I "read" a different conclusion. If they would use advanced Qt features (like QML + QtWebKit) and they would load slow (as they would load a small browser at startup) they would possible write the same compared with "raw" Qt or Gtk in an Unity desktop.
                EverNote claims were taken for many reasons out of context, and some things were addressed, is unfair to throw any application (like the Hamster's software packages) cause a complex WPF loads slow. Also, I'm not sure, in my Ribbon UI, the Microsoft based Ribbon was taking a long time to relayout (was Ribbon issue, not WPF!) when there was another project (named Fluent) that it did not had this issue. I'm not a EverNote client, but I mean, people should be used to test the claims.
                C# appeared in 2001, Java in 1995, C++ 11 was finalized in 2011, pretty worthless comparison. Both C# and Java has had lots of time to make an impact on the end user desktop.
                As the answer was combined in part with Kraftmann, I noticed that a lot of .Net applications are not written in fully managed can be for historical reasons: the core was written (like in Office) years way before to worth the price to rewrite it in .Net. In fact this is basically the norm answer. Yet those packages noticed the performance and the capabilities that most enterprises use, so it offers the .Net backend.
                In fact I can argue that C++ is worthless anyway, because is not a part of Gnome's core (as Gnome 3) and is not a part of Linux kernel, and the only big application we write documents in it (LibreOffice) is too sluggish to think C++ as fast language.

                Comment


                • #28
                  Originally posted by ciplogic View Post
                  About unpackers, and such there are WPF/.Net applications that are good enough
                  It's up to the end user to decide what is 'good enough'. If I have two applications which offers me equivalent features and one is faster and uses less memory then I will use that one. I'd say this holds true for people in general.

                  Originally posted by ciplogic View Post
                  This is why the most people I know use Total Commander at home (written in Delphi, and 64 bit in Lazarus) even it unpacks slower than a C++ or C# version would do.
                  I've never used it myself nor do I know anyone who uses it, but from what I gather it calls external programs to pack/unpack archives, you know, those native code programs like rar, zip, 7z so why would it be slower? I could do the same in Python (run a gui and do all the heavy lifting using native code external programs) and it would be no slower or faster I bet. I could be wrong and that Total Commander actually implements all these archivers in delphi but I _seriously_ doubt it.

                  Originally posted by ciplogic View Post
                  In fact this is basically the norm answer. Yet those packages noticed the performance and the capabilities that most enterprises use, so it offers the .Net backend.
                  In fact I can argue that C++ is worthless anyway, because is not a part of Gnome's core (as Gnome 3) and is not a part of Linux kernel, and the only big application we write documents in it (LibreOffice) is too sluggish to think C++ as fast language.
                  I'm not really following this part of your post, I think it's the language barrier since neither of us are native english speakers, but Libre Office (formerly Open Office) has alot of Java code in it, and the rewriting of Java code into C++ was cited as part of huge speed increases for the 3.4 release and reducing the amount of Java code is a stated goal of Libre Office development.

                  Comment


                  • #29
                    Originally posted by XorEaxEax View Post
                    It's up to the end user to decide what is 'good enough'. If I have two applications which offers me equivalent features and one is faster and uses less memory then I will use that one. I'd say this holds true for people in general.
                    I've never used it myself nor do I know anyone who uses it, but from what I gather it calls external programs to pack/unpack archives, you know, those native code programs like rar, zip, 7z so why would it be slower? I could do the same in Python (run a gui and do all the heavy lifting using native code external programs) and it would be no slower or faster I bet. I could be wrong and that Total Commander actually implements all these archivers in delphi but I _seriously_ doubt it.
                    I'm not really following this part of your post, I think it's the language barrier since neither of us are native english speakers, but Libre Office (formerly Open Office) has alot of Java code in it, and the rewriting of Java code into C++ was cited as part of huge speed increases for the 3.4 release and reducing the amount of Java code is a stated goal of Libre Office development.
                    The "performance addicted" folks a lot of times they miss features and even if not so, their criterias do not apply for all people. Let's take some cases that are so often discussed here: Gimp vs Pinta (or Paint.Net). Gimp "feels" slower as Pinta uses all cores for most of operations. But Gimp users don't use Pinta because Gimp is a trusted project, supports much more file formats and more filters/better implemented features.
                    Let's take another so known debate here: GNote vs Tomboy. Feature by feature GNote is a Tomboy implementation, feels faster, runs faster, so why people still use Tomboy!? Maybe because some of original performance issues were addressed!? Or maybe because Tomboy added later the suport to synchronize notes online, or simply because is still installed by default in distributions.
                    And as much as people are comparing GNote with Tomboy, they don't accept for emotional reasons that Phalanger/.Net/JIT can be faster than their PHP/C++/Interpreted counterpart.
                    I use Fedora and I noticed at least in older versions (like Fedora 12 or so) that Yum was slow, it was python based and remained python based, and it did improve exactly as you said by profiling and changing firstly the algorithm of dependency solver, and later (probably) by using C where needed. I don't find any excuse why .Net world cannot do that. The single advantage over Python is that C# gives by default static type + JIT as running framework. I would argue with you if you make any C#/GTK# application you will not notice the difference compared with a C+Gtk+ in most cases.
                    LibreOffice/Java did like you do and most folks would do: try implement a feature first (so that's why Java was preferred over C++) and where performance may matter, it was rewritten having an working code. I don't know any obvious reason to not do this in any codebase. In fact the LibreOffice which is still a mix of C++ (mainly), Java and Python, does not explain why is so popular to AbiWord, when AbiWord is written just in lean C++ (maybe C) and Gtk, no other abstract UI (like LO's VCL) framework.

                    Side note: About TotalCommander, the Total Commander creator shared Delphi/FreePascal source code of zip pack/unpack as opensource and is a part of FreePascal opensource codebase. So I'm fairly sure of using Delphi/FreePascal as its extractor code.

                    Comment


                    • #30
                      VAAPI and XV video output

                      Finally, XV output is useful, no more tearing and rendering problem, but Vaapi became not supported on my UVD+ card...

                      Comment

                      Working...
                      X