Mono 2.10, Moonlight 4 Preview 1 Released

[Stewart]

What architecture, 32 bit or 64 bit, it is running? Thank you.

Both. In fact it is compilable with 32 and 64 bits.

[ciplogic]

I want to make some corrections and there is no EDIT option.
- my original post was about the fact that I cannot thing anyone undergoing a tedious work to improve the code for so long freezing the project. Performance or whatever gains may be substantive, but people want feature and bug fixes, not esoteric "under the hood" rewrites. Didn't you?
- second fix is that: I would use it with or without optimizations AmaroK anyway in KDE. Yet I said that as you will unlikely do it, I will unlikely use it, but as a person trying to keep my word, I will do it for sake of keeping my word. But as is hypothetical talk, is as hypothetical yes. I don't have an ideology of performance, but if a person will take a more than 1 human-year effort for showing that he lives for his values (in this case the "ultimate" optimization of memory, startup performance and so on), I will give a deep respect to him.
At the end I do think that the effort is meaningless, not because AmaroK would start faster or not, but because AmaroK is not a game engine that every frame per second matters. Would it take 0.5 seconds instead of 0.015 in some specific searches, great! But if the specific search is optimized with common sense optimizations, certainly can be achieved a 0.2 seconds, which may be a bit slow, but more than bearable for most people. And after a week of profiling the slow-down, you can implement another feature or fix another bug in AmaroK, not just trying to improve performance that already is good to start with.

[ciplogic]

Excluding the rest of the meaningless talk I wonder why wouldn't you use Amarok now, but after some optimization? It's already faster, uses less memory and it's much less fragile than banshee. It also doesn't depend on mono. Logic fail?

So let's agree to some things (philosophy):
- optimizations are not always what make world spinning. Probably you would accept that losing some performance may make sense sometimes. For example bash scripts or pythons are used in fast installers, and updaters.
- my overall experience was that I don't have crashes in either AmaroK or banshee, so "less fragile" is meaningless
- any "hello world" program depends on proprietary hardware (Intel, AMD, Via or whatever), compiler, libraries and OS. One dependency is your video driver or maybe proprietary blob that let your Wifi card to connect. Would you use the proprietary blob that does not disconnect or works right, or would you use Mesa/OSS stack for everything? And if you are the just Intel folks (like happen right now to be), still makes no sense what you are saying, as having "everithing" open will fail on hardware level
Let's go realistic: (your example)
- Banshee was stable in my experience as it was Amarok. The posted video that shows that AmaroK loads slower was not to blame AmaroK for speed, but to point the fact that people use qualifiers but don't use numbers. In the same way, you say the fragility or memory cases, really!? Did you posted bug report to prove that this opensource project use that much of memory? Let's imagine AmaroK: Qt GUI, SqlLite library that store your playlist, multiple views (that embed webkit browsers) in themselves occupy most of AmaroK memory usage. The AmaroK logic is basically meaningless in memory consumption and optimization. Banshee: Gtk GUI, SqlLite library, a bit fewer views (because the Banshee's "multi-view" UI is a but hard to navigate), and at the end the memory usage will be maybe a bit higher than the optimized AmaroK core, but overall the application (I expect) to use significantly less memory than AmaroK. In fact as for myself I don't care about memory, I have 8 G, and practically no netbook/laptop is given with less than 2 GB of memory.
- Mono dependency is like Qt or KdeLibs dependency. For me Qt dependency make me not to pick AmaroK in a gnome environment, but is understandable why. In a similar way, you as a KDE user, you may dislike to use Gnome and Banshee alike. The runtime that is "after the covers" it make matters meaningless, right, right? If Mono is evil in itself, people have to justify it why... is a theoretical threat, that is as hurtful as the possibility that a company like Microsoft will notice that antialiasing algorithms from Qt Arthur engine are a variation of ClearType used in Windows XP, so will try to block all Qt applications without a free. Is too fancy and would never happen!? Microsoft did Community Promise over projects like Mono but not over Qt, should we uninstall all Qt applications for that reason?
So kraftman, please start banshee in a Gnome environment (or Xfce one), start Amarok too, and compare memory usages. Then take some actions that you felt that are speed dependent and post some numbers (can be like: adding 1000 songs to library: Amarok: 3 seconds, Banshee 35 seconds). Or whatever post you think make things appear so bad by using Banshee. Maybe you were hit by a bug, maybe really Mono is too slow. Make a case for using C++/Qt as I don't see one. Maybe I was too blinded by Miguel.

[kraftman]

AmaroK will certainly will go faster if you will take its all code, look for all abstractions and write them without iterators, without collections, databases, using raw code. Instead parsing xml files, you will have to set a binary packaged format, that is binary efficient (can be LZ compressed) so people with slow disks will get it running faster. Another area you can improve, is to make all plugins part of AmaroC inside application, no memory mapping at startup, no wasted memory. At the end, to be lightning fast, you will have to rewrite all SqlLite database code to an optimized C, and for slow areas, look to generated assembly code (use for Gcc the -s flag) and try to find a reduced form for them. In this way, (no joke intended) AmaroC may start 2-3 times faster than Banshee (for the same library size), it may be running around 4-5 times faster, if not more, in searching in the music library and so on.
As you know and have all tools to optimize, I guarantee to you, even AmaroK is a big project, in two years time, you can do it! I will install it as a default player if you will do it. Will you do it? I would love to write to you bug reports (sarcastic).
Do you feel right to that? Or you think is worthless?

Excluding the rest of the meaningless talk I wonder why wouldn't you use Amarok now, but after some optimization? It's already faster, uses less memory and it's much less fragile than banshee. It also doesn't depend on mono. Logic fail?

[Ulrike]

Mono is free licensed, please hear here why: http://apebox.org/wordpress/linux/374/

What architecture, 32 bit or 64 bit, it is running? Thank you.

[bruimi]

Mono 2 10 Moonlight 4 Preview 1 Released

Panned mono and stereo are not the same thing.

I could write a page or two on the differences but the best way is to do an actual stereo recording and compare the two.

[ciplogic]

Mono is free licensed, please hear here why: http://apebox.org/wordpress/linux/374/

[ciplogic]

Nobody proved AmaroK written in C will start faster - as you mentioned database can affect the player performance and who knows if it doesn't affect AmaroK startup time? Not some RAM, but quite a lot of RAM and not one second, but more. Btw. you won't support M$ too and this is the big WIN.

Look again here, if you skipped this: http://www.youtube.com/watch?v=cH-VrnIV-rs
We talk about 40% startup time, and is about C++ that starts slower than C#/Mono that the former is slow in your eyes.
FYI I will explain why in some way Mono fared well and why startup time is worse in AmaroK than in Mono, etc.
First of all, excluding your fully biased way, C#/Mono, and in general any language that support JIT will fare well in a math intensive benchmark. Java already prove it, etc. Try to run Eclipse with big codebases and try to use KDevelop or Anjuta (I did never use QtCreator for those). You will see that Eclipse even is written in Java, works better than their C++/C siblings (at least KDev and Anjuta) in all cases I do know. You will get probably misquote me out of context, but the reason that Eclipse is better for scaling in big codebases is that is well written, is not (necessarily) that C++ or C may get (or not) good performance.
In general any abstraction will give an overhead, and I will point some that you met: libSO/DLL memory mapping, files on disk written in a format more or less human readable (like Xml) instead binary ones (that avoid big disk accesses), plugins (as the application have to read, parse, validate, map functionality in application logic) and virtual calls (also named in language agnostic way: late binding).
C programs in general are written with less virtual calls, because is a bit awkward to write virtual calls (meaning pointer to a function) and when is done, so in raw performance, most likely (excluding you talk about scientific code where pointer aliasing matter, so you will write this code either in Fortran or in Java, maybe C, but never C++) will bring the raw performance.
The benchmarks where Mono "won" in front of C++ "paradigms" were that the C like coding will give less overhead. Anyway, as C++ give an overhead (raw number performance), the same Mono (depending how you write code) you will have abstraction penalty like bounds-checking (the most common issue) or boxing/unboxing.
So for certain a C style like coding of AmaroK will bring better performance, as code will be written in an efficient style.
Database code is a different issue, and you get it again (and it seem that at _every_ post you get a logical fallacy, yet facts wrong etc), and is just after your application start.
Let me explain: when your music library player start and its frameworks will start (I think both AmaroK and Banshee, I can say for certain in case of Banshee, but I think is the same for Amarok) a mini database (SqlLite) and will read and filter music library information using it. Firefox use it too (to search in history or when you search in bookmarks). The reason is that many common cases (like filtering through some criteria) are much easier to be understood and to be worked with than to be rewritten in C/C++/C# whatever to get a filtering for a criteria (i.e. filtering 5 star songs).
This makes that SqlLite (as startup time) to be the same for AmaroK and Banshee. Also performance wise, both AmaroK and Banshee SqlLite Selects & co code will get lower runtime performance than "native" Mono/C/C++ for filtering, but the code will be well written, is already tested, and so on.
This is why it makes no sense to rewrite an application (probably you are still sticking in your mind with GNote): there are many ways to reduce startup time. I've did it for my .Net/Win only project. Literally it goes down from around 10 seconds (around 1 year ago) to around 3.5. The JIT time goes from 5 to 6 seconds to 0.2 -0.3 (so application starts the same things). Is just about profiling and setting bugs down.
AmaroK will certainly will go faster if you will take its all code, look for all abstractions and write them without iterators, without collections, databases, using raw code. Instead parsing xml files, you will have to set a binary packaged format, that is binary efficient (can be LZ compressed) so people with slow disks will get it running faster. Another area you can improve, is to make all plugins part of AmaroC inside application, no memory mapping at startup, no wasted memory. At the end, to be lightning fast, you will have to rewrite all SqlLite database code to an optimized C, and for slow areas, look to generated assembly code (use for Gcc the -s flag) and try to find a reduced form for them. In this way, (no joke intended) AmaroC may start 2-3 times faster than Banshee (for the same library size), it may be running around 4-5 times faster, if not more, in searching in the music library and so on.
As you know and have all tools to optimize, I guarantee to you, even AmaroK is a big project, in two years time, you can do it! I will install it as a default player if you will do it. Will you do it? I would love to write to you bug reports (sarcastic).
Do you feel right to that? Or you think is worthless?

[kraftman]

Yes, but AmaroK does not, why not rewrite AmaroK in C? At least to start in similar times as Banshee?
This is what is about, if you are pleased (as I am for myself for Mono apps that I use) I see no point to rewrite them just to win theoretically (or practically sometimes) some RAM or 1 second at startup as other issues are more important.

Nobody proved AmaroK written in C will start faster - as you mentioned database can affect the player performance and who knows if it doesn't affect AmaroK startup time? Not some RAM, but quite a lot of RAM and not one second, but more. Btw. you won't support M$ too and this is the big WIN.

[ciplogic]

I wouldn't rewrite Vala application like Shotwell, because unlike F-spot, I found it to be very responsive and starting very fast.

Yes, but AmaroK does not, why not rewrite AmaroK in C? At least to start in similar times as Banshee?
This is what is about, if you are pleased (as I am for myself for Mono apps that I use) I see no point to rewrite them just to win theoretically (or practically sometimes) some RAM or 1 second at startup as other issues are more important.