Slashdot Mirror

FYI, Iceweasel is at 3.5.1-1 in experimental.

To me, tapes have ALWAYS been a reliable tangible fashion to back ....... server/OS content and get it back, reliably.

I don't backup binaries.

What good is a backup of /bin/ls from my current AMD64 server, if I need to restore to non AMD64, perhaps intel ia64 or i386 hardware?

Of if my powerpc desktop running debian croaks and I find an i386 as a cheap replacement?

I also have an ARM arch debian machine in the basement somewhere.

Can my backup plan for /bin/ls really do a better job than Debian's four hundred and nineteen world wide binary mirrors?

http://www.debian.org/mirror/list

How generous. As I really won't need Helvetica privately and have licensed access to it at work, please choose a charitable organization of your liking, maybe the FSF, Debian, or Médecins Sans Frontières :)

How about Debian, which automatically includes dpkg, aptitude and synaptic?

From my experience it would take care of most aything.

And with a good admin, even more.

.

> great idea , now how about renameing linux next , seriously...

Idea! Let's call it GNU/Linux.

> how conceded do you have to be to name a os after your self??

Dunno but it seems to work well

I believe the version of Eclipse in Debian and Ubuntu is so far behind because the packagers haven't been able to produce a package of newer versions that runs using the GCJ native compiler, and they don't want to ship a version that uses the regular JVM. Why they would rather ship an ancient version of eclipse, than ship a java program that uses the JVM, I do not know.

This is doubly ridiculous when you realize that the Sun JDK is no longer in non-free... as openjdk-6-jdk.

What Debian distribution is he using? Even Debian Lenny (the current stable) uses 3.2!

The *only* weak point? When did Java get anything that works at all like a function pointer (delegates)?

Java does not have them because it enforces object-oriented code design. Which will make any project bigger than a VB form much easier to understand and maintain.
Their equivalents are anonymous inner classes. They're equivalently ugly, too.

When did it get unsigned integer types (uint16/32/64)?

Java explicitly left them out because they're not usually needed and make the arithmetic rules much more complicated. If you want a bigger integer, use a wider one, don't rely on the sign bit to carry information for you.
Just knowing that unsigned types exist, but ignoring the intricacies of the rules that their existence implies, will lead to more bugs in software, which is what Java tries to avoid.

When did it get stack-allocated pass-by-reference data types (structs)?

A "struct" is a class without methods. There's no need to complicate and uglify the language by adding second-citizenship classes. One of the core points in Java is that the programmer needs not to be aware of how the objects he uses are allocated (stack? Heap? A programmer shouldn't worry about the architecture of the VM). The only reason to use them would be *performance*, but Java happens to be more than three times faster than Mono with its current design, so if you really care about performance, you should switch to Java without even thinking about stack and heap considerations.

Then there's all the unsafe stuff that C# supports and Java doesn't, although in my years with both languages I've very rarely felt a need for any of that, and never actually used it. Would amke porting C/C++ to C# a lot easier than porting to Java, though...

The whole "unsafe" concept is crap. It breaks every advantage of using a VM. Unsafe code can’t be trusted, so it relies on the underlying operating system for protection, and badly-written unsafe code can trigger bugs everywhere, even in the "safe" code that is using it. It even breaks some assumptions which can be used to improve the performance of the VM.
That's why "unsafe" code cannot be run by default on .NET. Only signed applications can use it (as it happens with JNI in Java).
"Unsafe" was only added to .NET to support the abomination called "managed C++", which was fortunately rejected by developers even though MS silently made it the default option for "C++" projects in Visual Studio.
You even say that you never used it, so I really don't see your point, should a language implement every possible feature, even an unuseful and harmful one like "unsafe", just for the sake of it?
To interoperate C++ code with Java, we have JNI, which in the end serves exactly the same purposes of "unsafe", but without masquerading dangerous, potentially buggy code as safe, managed code.

Let's not forget LINQ though, that's actually well-worth mentioning. Any equivalent in Java yet?

Not having this feature does not prevent Java to be the vastly preferred choice in the enterprise world, where C# has a very low adoption rate.
Evidently many people who actually work with enterprise software do not really care about it.

However there is a proposal to make mono part of the default installation of both Debian and Ubuntu in their next releases.

(Official) citation please, especially for the Debian claim.

I think you completely misunderestimate the Debian package priority structure.
see: http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html#s-priority

For example less is a good example of a standard priority package in Debian. While gcc and the previously mentioned X.org are both at the Optional level.

A library which is only used by non-system apps is not going to be part of the core installation any time soon, sorry.

However there is a proposal to make mono part of the default installation of both Debian and Ubuntu in their next releases.

(Official) citation please, especially for the Debian claim.

I think you completely misunderestimate the Debian package priority structure.
see: http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html#s-priority

For example less is a good example of a standard priority package in Debian. While gcc and the previously mentioned X.org are both at the Optional level.

A library which is only used by non-system apps is not going to be part of the core installation any time soon, sorry.

However there is a proposal to make mono part of the default installation of both Debian and Ubuntu in their next releases.

(Official) citation please, especially for the Debian claim.

I think you completely misunderestimate the Debian package priority structure.
see: http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html#s-priority

For example less is a good example of a standard priority package in Debian. While gcc and the previously mentioned X.org are both at the Optional level.

A library which is only used by non-system apps is not going to be part of the core installation any time soon, sorry.

I would like it if in Debian-like linux distro's, mono can be easily uninstalled (which also un-installs all "dependent" packages (programs and libraries)). This means that if I've installed your apps, and if (for whatever reason) I decide to purge mono from my system, that I would have to give up using your apps, too.
So far, so good. My personal gripe is if important packages (Debian version of openoffice.org 3.1.0-5) that everyone uses are dependent on mono.
Do you happen to be one of the developers of openoffice.org?
On the bjorn.haxx.se site describing when packages go into testing, there seems to be somewhere a "Build-Depends:" of the openoffice.org package on mono, which is why openoffice 3.1 is currently not yet in Debian testing.
Before you flame me, I know that this doesn't mean that all openoffice.org programs actually depend on mono, it's probably only for cli-uno-bridge, but I would strongly prefer an openoffice.org NOT dependent on mono, and then if necessary, an openoffice.org-extras-mono package containing those parts dependent on mono.
I haven't yet had time to open a wishlist bug against openoffice.org. Sorry.

Don't get angry, get even.

Here's the home page of the Debian Mono project with links to the various projects and the names of the dirty dozen (Ok, there's more than a dozen but artistic license and all that...) who are responsible for the push to get Microsoft technologies into Debian.

The current developers are:
Mirco Bauer (meebey)
Sebastian DrÃge (slomo)
Jo Shields (directhex)
David Paleino (hanska)

Let them know what you think. Let the Debain project as a whole know too. Maybe consider joining the project to have a say in the decisions. I'm sure Microsoft has already done that. Why not you too?

That's a collection of shell scripts around the free software Ksplice tool that merely automates the task of downloading the Fedora kernel. (The Ksplice software has been released for over a year, and is also packaged in Ubuntu and in Debian, although the ksplice.com apt repo has newer versions.) Ksplice's Uptrack service is a way to automatically apply Ksplice updates that have been vetted for safety by the Ksplice developers, which is a much more convenient thing unless you like reading every kernel patch daily and testing the resulting Ksplice patch yourself.

I'm hardly an idiot. If I could find an open source software package capable of doing what I require, I would have gone that way a long time ago. As it stands, I have to use a proprietary software package that does not allow me to weight the incoming emails based of *any* RBL's. I can only refuse the connection based on the RBL's.

You're kidding right? What (where) is your skill set? Build a Linux or FreeBSD smart host box with Postfix and SpamAssassin. Then relay the scrubbed mail stream to your current mail server. You can block outright based on dnsbl hits within Postfix, or you can score based on dnsbl hits in SpamAssassin.

Here's a decent head start:
http://www.debian.org/
http://wiki.debian.org/Postfix
http://www.debianhelp.co.uk/spam.htm
http://wiki.apache.org/spamassassin/DnsBlocklists

If you're currently running Exchange, all you have to do is tell Postfix to relay all inbound mail to the IP address of your Exch server. For example, in main.cf you'd have:

relayhost = 10.3.2.1

To get Postfix to accept mail for your users, you can either have Postfix poll your AD server for valid user addresses, or you can just manually type them into a relay_recipients file, if you're a small organization, say 100 users or less. The manual thing gets really tedious for larger user counts.

It's a fantastic anti spam solution. If you're not a sysadmin type and don't know anything about dns and changing MX IPs in your dns server or getting your provider to do it, you may not want to take this plunge. You've got to have some decent networking background, including configuring dns entries on your authoritative server.

I'm hardly an idiot. If I could find an open source software package capable of doing what I require, I would have gone that way a long time ago. As it stands, I have to use a proprietary software package that does not allow me to weight the incoming emails based of *any* RBL's. I can only refuse the connection based on the RBL's.

You're kidding right? What (where) is your skill set? Build a Linux or FreeBSD smart host box with Postfix and SpamAssassin. Then relay the scrubbed mail stream to your current mail server. You can block outright based on dnsbl hits within Postfix, or you can score based on dnsbl hits in SpamAssassin.

Here's a decent head start:
http://www.debian.org/
http://wiki.debian.org/Postfix
http://www.debianhelp.co.uk/spam.htm
http://wiki.apache.org/spamassassin/DnsBlocklists

If you're currently running Exchange, all you have to do is tell Postfix to relay all inbound mail to the IP address of your Exch server. For example, in main.cf you'd have:

relayhost = 10.3.2.1

To get Postfix to accept mail for your users, you can either have Postfix poll your AD server for valid user addresses, or you can just manually type them into a relay_recipients file, if you're a small organization, say 100 users or less. The manual thing gets really tedious for larger user counts.

It's a fantastic anti spam solution. If you're not a sysadmin type and don't know anything about dns and changing MX IPs in your dns server or getting your provider to do it, you may not want to take this plunge. You've got to have some decent networking background, including configuring dns entries on your authoritative server.

I stalk..er find women here.

http://women.debian.org/profiles/

PS. It's legit.

It's the last version, but it is in sid (I am on amd64)

$ apt-cache policy alien-arena
alien-arena:
    Installed: (none)
    Candidate: 7.0-1
    Version table:
          7.0-1 0
                500 http://ftp.de.debian.org/ sid/contrib Packages

Oh, no, if the apps weren't in Java they wouldn't be portable. Unlike say Debian's 25113 packages -- the vast majority of which are not Java or .NET-based -- which run just fine on ARM and MIPS and, well, pretty much anything else you can think of. If Google wants to make sure apps are portable, they should tell the devs to not be stupid, not force them to use Java or .NET. (Personally I think using managed languages like Java or .NET (or Python or pretty much anything except C/C++) is in general a great idea because it helps avoid certain classes of bugs, but really, the devs should be allowed to use whatever language they want.)

Oh, no, if the apps weren't in Java they wouldn't be portable. Unlike say Debian's 25113 packages -- the vast majority of which are not Java or .NET-based -- which run just fine on ARM and MIPS and, well, pretty much anything else you can think of. If Google wants to make sure apps are portable, they should tell the devs to not be stupid, not force them to use Java or .NET. (Personally I think using managed languages like Java or .NET (or Python or pretty much anything except C/C++) is in general a great idea because it helps avoid certain classes of bugs, but really, the devs should be allowed to use whatever language they want.)

This Mono encumberance spreads via dependencies. Installing GNOME or certain GTK apps without any Mono dependencies is extremely difficult. Even more so when these packages and dependencies are tested and become part of stable, yielding silly situations, like when 'bootsplash' is replaced with 'splashy', which requires the 'gnome-desktop-environment' meta-package, 'gnome-desktop', 'cheese', etc.

From what I've seen and read, the dependencies in Debian are being swept in as a means to resolve inter-package dependencies within Debian. It's GNOME and subcomponents, and some tertiary apps that require Mono, but oversight in keeping barriers between 'default' and 'encumbered' is falling short, despite claims to the contrary:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=473118

"This is why gnome-desktop-environment doesn't depend on it despite being
part of the official GNOME desktop.

The gnome metapackage is here to bring a full-fledged desktop with all
the bling. If you don't want everything, you should install
gnome-desktop-environment and pick other stuff depending on your choice."

As it happens in some other distributions - SUSE, for instance, the dependency web is such that basic GNOME components have a cross-dependency with Tomboy, and as GNOME is headed by Mono-centric developers, it's to be expected that the interoperability of GNOME components will continue to depend on Mono. Evolution, Tomboy, Beagle, will each require similar effort as has been put into Gnote, and similar vigilance in assuring compatibility.

http://svn.debian.org/viewsvn/pkg-gnome/desktop/unstable/meta-gnome2/debian/control?revision=20303&view=markup

"Depends: gnome-desktop-environment (= ${source:Version}),
                  gdm-themes,
                  gnome-themes-extras,
                  gnome-games (>= 1:2.24.3),
                  libpam-gnome-keyring (>= 2.24.1),
                  gstreamer0.10-plugins-ugly (>= 0.10.10),
                  gstreamer0.10-ffmpeg (>= 0.10.6),
                  rhythmbox (>= 0.12),
                  synaptic (>= 0.62),
                  system-config-printer (>= 1.0.0),
                  totem-mozilla,
                  swfdec-mozilla,
                  epiphany-extensions,
                  gedit-plugins,
                  evolution-plugins (>= 2.24.3),
                  evolution-exchange (>= 2.24.3),
                  evolution-webcal (>= 2.24.0),
                  serpentine,
                  gnome-app-install,
                  transmission-gtk,
                  bluez-gnome,
                  arj,
                  avahi-daemon,
                  tomboy (>= 0.12.2) | gnote,"

note: tomboy (>= 0.12.2) | gnote

In plain English that means tomboy *or* gnote.

It's Debian, you have a choice.

Debian also offers an Xfce/LXDE version of CD1 and a KDE version of CD1, CD1 being the installer. Neither of these offer mono or Gnome (duh!). Debian also offers fine grained package selection in all the installers, and a netinstall and a tiny netinstall, the businesscard iso. There is also the DVD installer which offers a choice of desktop environments along with the usual options for fine grained selection of packages, the 'Expert Install' option.

So *one* of the numerous ways of installing Debian *may* offer Tomboy to those who want it. Cue howls of intolerant, ill-informed, unsubstantiated quasi-religious outrage.....

And anyway mono is accepted as free software by the two bodies which are best placed to determine its status, the FSF and the OSI (and Debian Legal as well). Their legal teams have somehow failed to persuaded by psychotic ravings and are obstinately insistent in assessing these things by means of reason, facts, law and other little know methods. How churlish.

On the other hand it might be a far reaching conspiracy and have something to do with the Kennedy assassination, 9/11 and Roswell.

Perhaps Debian doesn't believe that Microsoft might do something like Rambus did.

Rambus was chastised for their actions (like the linked article states). And I propose Debian approach this the same way someone would approach the Rambus situation from the beginning had they an inkling of Rambus' true intent.

Even though Microsoft submitted the CLI and C# main components of .NET, MIcrosoft does hold at least one patent on the .NET infrastructure. So far, Microsoft has agred to offer these under a "reasonable and non-discriminatory (RAND) terms of use" and they are currently royalty free. No one seems to be clear on how you get this into writing but it's allegedly the way things are.

Were I a Debian leader, I would simply approach Microsoft with the Mono code and the ECMA code of conduct and demand it in writing that for this snapshot of the code you have a forever royalty free to interact with .NET. Should they fail to comply with this request in a timely manner, I would submit all communications with Microsoft to ECMA in a motion to dismiss the aforementioned "standards" and remove Mono--and unfortunately Tomboy--from the Debian default package. I'd beef up the Debian wiki with details on how to get these two packages to fix this bug and focus on the bug for a near future release after Squeeze.

At that point, sit back and let ECMA and the community at large hash it out with Microsoft. Better now than later when other things may depend on this package and Microsoft has you right where Rambus has every memory maker on the planet.

Good. Now how fast does your Haskell program run?

Pretty well, I'd say.

Open packaging standards? I know a great one!

I sympathize, although for my desktop system I do prefer just grabbing the latest stable stuff every nine months or so ala the Ubuntu release cycle. But for a server of course, it's nice to have things stable. Or is it UI changes that bug you?

But as the Anonymous One suggested, there are other flavors of Linux which move at a slower pace, such as http://debian.org/ or RHEL (or the free version of it, CentOS).

Well, right, I think we're saying the same thing and agreeing :) The core of the problem was Debians requirement that they should be able to ship unapproved patches to Firefox and still call it Firefox. That makes no sense for any program that is trying to build a brand reputation. That's why I said an open source "app store" would have a very different philosophy to an open source "repository" where the understanding is that you can "apt-get install firefox" and possibly get something that is not what the Firefox developers actually created.

Before Apple, shared calendaring in the linux world sucked or was very expensive. Get the source for Darwin Calendar Server here:
http://trac.calendarserver.org/
Or the Deb:
http://packages.debian.org/stable/python/calendarserver

If it's on Debian, it's pretty darn open.

I am one of those who support copyright, but with major, major, major revisions, especially in the area of its expiration date. Most songs lose value after 5 years, so 25 years should be more than enough. Even death + 25 is much more than enough, except in extreme cases (Tolkien's works). But death + 95 for all content is silly and stupid. If things keep going this way, soon we'll see death + 150, and that's just plain silly.

And how do they get paid if anyone can replicate their content for free? Just hope for donations? There's a guy with a guitar on the corner of my street who does that. It doesn't seem to be working all that well for him.

How do you know that donations wouldn't start working? See, if people suddenly had no new music, perhaps they might pay for new music in other ways.

Or they might say "We have enough old music, we don't need more" and that'd be it. Why do you think that free market can't regulate itself?

That said, some basic protection at least for first few years is stimulative enough. As I said, even 25 years would be enough. I definitely won't think of paying for stuff more than 25 years old because it's just that -- old. Except in case of really cult movies.

How about the freedom of matters of fact? For example, we should have the freedom to know how our tax dollars are spent. That doesn't mean Microsoft should have the freedom to steal the code for Firefox, slap an IE-logo on it, and call it their own.

But they can take it. It's not even stealing, you can rebrand Firefox, uhm I mean Iceweasel.

Most C programs are fast, except they have all but 1 core on the CPU idling because threading and concurrency are very hard to bolt on to a C program. Which is why some performance critical messaging servers are done in languages like Erlang.

Except that auto detecting and synchronizing generic (I'm not talking about vectorization) parallelism is a hard problem. If you look at the thread ring benchmark you will see that haskell and erlang post significantly better results than C. A closer look shows that the C routine is balancing the CPU usage, while the haskell/erlang results are running entirely on a single CPU. How is it a micro benchmark like that could run 20x as fast in haskell on a single CPU as the C version does using all 4 CPU's? Its because C is explicitly context switching, while the haskell implementation is implicitly using a cooperative threads model. Doing that would be extremely easy in C, but its disallowed. It is possible to write massively parallel code using something like VHDL, the problem is that the locking is still explicit (via clocking) and the result is extremely slow. Frankly, if someone could actually write a compiler that does SMP parallelism on procedural code, without doing a time/space tradeoff, or a number of other fundamental issues, there name would appear in every comp sci book for the rest of history.

Only languages implementations of the The Computer Language Benchmarks Game [1] are used. Read there rues and you know.

Martin

[1] http://shootout.alioth.debian.org/ [debian.org]

Only languages implementations of the The Computer Language Benchmarks Game [1] are used. Read there rues and you know.

Martin

[1] http://shootout.alioth.debian.org/

If you would like APL to be on the list, then submit benchmarks for APL to the Shootout (the blog got its data fro there).

~I'm sure he would definitely like to. But he broke the necessary keyboard~

The justice or injustice of your comment depends strongly on what metric they're using for size, and a lot of the replies to your comment have been speculating about what the metric really is. Okay, if you start with the game's FAQ, it looks like there are three different metric they actually computed:

1. size of the source code, in bytes
2. "gzip bytes," which they define as follows: "We started with the source-code markup you can see, removed comments, removed duplicate whitespace characters, and then applied minimum GZip compression."
3. amount of memory used when running

Obviously these are going to give completely different results. Java will come out looking awful by measure #3, for instance. The difference between #1 and #2 has more to do with the distinction between terseness and expressiveness. You wrote "Do you make all of your variables and class/function/methods a single character for the sake of verbosity? I hope not." If someone did that, it would have a huge effect on #1, but little or no effect on #2. Actually #2 seems to me like a very reasonable measure of expressiveness.

So now the question is which one the author of the article actually used for his plots. He doesn't say explicitly which one he used. However, he has links to the source code he used to generate the plots, and to the data file he used as input. The data file only has metrics #1 and #3, so it looks like he didn't actually use metric #2, which IMO is the only one that measures expressiveness in the way he obviously intended. If you look through his lisp code, it looks to me like he actually used #1. (See the line that reads "(normalize-accross (normalize-accross data 'cpu) 'size))". My lisp is pretty weak, but I believe he's extracting the columns whose names begin with the strings "cpu" and "size.")

So it looks to me like he picked the wrong metric, which makes your criticism valid, but that just means he should have picked the right metric.

Even the right metric, #2, still wouldn't be a perfect proxy for expressiveness, of course. For instance, a language with static typing and no type inference will require the programmer to expend a lot of characters on declarations. However, that's a matter of taste; some people feel safer with static typing.

If you would like APL to be on the list, then submit benchmarks for APL to the Shootout (the blog got its data fro there). The Shootout is mainly driven by user submissions. They do have some fairly strict rules about how to submit. However, if you can name an implementation (along with enough guidelines to make installing it easy) and provide a reasonably full set of benchmarks, then the language will generally be added.

One tip about submitting though: try to make life as easy as possible for the guy who runs it. He doesn't have time to figure out typos or to fix "easy" bugs in some programming language they he may not even know.

ML, Haskell, Scheme, Fortran and Common Lisp are on the list. You probably didn't notice them because they are listed by their implementation name (e.g. mlton/O'Caml, GHC, Stalin/Gambit/Ikarus/Chicken, G95, SBCL/CMUCL, etc.). The Shootout front page lists which implementations implement which languages.

What if you used Linux with a BSD kernel? Is it still Linux?

That would be GNU/kFreeBSD ;-)

From http://scienceblogs.com/goodmath/2006/11/the_c_is_efficient_language_fa.php :

"I didn't know what language to use for this project, so I decided to do an experiment. I wrote the LCS algorithm in a bunch of different languages, to compare how complex the code was, and how fast it ran. I wrote the comp bio algorithm in C, C++, OCaml, Java, and Python, and recorded the results. What I got timing-wise for running the programs on arrays of 2000 elements each was:

        * C: 0.8 seconds.
        * C++: 2.3 seconds.
        * OCaml: 0.6 seconds interpreted, 0.3 seconds fully compiled.
        * Java: 1 minute 20 seconds.
        * Python: over 5 minutes.

About a year later, testing a new JIT for Java, the Java time was down to 0.7 seconds to run the code, plus about 1 second for the JVM to start up. (The startup times for C, C++, and Ocaml weren't really measurable - they were smaller than the margin of error for the measurements.)"

http://shootout.alioth.debian.org/ has more.

Here's the build:

http://packages.debian.org/etch/graphics/vlc

Here's the source:

http://packages.debian.org/source/etch/vlc

Are you a moron or just a bad troll?

Here's the build:

http://packages.debian.org/etch/graphics/vlc

Here's the source:

http://packages.debian.org/source/etch/vlc

Are you a moron or just a bad troll?

Exactly, now do it for every single function, automatically determining (by call count and mutability of external references) if it makes sense or not. Now you DO have a runtime.

At compile time, you would make the safety checks to see if a function is safe enough to be optimize (it certainly can't use global variables, unless the contents of those are also to be recorded; changing global variables would be a no-go of course). And it would only be able to call equally safe functions.

I think you're blurring the definition of a runtime a bit. I don't consider inserting trivial wrapper code around a function's contents a real runtime system, but if you want to call it that, go ahead. That's what things like gprof (profiler) do, and it works just fine.

Also, how do you prove that pointers haven't modified the values you depend on without checking each one?

The same way that the runtime would do it. The runtime would also have to check such things (and that's if they dare to apply this optimization to functions accessing foreign objects).

--Inlining code like that (or not) based on runtime statistics.

Is that improvement worth it when you have to constantly gather statistics about every function call? There's two sides to this coin, you know. Does Java implement that?

--Taking code written as single-threaded and throwing multiple threads at it when it determines that two paths don't interact. (This could be done at compile time as well, but could be done more efficiently with code profiling information in memory.)

How would it prove that the two paths don't interact, in a way which can't be done by a compiler? The compiler can also simulate the running of code.

An example would be helpful if you think I'm wrong in this case.

In fact, that may be the point that the C people here are missing. How can C possibly compete with a language that compiles to machine language with more information than the C compiler has at compile time?

That's not the whole picture. Java has more features which add a certain overhead to several operations (function calls, accesses to arrays, type handling and so on).

I accept that having a smart runtime can be helpful in some cases, but it's not like you can't make such a runtime for C either. The fact is that so far C's performance is great without one.

Look at some of those results (The best code submitted by expert programmers for each language)--Java and C are always in the top few, C is almost always a few ticks quicker, but virtually tied.

I looked, and it's a bit weird that the results for C and C++ often differ by a lot (which makes me think the programs are not that optimized, as for small programs like that it should be trivial to make C and C++ as fast as each other).

I assume "elapsed secs" is the most relevant performance statistic.

Still, either C or C++ are always faster than Java, and in most cases much faster as you can see in these comparison pages:

http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=javasteady&lang2=gpp&box=1
http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=javasteady&lang2=gcc&box=1

I see a lot of problems for which C/C++ are 2 or 3 times faster than Java.

By the way, it's worth noting that some of these benchmarks do little memory handling and are pretty numerical code which uses few language features. In these cases compiler quality should make most of the difference in results, so Java should fare quite well there.

Exactly, now do it for every single function, automatically determining (by call count and mutability of external references) if it makes sense or not. Now you DO have a runtime.

At compile time, you would make the safety checks to see if a function is safe enough to be optimize (it certainly can't use global variables, unless the contents of those are also to be recorded; changing global variables would be a no-go of course). And it would only be able to call equally safe functions.

I think you're blurring the definition of a runtime a bit. I don't consider inserting trivial wrapper code around a function's contents a real runtime system, but if you want to call it that, go ahead. That's what things like gprof (profiler) do, and it works just fine.

Also, how do you prove that pointers haven't modified the values you depend on without checking each one?

The same way that the runtime would do it. The runtime would also have to check such things (and that's if they dare to apply this optimization to functions accessing foreign objects).

--Inlining code like that (or not) based on runtime statistics.

Is that improvement worth it when you have to constantly gather statistics about every function call? There's two sides to this coin, you know. Does Java implement that?

--Taking code written as single-threaded and throwing multiple threads at it when it determines that two paths don't interact. (This could be done at compile time as well, but could be done more efficiently with code profiling information in memory.)

How would it prove that the two paths don't interact, in a way which can't be done by a compiler? The compiler can also simulate the running of code.

An example would be helpful if you think I'm wrong in this case.

In fact, that may be the point that the C people here are missing. How can C possibly compete with a language that compiles to machine language with more information than the C compiler has at compile time?

That's not the whole picture. Java has more features which add a certain overhead to several operations (function calls, accesses to arrays, type handling and so on).

I accept that having a smart runtime can be helpful in some cases, but it's not like you can't make such a runtime for C either. The fact is that so far C's performance is great without one.

Look at some of those results (The best code submitted by expert programmers for each language)--Java and C are always in the top few, C is almost always a few ticks quicker, but virtually tied.

I looked, and it's a bit weird that the results for C and C++ often differ by a lot (which makes me think the programs are not that optimized, as for small programs like that it should be trivial to make C and C++ as fast as each other).

I assume "elapsed secs" is the most relevant performance statistic.

Still, either C or C++ are always faster than Java, and in most cases much faster as you can see in these comparison pages:

http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=javasteady&lang2=gpp&box=1
http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=javasteady&lang2=gcc&box=1

I see a lot of problems for which C/C++ are 2 or 3 times faster than Java.

By the way, it's worth noting that some of these benchmarks do little memory handling and are pretty numerical code which uses few language features. In these cases compiler quality should make most of the difference in results, so Java should fare quite well there.

Exactly, now do it for every single function, automatically determining (by call count and mutability of external references) if it makes sense or not. Now you DO have a runtime.

Also, how do you prove that pointers haven't modified the values you depend on without checking each one?

And that's just one of hundreds of things that are possible with a VM, none of which you can do with native code.

--Compiling code to native for a given state of a variable who's state rarely changes, eliminating calculations on that variable as though it was a constant.
--Compiling a second instance of that method if the variable DOES change, being able to alternate between which of the two you call at will.
--Inlining code like that (or not) based on runtime statistics.
--Taking code written as single-threaded and throwing multiple threads at it when it determines that two paths don't interact. (This could be done at compile time as well, but could be done more efficiently with code profiling information in memory.)
--Improving the efficiency without recompiling (Or, you could look at Java as ALWAYS recompiling to machine language)

In fact, that may be the point that the C people here are missing. How can C possibly compete with a language that compiles to machine language with more information than the C compiler has at compile time?

Currently C keeps up (Most benchmarks seem to have a few C compilers running faster than java and a few slower, but the difference is often under 10% both ways) but C is on it's umpteenth year of optimization, whereas the JVM has only been compiling for a few years now and has a lot of improving to do...

http://shootout.alioth.debian.org/u64q/benchmark.php?test=binarytrees&lang=all&box=1

Look at some of those results (The best code submitted by expert programmers for each language)--Java and C are always in the top few, C is almost always a few ticks quicker, but virtually tied.

If you think the C code must suck, please help C win by improving their code--I'm fairly sure it's already been streamlined past what a mortal programmer can improve in most of those languages. Until someone improves these I'm going to go with C and Java being the same speed, but Java improving more rapidly.

I'd quite like to see you beat my Haskell entry for the computer language shootout, thread ring program: http://shootout.alioth.debian.org/u32q/benchmark.php?test=threadring&lang=all&box=1 it's currently almost 20 times as fast as the C entry. If you can beat it, then please, by all means, submit it to the shootout, just make sure you read the rules (there may be faster ways to do the same thing, but separate threads of execution are required) :)

Sure there is, and it's 2-3 times faster than the C version.

This seems to be one case where C could use some help:

http://shootout.alioth.debian.org/u32q/benchmark.php?test=threadring&lang=all&box=1

The functional languages seem to have it locked up, or perhaps their C implementation needs you to step up and fix it.

There is no reason any other compiler couldn't put out code as good as C, better in fact since C allows pointers (which stops the compiler from making quite a few optimizations). It's just that C tends to be easier to hand-optimize right now (just like assembly is easier than C). That doesn't make assembly better for 99% of the cases though, and the same could be said of C.

Sure. How about pi digits http://shootout.alioth.debian.org/u32q/benchmark.php?test=pidigits&lang=all . Currently the fastest program is in the functional language Haskell. I challenge you to write a faster one in C (for a quad core processor).

> So for all the non-volatile stuff, the compiler can perform the same static analysis that a Java/C# compiler does to decide whether a function has your specified behavior or not.

No it can't. It can't recognize that a function happened to be called 30 times in the last second with the parameters (1, 5, "Hello") and returned 17, and just return 17 for those values--and the next day, do the same thing for different values.

Sure you could program it to, but it would all be your code--C cannot do it for you on every single function, it wouldn't make sense (then C would need a runtime like java--it would no longer be C)

Also--the language itself would make this impossible. Java can know for sure that nothing is modified without the runtime's knowledge. There are no pointers in Java, and the runtime can analyze a class to ensure that things it relies on haven't changed. C could not do that generically, You would have to double the size of every method to get that kind of functionality.

> And what's to stop people from writing a linker which does some "post-production" optimizations on the object code?

You'd have to relink. I suppose linking could be done at runtime automatically, and C could have a runtime that was updated and understood how to restructure the code and add new optimizations. It would probably have to eliminate pointers and have a pretty serious runtime component to do so. Perhaps it could take on a new name--call it C# I guess.

>Also, note that traversing data structures representing byte code isn't free. If later JVMs do more work to optimize code before running it, I predict they will take longer to start up.

Not really, they can (and do) just make the JVM more efficient. The chances also tend to make the JVM smaller and faster to load.

>Are people shipping fancy linkers that speed up C code? No, they're not. Are JVMs employing fancy optimization techniques at run-time? Yes, they are. Is C substantially faster than Java at run-time? Yes, it is.

What makes you say it's substantially faster? Until you get fairly high on the C optimization scale, Java tends to be faster--There was a programming challenge on Cedric's blog that became really interesting--people optimized the hell out of a routine and then re-ported it to a few languages. I believe the Java routine was slightly faster than the C routine (including startup) until it was compiled above -O3, then the differences were minimal (IIRC). In a few cases java is much worse (maybe even 10x), but for most stuff it tends to be 2x as slow.

One of the worst cases is floating-point math where Java refuses to use the math co-processor because they do not all return the same results for a given operation--this infuriates the graphics folks who don't care about accuracy anywhere near as much as speed (and here lies one of the REAL advantages of C, you can't fix this without recompiling the java source--a daunting task--where in C you just link against a different library.)

Anyway, the point is, compare Java and C's speed to say that of Python and Ruby (100x slower) and you'll see that Java and C are extremely closely tied.

I've used Java on multiple embedded platforms with oddball chipsets and very low power (including high performance graphics).

So Can you back up your "Substantially faster" statement? Where do you get your data? Are you just using the same logic and assuming it has to be faster?

http://shootout.alioth.debian.org/gp4/benchmark.php?test=nbody&lang=all

http://shootout.alioth.debian.org/u32/benchmark.php?test=threadring&lang=all

OK, go on. Do this in less than 100 sec to beat the best C entry.
Do it in less than 8 sec to prove your point.

Unless

        * create 503 linked threads (named 1 to 503)
        * thread 503 should be linked to thread 1, forming an unbroken ring
        * pass a token to thread 1
        * pass the token from thread to thread N times
        * print the name of the last thread (1 to 503) to take the token

Is too complicated for you

FYI: Debian lenny (the current stable) ditched apache 1.3 and only includes 2.2 now.

Even the previous version of stable (etch) offered Apache 2.2 as an option. The release before that (sarge) had Apache 2.0 as an option.