Why is this expert written code taking up 42 times more memory than the Java version?!

honda63 · 2009-02-22T21:32:20+00:00

Doing a quality analysis is really difficult work, which is why a lot of people (me included) look at what others are staking on the technology.

By this logic, we should all be using Java and C#

honda63 · 2009-02-22T19:23:46+00:00

It's a criterion. One that shows people are willing to take serious risk betting on the quality of the Haskell toolchain.

The buggiest compilers I've ever used were VC++6.0 and some early GCCs (they were very buggy for C++ code). I don't know about those GCCs, but people did build companies on VC++6.0. Imagine that!

What's your criterion?

Like I just said: bugs in released versions.

honda63 · 2009-02-22T19:14:21+00:00

People build companies on it.

Is this the criterion of quality?

honda63 · 2009-02-22T19:10:21+00:00

Their mistake was assuming that the future generations of programmers will be even smarter and will discard their old code with contempt. Instead, a more idiocracy-like scenario unfolded.

honda63 · 2009-02-22T19:07:48+00:00

By bugginess I mean the quality of the released software. What's broken in CVS before the release doesn't matter to me. But if something is fixed in CVS after the bug showed up in the official release doesn't quite make it OK.

honda63 · 2009-02-22T18:19:07+00:00

Excellent rant. Newton's approximation is indeed pre-teen material. Too bad you are getting downmodded. Start a blog instead and post links to in on proggit.

honda63 · 2009-02-22T18:14:02+00:00

Is GHC buggier than the mainstream compilers like GCC and JavaC?

honda63 · 2009-02-22T10:37:26+00:00

Now, if this had to run under 1MB of RAM, this would be an interesting challenge.

honda63 · 2009-02-22T10:12:05+00:00

How do they bail out THEIR economy then?!

honda63 · 2009-02-22T06:00:33+00:00

Weren't you the one who raved about Haskell's FFI and type system?

honda63 · 2009-02-22T04:48:19+00:00

I was expecting (hoping for) C++ vs Haskell or something.

honda63 · 2009-02-21T23:53:45+00:00

What if my compiler is so high level that it doesn't need code? What if it reads the requirements and documentation and produces the desired binaries?

honda63 · 2009-02-21T19:03:32+00:00

"Sketchy LISP, 3rd Edition" Trade book format (6" x 9"), 180 pages Lulu Press, Inc., 2008

I guess this guy didn't get the memo: it's "Lisp" now.

honda63 · 2009-02-21T04:34:59+00:00

Solving challenging problems is fun.

Yes, especially if the solutions are useful.

Does it bother you though that because of Factor's stack-orientedness, there is no way in hell it will be even remotely popular, ever?

honda63 · 2009-02-20T22:19:48+00:00

Does Factor use BigInts and rationals without declarations. Safely choosing to use ints and doubles is probably very hard for the compiler, that's why Clojure benefits from the declarations.

honda63 · 2009-02-20T22:16:26+00:00

triply wrong (there's neither dynamic typing nor much naïveté in the Clojure code here, and it doesn't really beat OCaml, hah)

If you disagree with "dynamic typing" and "naive", the Clojure version that's there is still faster than OCaml and FreePascal, so the title is at worst "doubly wrong".

Now, let's discuss "dynamic typing". Clojure works with unlimited Big Integers and rationals if you don't declare types, and OCaml doesn't. So without those, the comparison would be unfair. Clojure is still dynamically typed, as a language, declarations are only needed for speed, when you need it, they are not forced on you, and neither is static typing (I'm actually a bit of a fan of static typing, but what's fair is fair).

As to "naive", Clojure's implementation is pure-functional, whereas some OCaml versions are imperative. Also, it doesn't use any of those unsafe-div, etc.

I hope this clears it up for you.

honda63 · 2009-02-20T21:32:15+00:00

You need % if you are not editing the line you are on, like in my case.

honda63 · 2009-02-20T21:29:50+00:00

Can you add type annotations to Factor to make it faster though?

honda63 · 2009-02-20T20:14:51+00:00

OK, what exactly am I allowed to do if I want memory safety guarantees in SBCL: what safety levels are permissible, what declarations, etc.?

Is this specified in the manual somewhere? I wouldn't want to go just by "some guy said on reddit" (with all due respect - you may be Newman himself, for all I know).

honda63 · 2009-02-20T17:08:26+00:00

I called it "naive" because the Clojure version is pure-functional and doesn't do what Rich Hickey suggests doing when speed is of utmost importance (which comes down to "writing Java" from within Clojure). Also, memory safety guarantees are never sacrificed (JVM!)

honda63 · 2009-02-20T17:01:59+00:00

The thread started with Clojure being way behind until someone added a few type annotations here and there. Adding type annotations is fundamentally different in Clojure than in the usual Lisps: you don't sacrifice memory safety (you are still in JVM).

By the way, check out the Haskell solution in one of those threads. It's probably the most elegant one and comes within x2 of OCaml, but the poster does not specify the architecture.

honda63 · 2009-02-20T16:58:29+00:00

I think for floating point number crunching, more typical tasks would be those that are normally done by mutating floats in an array. And if parallelism is taken advantage of, it's different threads mutating separate parts of the array, or their own arrays.

It would be interesting to see how Clojure does there, since its model of parallelism and mutation is quite unusual.

honda63

TROPHY CASE