The Freshmeat ratings would be far more useful if more users actually bothered to rate the software they have tried. Even if that were the case, these OpenBRR dorks are right about one thing: a simple scalar metric is not terribly informative for describing the many attributes of a software package. I wish FM would have separate categories for ease of installation, documentation quality, usability, etc.
For a really fast boot time, why not store the boot file in flash RAM?
Because flash RAM is slow. Unless I've lost touch with the latest tech, the average HDD provides about 4x the throughput of current flash memory. Next-gen flash is better, but still on the same order of magnitude. A battery-backed (volatile) RAM boot disk could be nifty...
The LinuxBIOS project lets you boot up fast out of flash, but that's mainly because you get the skip all the useless crap that the PC BIOS wastes time on.
Well put. It's incredibly disappointing that the industry standard for scientific/engineering algorithm prototyping comes with such a poor programming language. The moment you want to do something that the built-in functions can't handle, Matlab's weaknesses become apparent.
Psilab offers a much better programming environment than Matlab or its clones. The tradeoff, of course, is that Psilab's algorithm library comes nowhere near the scope of Matlab's.
In this post I provide evidence that Arch offers reasonable performance on large trees. Here is a post from the lkml thread that demonstrates Monotone's performance problems.
Do you have a link where has Arch been proven prohibitively inefficient? (Any benchmark older than mid-2004 is obsolete.)
Also, bazaar is not a performance-focused fork, although it does have a caching system that is not yet in mainline Arch. Its primary goal is to put a better UI on top of Arch. bazaar-ng is a completely separate project that shares no code with Arch, but is inspired by some pieces of Arch design.
"If it takes half a minute to apply a patch and remember the changeset boundary etc (and quite frankly, that's _fast_ for most SCM's around for a project the size of Linux), then a series of 250 emails (which is not unheard of at all when I sync with Andrew, for example) takes two hours."
Generally speaking, applying a series of Arch changesets is a fast operation--it's nothing more than 'diff' and 'patch' with rename tracking. The bottleneck is running "tla changes" prior to commit, which determines what files have been altered by the series of patches.
Here is an email in which a knowledgeable Arch hacker demonstrates Linux kernel 'tla changes' benchmarks under 20s. That's a relatively minimal penalty, and it's incurred once per merge, not once per patch.
I don't usually reply to ACs, but I believe this to be inaccurate. Arch performance is quite reasonable, particularly when exploiting its revision library and hard-link checkout optimizations.
Perhaps you are thinking of darcs or monotone, both of which do have performance issues on large trees.
Darcs is nice, but it doesn't (yet) perform well enough for regular kernel development. The patch reordering algorithms work by loading the entire history in memory, which does not scale well to large trees.
Darcs is, at the moment, a nice system for smaller projects.
So... maybe you can re-write higher-order memoization code using more efficient data structures? I would love to see that code, and I'm sure the OCaml community would benefit from having that in their toolbox.
You get a significant boost just by dumping the list memoization in favor of a hashtable implementation. I'm not necessarily saying that's the optimal choice, but it's an easy drop-in replacement that is much better suited to the task. Here's a patch:
(* checks if each cell in center colum is covered by an empty cell *)
let rec isCovered c1 c2 c3 = @@ -266,7 +266,7 @@ and memo_fib n = memoize fib n;;
*)
QEMU looks like a worthy replacement for VMWare, especially given the recent release of the accelerator module. Fabrice is hoping for corporate support of the project, and IMO he is as deserving as anyone.
Basically, if you can't write a complex FFT with a user-defined complex number type and have it work about as efficiently...
Of course, I couldn't help myself and had to go experiment a bit. My conclusion is that you're halfway correct. A naive FFT implementation using the standard Complex module delivers very poor performance. A few minutes with the profiler demonstrates that the biggest problem is the immutability of the standard Complex datatype. You end up doing lots of needless allocations and garbage collections--mark_slice alone accounts for 40% of the computation.
But if you're willing to compromise a bit, you can use a mutable data structure and get rid of most allocations. The tradeoff is that the code has lots of assignments--not very functional in nature.
C++ and OCaml code is here. On my (slow) machine, I get the following representative times:
$ time./fft_cpp
real 0m3.143s user 0m2.881s sys 0m0.128s
$ time./fft_ml
real 0m3.785s user 0m3.465s sys 0m0.123s
I consider that pretty good. Note that the C++ STL isn't terribly fast here; you can save about 25% on the C++ code by dumping that in favor of something simpler. But still, OCaml is in the ballpark as long as you're willing to write imperative-looking code.
Thanks for elaborating--you have made your point more clearly. I'm not sure I agree with the conclusion that OCaml (like Java) is defective due to deficiencies in handling of numeric types, but I see where you're going.
Basically, if you can't write a complex FFT with a user-defined complex number type and have it work about as efficiently (in both space and time) as equivalent Fortran 90 or C++ code, then the language is not suitable for modern general-purpose applications.
I completely disagree.
1) What do you consider "about as efficiently?" A ten-second search turns up an FFT benchmark written by Xavier Leroy; he reports that it runs about 2/3 as fast as C code.
2) What the hell kind of "modern general-purpose application" needs to compute FFTs quickly? That's a highly specialized application.
3) If certain algorithms cannot be computed quickly in OCaml, just write them in C. Bindings to C functions are trivial to write. You want to do FFTs? It's already been done.
I'm working on OS X right now (which is a real pain without administrator privileges). Check the London Law site in a day or two; I'll put out a point release when I've got something workable.
You have two options for installing as an unprivileged user:
Don't install. Just extract the archive somewhere, change to the londonlaw/ subdirectory, and you should be able to launch the client and server from there.
Use the '--prefix' option to setup.py to set the installation directory somewhere that does not require root permissions. But if you do this, you'll need to set the PYTHONPATH environment variable appropriately so that python knows where to find the module.
Now quit complaining about free stuff. Or at least find a better reason to complain.
As the author of London Law, I'd just like to point out that
I personally have only tested this code under Linux, Win98, and WinXP. And not so heavily in Windows.
While the game is fully playable, this is an initial release and it needs a whole lot of work yet. My plans are laid out in the TODO file buried in the archive.
Also, have mercy on my department's poor webserver. I understand some people actually rely on it to deliver important things like, say, homework.
Creature AI could be painful to work with. Behavior learned early on often dominated a creature's actions, to the point that the creature might not be very useful. I had one run through the game with a creature who would cast only the rain spell, continued to eat occasional villagers, and got his jollies by pooping boulder-sized turds all over important buildings. It was not possible to correct the situation.
After spending all that time training a creature, perhaps even successfully, you end up playing half the game without it. Hey, it's Populous all over again! In 3D!
The game was too short and rather repetitive.
The villagers seemed painfully incapable of looking after themselves; the game eventually devolves into micromanagement.
The fundamental challenge was usually getting past the obstacle of a scarce resource (wood). That's just boring game design.
Mouse gestures were a neat trick, but ultimately impractical. The lack of a complete set of hotkeys is simply ridiculous.
Save and load times were insane. I guess I'll give Lionhead a partial pass on this one, as there is rather a lot of villager state to encode.
In short: a lot of neat ideas and a pretty good engine, but I found the game itself to be pretty darned boring after the first day or so.
Slashdot Mirror
The Freshmeat ratings would be far more useful if more users actually bothered to rate the software they have tried. Even if that were the case, these OpenBRR dorks are right about one thing: a simple scalar metric is not terribly informative for describing the many attributes of a software package. I wish FM would have separate categories for ease of installation, documentation quality, usability, etc.
It's a completely different trailer. That one's been out for a couple of months already.
Good point.
For a really fast boot time, why not store the boot file in flash RAM?
Because flash RAM is slow. Unless I've lost touch with the latest tech, the average HDD provides about 4x the throughput of current flash memory. Next-gen flash is better, but still on the same order of magnitude. A battery-backed (volatile) RAM boot disk could be nifty...
The LinuxBIOS project lets you boot up fast out of flash, but that's mainly because you get the skip all the useless crap that the PC BIOS wastes time on.
Well put. It's incredibly disappointing that the industry standard for scientific/engineering algorithm prototyping comes with such a poor programming language. The moment you want to do something that the built-in functions can't handle, Matlab's weaknesses become apparent.
Psilab offers a much better programming environment than Matlab or its clones. The tradeoff, of course, is that Psilab's algorithm library comes nowhere near the scope of Matlab's.
Maybe the poster was trying to save us from that oh-so-trendy yet squint-inducing low-contrast text. You'd think Goodger would know better...
In this post I provide evidence that Arch offers reasonable performance on large trees. Here is a post from the lkml thread that demonstrates Monotone's performance problems.
Do you have a link where has Arch been proven prohibitively inefficient? (Any benchmark older than mid-2004 is obsolete.)
Also, bazaar is not a performance-focused fork, although it does have a caching system that is not yet in mainline Arch. Its primary goal is to put a better UI on top of Arch. bazaar-ng is a completely separate project that shares no code with Arch, but is inspired by some pieces of Arch design.
"If it takes half a minute to apply a patch and remember the
changeset boundary etc (and quite frankly, that's _fast_ for most SCM's
around for a project the size of Linux), then a series of 250 emails
(which is not unheard of at all when I sync with Andrew, for example)
takes two hours."
Generally speaking, applying a series of Arch changesets is a fast operation--it's nothing more than 'diff' and 'patch' with rename tracking. The bottleneck is running "tla changes" prior to commit, which determines what files have been altered by the series of patches.
Here is an email in which a knowledgeable Arch hacker demonstrates Linux kernel 'tla changes' benchmarks under 20s. That's a relatively minimal penalty, and it's incurred once per merge, not once per patch.
I don't usually reply to ACs, but I believe this to be inaccurate. Arch performance is quite reasonable, particularly when exploiting its revision library and hard-link checkout optimizations.
Perhaps you are thinking of darcs or monotone, both of which do have performance issues on large trees.
The Arch project is active. Version 2.0 has been postponed in favor of continued maintenance of the 1.x line.
The Bazaar project is a fork of Arch that is introducing new features more rapidly (improved syntax, new archive formats, a caching system, etc.).
Darcs is nice, but it doesn't (yet) perform well enough for regular kernel development. The patch reordering algorithms work by loading the entire history in memory, which does not scale well to large trees.
Darcs is, at the moment, a nice system for smaller projects.
You get a significant boost just by dumping the list memoization in favor of a hashtable implementation. I'm not necessarily saying that's the optimal choice, but it's an easy drop-in replacement that is much better suited to the task. Here's a patch:Also: learn to use the profiler! It takes about five seconds to see that camlList__assoc is killing you.
QEMU looks like a worthy replacement for VMWare, especially given the recent release of the accelerator module. Fabrice is hoping for corporate support of the project, and IMO he is as deserving as anyone.
Basically, if you can't write a complex FFT with a user-defined complex number type and have it work about as efficiently...
./fft_cpp
./fft_ml
Of course, I couldn't help myself and had to go experiment a bit. My conclusion is that you're halfway correct. A naive FFT implementation using the standard Complex module delivers very poor performance. A few minutes with the profiler demonstrates that the biggest problem is the immutability of the standard Complex datatype. You end up doing lots of needless allocations and garbage collections--mark_slice alone accounts for 40% of the computation.
But if you're willing to compromise a bit, you can use a mutable data structure and get rid of most allocations. The tradeoff is that the code has lots of assignments--not very functional in nature.
C++ and OCaml code is here. On my (slow) machine, I get the following representative times:
$ time
real 0m3.143s
user 0m2.881s
sys 0m0.128s
$ time
real 0m3.785s
user 0m3.465s
sys 0m0.123s
I consider that pretty good. Note that the C++ STL isn't terribly fast here; you can save about 25% on the C++ code by dumping that in favor of something simpler. But still, OCaml is in the ballpark as long as you're willing to write imperative-looking code.
Thanks for elaborating--you have made your point more clearly. I'm not sure I agree with the conclusion that OCaml (like Java) is defective due to deficiencies in handling of numeric types, but I see where you're going.
Basically, if you can't write a complex FFT with a user-defined complex number type and have it work about as efficiently (in both space and time) as equivalent Fortran 90 or C++ code, then the language is not suitable for modern general-purpose applications.
I completely disagree.
1) What do you consider "about as efficiently?" A ten-second search turns up an FFT benchmark written by Xavier Leroy; he reports that it runs about 2/3 as fast as C code.
2) What the hell kind of "modern general-purpose application" needs to compute FFTs quickly? That's a highly specialized application.
3) If certain algorithms cannot be computed quickly in OCaml, just write them in C. Bindings to C functions are trivial to write. You want to do FFTs? It's already been done.
Check the website, there's a new build available specifically for OS X.
Think of it this way: that screenshot is motivation for me to rewrite the crappy server sooner rather than later.
Of course, that's a valid complaint, but don't blame me. I didn't post it here. :-)
I'm working on OS X as we speak; hopefully the porting issues are minor. Check the site again in a day or two.
I'm working on OS X right now (which is a real pain without administrator privileges). Check the London Law site in a day or two; I'll put out a point release when I've got something workable.
- Don't install. Just extract the archive somewhere, change to the londonlaw/ subdirectory, and you should be able to launch the client and server from there.
- Use the '--prefix' option to setup.py to set the installation directory somewhere that does not require root permissions. But if you do this, you'll need to set the PYTHONPATH environment variable appropriately so that python knows where to find the module.
Now quit complaining about free stuff. Or at least find a better reason to complain.If someone does have it working perfectly under OS X, they haven't told me about it. I have a couple reports of it "almost working."
Also, have mercy on my department's poor webserver. I understand some people actually rely on it to deliver important things like, say, homework.
original
- Creature AI could be painful to work with. Behavior learned early on often dominated a creature's actions, to the point that the creature might not be very useful. I had one run through the game with a creature who would cast only the rain spell, continued to eat occasional villagers, and got his jollies by pooping boulder-sized turds all over important buildings. It was not possible to correct the situation.
- After spending all that time training a creature, perhaps even successfully, you end up playing half the game without it. Hey, it's Populous all over again! In 3D!
- The game was too short and rather repetitive.
- The villagers seemed painfully incapable of looking after themselves; the game eventually devolves into micromanagement.
- The fundamental challenge was usually getting past the obstacle of a scarce resource (wood). That's just boring game design.
- Mouse gestures were a neat trick, but ultimately impractical. The lack of a complete set of hotkeys is simply ridiculous.
- Save and load times were insane. I guess I'll give Lionhead a partial pass on this one, as there is rather a lot of villager state to encode.
In short: a lot of neat ideas and a pretty good engine, but I found the game itself to be pretty darned boring after the first day or so.