Phalanger: Stuffing PHP With Mono, .NET

[XorEaxEax]

The "performance addicted" folks a lot of times they miss features and even if not so, their criterias do not apply for all people.

Well like I said my first criteria is that applications must have the features I require, if there's only one application supplying those features then it's obviously the one I go with, if there are several available I will go with the one which is performs better. Choosing something because it's slower and uses more memory than equivalent options would make little sense to me.

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.

I don't know, I don't use either. Maybe there are some features Tomboy has which are not available in GNote, or in this case the differences in resource usage is very small as note apps aren't really demanding (although needing to launch a VM for a note taking app seems like overkill to me).

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'm merely stating that native code is faster and less memory demanding than equivalent managed code, and it's not for emotional reasons.

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.

Well of course you can do that but it seems again like overkill to depend on the .Net framework for something you could just as easily use Python for. The heavy lifting will still be done in C for both these suggested solutions, and the non-performance dependant stuff can just as easily be done in Python and avoid the much larger C# VM/.Net framework dependancy.

This is how much of the foss world desktop solutions looks these days, with Python for non-performance dependant 'glue' code which calls high performant C/C++ code where needed. I fail to see what there is to gain by exchanging Python with C# for the non-performant code?

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.

That's easy, Abiword is nowhere near LibreOffice in term of features as it is only a word processor while LibreOffice is an entire office suite, also Microsoft Office which is the most used 'office' application in the world is written in C++, Apple's counterpart IWork is written in ObjC. That said I'm not saying that an Office Suite is something that is outside the performance scope of managed code, actually I'd say this is the type of application which would be tailored for managed code as it's not particularly performance dependant and often has huge and complex codebases where memory leaks are more likely to occur.

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.

I suppose that there's delphi code to pack/unpack zip as it is such an old and well-known format, I doubt there's delphi code for all the other archivers in heavy use out there like rar, 7z, gzip, bzip, etc but again I may very well be wrong since I really have no insight on delphi. Also I'm a bit confounded on you bringing Total Commander up in this discussion as I was under the impression that it was a native code application, or?

Anyway, native code is here to stay and so is managed code. On the end user desktop managed code has failed to make an impact, likely due to end users preferring native code alternatives where available due to the increased resource usage of managed code applications. Meanwhile managed code solutions like Java and C# are strong on in the enterprise sector where ease and speed of development trumps pretty much all other aspects. Then we have new languages coming out like Go, which offers native code but with automatic garbage collecting and built-in language properties for concurrent programming which may find presence on the desktop once it matures (or atleast reaches version 1).

As always, code talks, bullshit walks. The success or failures of the respective language solutions out there depends entirely on code being written in them and how/if that code is recieved and utilized, and my opinions just like anyone else's are just that, opinions.

[ciplogic]

I don't know, I don't use either. Maybe there are some features Tomboy has which are not available in GNote, or in this case the differences in resource usage is very small as note apps aren't really demanding (although needing to launch a VM for a note taking app seems like overkill to me).
I'm merely stating that native code is faster and less memory demanding than equivalent managed code, and it's not for emotional reasons.

Python is a VM too (even it doesn't have a JIT compiler), and the argument of using/not using a technology is easier when is already preinstalled. And the argument may be the same to every software package: to run in "..." instead of plain C is overkill.
I think we all agree that native code is faster and a lot of times consumes less memory. Yet it does not make it faster as implementation goes. An easy to test part: JRuby is faster than Ruby 1.9 which have a JIT by a small margin and much more 1.8, Jython/IronPython are faster the reference implementation. If you want to dynamically add some functionality in C world (C++) you have two major options easy to integrate: add Lua, or use dynamic libraries, which have to expose C functionality to be standard. Lua is easy to interpret and small memory footprint, libraries are hard to debug and sometimes not as flexible if you want to change just some aspects of your program and you want to iterate. Is much faster to do it using .Net's reflection or use a Mono framework like AddIn. And when you add this library, it will not add any performance impact.
Another feature that JITs have an edge is when you want to generate compiled code at runtime (Phalanger). You can as you have all exposed. Let's say 2x slower than optimized C, but many times than an optimized C interpreter. Here is 1 page of code of generated Boo code that can evaluate as easy or as complex expressions as Boo language can support at runtime.
Where you use this in normal applications!? Rarely, but you have a lot of functionality to start from, a lot of paradigms and languages. I noticed that you like Python, so you may give Boo a shot (is static typed Python, with option to use dynamic constructs, and you will notice about its performance is like Python + Cython that is written freely).

[XorEaxEax]

Python is a VM too (even it doesn't have a JIT compiler), and the argument of using/not using a technology is easier when is already preinstalled.

Yes you are right it is running in a VM which I sometimes forget due to it's interpreted/dynamic nature. And yes while Python isn't preinstalled on my distro of choice (Arch) I'd say it's pretty much standard on the linux platform which certainly helps with it's popularity compared to similarly featured languages.

Lua is easy to interpret and small memory footprint, libraries are hard to debug and sometimes not as flexible if you want to change just some aspects of your program and you want to iterate. Is much faster to do it using .Net's reflection or use a Mono framework like AddIn. And when you add this library, it will not add any performance impact.

Not really following this... sorry.

Rarely, but you have a lot of functionality to start from, a lot of paradigms and languages. I noticed that you like Python, so you may give Boo a shot (is static typed Python, with option to use dynamic constructs, and you will notice about its performance is like Python + Cython that is written freely).

Yes I read about it back when I came across it as one of the scripting languages supported by Unity, seems nice enough but I am very lazy when it comes to picking up new languages outside of what I need for work. I've promised myself to give Go a serious shot once it stabilizes (and I come up with a project fun enough to spend my spare time on, preferably something I can drag some coworkers in to).

[ciplogic]

Not really following this... sorry.

The point was that as platforms that work with generated runtime code, most of JITs add (plugin like) functionality with lower performance penalty. Most JITs are better in doing inlinging, type specialization (because you declare an interface in your application, and the specialized code is in your specific platform implementation) calls and like. If you have constants for example, they may be inlined back by the JIT without having to consider a DLL or a Lua script boundaries. I am not here to teach Carmack how to make software, and he states a thing that I was witnessing in my team for some years: static code analysis is a must for big codebases, quality over performance is a better long-term goal to be had, and he said the problems that he had here and there. He also complained about performance of interpreted languages (he said about QuakeC which as the custom code grew, it made really hard for his team to improve it to a level that is desirable performance for games). If he would have available a JIT (not necessarily Mono, but at least something like LuaJIT) instead of QuakeC, maybe his complains were not so vocal in this year, and it would give just the right balance for most of heavy lifting. As quakeC was a 15 years old project, it was even too early for Java to be used, and even it was used, there was practically just one JIT (Symantec one) and it was really to low quality for gaming standards, and in 1997 it was just launched Pentium 2 and Pentium MMX was really the best someone could hope. Today I think we live different times.
Disclaimer, I don't work in game industry, so maybe some performance conscious people will correct my mistakes (I work in somewhat performance sensitive codebases, and even so, my code is not that fast, but is I hope fast-enough).

[migueldeicaza]

Who's funding you, Icaza? Why do you keep working on project which is already dead on Linux?

MonoTouch and MonoDroid customers are.

You can check our products here:

http://xamarin.com

As for Phalanger, that is being done by a separate team of passionate developers that love PHP and love that they can run faster while not compromising any of the PHP features like Facebook's HipHop compiler has to. Bonus point for the guys running on Mono in addition to .NET.