No alternative for F-spot?

Posted Jul 2, 2009 11:43 UTC (Thu) by MathFox (guest, #6104)
In reply to: No alternative for F-spot? by MisterIO
Parent article: Stallman warns about C# and Mono dependence

My problem with both java and dotnet is that their runtime environments are memory hogs. On a recent machine one has some memory to spare, but even with 2 GB RAM it is not unusual to see swap space used. On smaller machines you want to avoid both the JVM and Mono, but if you have room for only one, a JVM is much better than Mono. There are far more Linux compatible Open Source java applications than dotnet applications. (Even without the patent threat hanging over Mono's head.)

For me it is not a programming language issue, but a runtime resource usage issue.

No alternative for F-spot?

Posted Jul 2, 2009 15:50 UTC (Thu) by alankila (guest, #47141) [Link] (14 responses)

Head to head, mono appears to have much smaller memory requirements to JVM. This can be discerned from the "Computer language benchmarks game" at alioth.

This is important because every application has a distinct heap of memory that it uses for whatever purpose, but there is no possibility of sharing this area of memory because every application always starts from scratch.

Assuming there's any degree of accuracy on these numbers, Mono wins JVM by a factor of 2-3.

Resource hogs

Posted Jul 2, 2009 18:32 UTC (Thu) by ncm (guest, #165) [Link] (12 responses)

Question: Which is worse, Transformers 2 or Gigli?
Answer: Both.

It's pointless to compare a JVM's resource usage to that of the Mono runtime. Both are indefensibly awful. It's partly a consequence of a stupid runtime design -- why defer compilation to runtime, when you can compile directly to machine code once? But it's as largely attributable to unavoidable dependence on garbage collection, leading ineluctably to pervasive memory leaks. In other words, they don't bother compiling to machine code because it doesn't help much anyway.

Mono and Java defenders often point out that Python can be a thousand times slower than Mono or Java. That Python programs are often preferable to either, anyway, indicts both.

Resource hogs

Posted Jul 2, 2009 20:46 UTC (Thu) by nix (subscriber, #2304) [Link]

Well, deferring compilation to runtime *can* be useful: you can hunt for
optimization opportunities given the code's *current* workload, which is
something a static in-advance compiler would have no hope of doing.

Resource hogs

Posted Jul 2, 2009 21:37 UTC (Thu) by epa (subscriber, #39769) [Link] (2 responses)

You do realize that Python also compiles to bytecode and has an 'unavoidable dependence' on garbage collection?

Resource hogs

Posted Jul 3, 2009 5:04 UTC (Fri) by ncm (guest, #165) [Link]

The tolerable Python programs I have run used reference-counting, underneath. Maybe Python 3 runtimes use deferred GC. If they do, we might begin to see Java- and C#-like memory usage characteristics.

Python gc is avoidable

Posted Jul 3, 2009 7:24 UTC (Fri) by xoddam (subscriber, #2322) [Link]

From http://docs.python.org/library/gc.html :

"Since the collector supplements the reference counting already used in Python, you can disable the collector if you are sure your program does not create reference cycles. Automatic collection can be disabled by calling gc.disable()."

Resource hogs

Posted Jul 3, 2009 17:09 UTC (Fri) by alankila (guest, #47141) [Link] (7 responses)

"Why defer compilation to runtime"? You are incorrect in assuming that it isn't compiled. The language is compiled to a bytecode. The reason to do this is to achieve a degree of hardware independency. If that is unimportant, Mono can compile C# to native code, and gcj can be used to compile Java to native code. I imagine Mono works better in this than GCJ, as my experiences with GCJ have been quite poor overall.

Your concept of garbage collection and its "pervasive memory leaks" is bizarre. I don't even attempt to figure out what you can possibly mean by this.

Resource hogs

Posted Jul 3, 2009 20:24 UTC (Fri) by nix (subscriber, #2304) [Link] (6 responses)

There are two problems that I know of with languages supporting GC.

Firstly --- and this is more a problem with stupid programmers, but a
pervasive one --- programmers tend to think "ooh, GC, now I don't need to
worry about resource leaks". And then they go on and leak all sorts of
non-memory resources, many of which have memory tied to them.

Secondly, GC can often ruin data locality, smashing the dcache badly.
(This is a major, perhaps *the* major, reason for the large slowdown in
GCC around version 3.0. Cache misses up the wazoo.)

Resource hogs

Posted Jul 4, 2009 1:32 UTC (Sat) by alankila (guest, #47141) [Link] (5 responses)

Perhaps the GC is not explained well enough, if it leads to people assuming that they can just forget about disposing resources in a timely fashion.

I have actually seen this antipattern in my old working place: a web application that didn't quite work and they had to restart the program whenever customers reported that it was stuck again. The application was ported from Perl with people assuming similar semantics (predictable destructor calls at end of block), and none of the database handles were closed properly, leaving read locks behind.

The locality issue is harder to tackle in any meaningful way. In principle the GC could be informed about desired locality patterns by some kind of sampling algorithm that records recently used objects, and then moves them as close to each other as possible during the next major GC cycle. I don't think anyone does this in practice, though.

Still, VM people are fond to argue that having a VM abstraction allows doing just this kind of weird optimizing like moving objects around in memory in response to runtime demands. Perhaps JVM could beat C one day if all imaginable tricks were pulled...

Resource hogs

Posted Jul 4, 2009 5:14 UTC (Sat) by ncm (guest, #165) [Link] (4 responses)

People have been talking about stuff like this for going on fifty years. If it worked, it would be everywhere by now. Various such tricks have been implemented here and there. The code washes away, every time, and takes the tricks with it. Nobody has ever implemented many of the tricks in one place. You never get real-time, incremental, compacting, generational, thread-safe, multi-CPU cache-efficient GC all in one place in a runtime you actually get to use. Many potentially helpful techniques are incompatible with calling essential C libraries, so they'll never show up in a JVM or CLI.

Resource hogs

Posted Jul 4, 2009 7:41 UTC (Sat) by njs (subscriber, #40338) [Link] (3 responses)

I'm not sure what "cache-efficient" ends up meaning for a garbage collector (e.g., which is better -- mark-sweep with its big reads, or reference counting with its scattered writes?), but AFAICT pretty much all the rest of those are common in the Java world at this point. Many, many person-years have gone GC's in recent years. For instance, here's a paper on the latest (still beta?) Sun GC called G1.

That said, I agree it's annoying how popular the idea is that deferred GC is the *only* memory management technique one would ever need or want. Also, determinism is awesome. But OTOH, a lot of the programs being written in GC environments are ones where the authors would never get the memory management right anyway.

None of which has anything to do with Seattleites bearing gifts.

Resource hogs

Posted Jul 4, 2009 7:43 UTC (Sat) by njs (subscriber, #40338) [Link] (2 responses)

Err, Redmondites. WTF, brain. I guess they're nearby.

Resource hogs

Posted Jul 6, 2009 19:00 UTC (Mon) by ncm (guest, #165) [Link] (1 responses)

They work in Redmond, but they live in Seattle.

Resource hogs

Posted Jul 8, 2009 6:19 UTC (Wed) by deunan_knute (guest, #290) [Link]

I wonder how true that is nowadays. The East side is quite well-developed now, and the commute across the 520 bridge is just awful (i should know, i make it every day). Even so, i see more and more of those Microsoft commuter vans...

Language shootout

Posted Jul 9, 2009 8:24 UTC (Thu) by ketilmalde (guest, #18719) [Link]

Anybody else take issue with the technical merits for C# presented? From the Language Shootout, I just don't think they hold water.

The results are graphed here:

http://gmarceau.qc.ca/blog/2009/05/speed-size-and-dependa...

From this, the ideal seems to be OCaml, which is consistenly good both in code size and speed, but plain C seems to beat C# soundly.