Objects vs closures • Hacker News Board

Re: Objects vs closures

#11

Post by supersillyus » Wed, Dec 08, 2010, 5:21 PM UTC

swannodette wrote: post #9

beza1e1 wrote: post #7

"so closures can be, and are, used to implement very effective objects with multiple methods" I don't really believe this to be efficient. The linked text by Kiselyov implements the dispatch via Scheme's (case ...) expression. Efficient dynamic dispatch means one indirection through a vtable, so one load instruction more compared to a normal function call. Which compilers for functional languages can perform this opt…

Clojure. Clojure has a fairly interesting feature called reify: (defprotocol Foo (bar [this]) (baz [this])) (defn make-foo [a] (reify Foo (bar [this] a) (baz [this] a))) (dotimes [_ 10] (let [x (make-foo 'x)] (time (dotimes [_ 1e8] (bar x) (baz x)))) So 2 methods called 1 billion times only takes about ~500ms on my 2.66ghz i7 MacbookPro. (of course, Clojure prefers values+behaviors, aka objects, without mucking it up…

It seems very likely to me that the JVM is recognizing that "bar" and "baz" don't do anything and (after some warm-up) optimizing them away. Microbenchmarking JVM is hard.

Re: Objects vs closures

#12

Post by anon_d » Wed, Dec 08, 2010, 5:29 PM UTC

beza1e1 wrote: post #7

"so closures can be, and are, used to implement very effective objects with multiple methods" I don't really believe this to be efficient. The linked text by Kiselyov implements the dispatch via Scheme's (case ...) expression. Efficient dynamic dispatch means one indirection through a vtable, so one load instruction more compared to a normal function call. Which compilers for functional languages can perform this opt…

    (define (error . args) #f)
    (define (class x y z)
     (lambda (d)
      (case d ('x x) ('y y) ('z z) (else (error "Invalid slot ~a" d)))))

    (define obj (class 'this 'is-a 'test))
    (display (obj (read)))
    (newline)

The Stalin scheme compiler, if I read the output correctly, makes a separate type for 'x, 'y, and 'z. Then it does the dispatch using a switch statement (in the c code) over the three symbol types. This seems quite resonable to me; The C compiler will probably produce a jump table.

Note that I was unable to get the compiler to produce dispatch code at all without dispatching on the result of READ.

Re: Objects vs closures

#13

Post by noblethrasher » Wed, Dec 08, 2010, 6:18 PM UTC

A closure is also a poor man's class (sort of).

I've often wished that C# let me implement interfaces with anonymous classes. Since it doesn't, I get around it by creating AdHoc classes for interfaces that I use a lot.

For instance, if I have an interface Foo defined as:

    interface Foo
    {
        string Bar(int x);
    }

then I also create a corresponding class called AdHocFoo defined like so:

    class AdHocFoo : Foo
    {
        Func _bar;

        public AdHocFoo(Func bar)
        {
            _bar = bar;
        }

        public string Bar(int x)
        {
            return _bar(x);
        }

    }

I've written a little program that creates these AdHoc class definitions from interfaces.

Re: Objects vs closures

#14

Post by doki_pen » Wed, Dec 08, 2010, 8:21 PM UTC

I wish that _why didn't leave potion behind. One of the coolest thing about potion is that everything is a function. For example, if you have an integer named a that has a value of one, the a() will return 1. I hadn't seen that in any other language. Are there other languages with this feature?

Re: Objects vs closures

#15

Post by jpr » Wed, Dec 08, 2010, 8:39 PM UTC

beza1e1 wrote: post #7

"so closures can be, and are, used to implement very effective objects with multiple methods" I don't really believe this to be efficient. The linked text by Kiselyov implements the dispatch via Scheme's (case ...) expression. Efficient dynamic dispatch means one indirection through a vtable, so one load instruction more compared to a normal function call. Which compilers for functional languages can perform this opt…

Sufficiently Smart Compiler(tm) should be able to optimize `case` that switches only on a known set of symbols pretty well. Certainly not necessary to do hash-lookup.

Re: Objects vs closures

#16

Post by J3L2404 » Wed, Dec 08, 2010, 9:13 PM UTC

eru wrote: post #5

jaekwon wrote: post #2

I like the koan in the end. Now if only one can hit me in the head such that I understand the duality of electricity and magnetism...

Feynman explains it nicely in his lectures on physics. The key is relativity. (Magnetism is a relativistic effect of electricity.) http://en.wikipedia.org/wiki/Classical_electromagnetism_and_... may be interesting. Especially the section "Relationship between electricity and magnetism".

Can someone summarize how magnetism is a relativistic effect?

Re: Objects vs closures

#17

Post by swannodette » Thu, Dec 09, 2010, 4:28 AM UTC

supersillyus wrote: post #11

swannodette wrote: post #9

Earlier quoted context omitted.

Clojure. Clojure has a fairly interesting feature called reify: (defprotocol Foo (bar [this]) (baz [this])) (defn make-foo [a] (reify Foo (bar [this] a) (baz [this] a))) (dotimes [_ 10] (let [x (make-foo 'x)] (time (dotimes [_ 1e8] (bar x) (baz x)))) So 2 methods called 1 billion times only takes about ~500ms on my 2.66ghz i7 MacbookPro. (of course, Clojure prefers values+behaviors, aka objects, without mucking it up…

It seems very likely to me that the JVM is recognizing that "bar" and "baz" don't do anything and (after some warm-up) optimizing them away. Microbenchmarking JVM is hard.

Not true. Timings are completely different if you take a method out. I'm not saying that the JVM is not doing any magic here - but here is a closure that gets method dispatch as fast as the host can provide.

Re: Objects vs closures

#18

Post by weber88 » Thu, Dec 09, 2010, 5:24 AM UTC

J3L2404 wrote: post #16

eru wrote: post #5

Earlier quoted context omitted.

Feynman explains it nicely in his lectures on physics. The key is relativity. (Magnetism is a relativistic effect of electricity.) http://en.wikipedia.org/wiki/Classical_electromagnetism_and_... may be interesting. Especially the section "Relationship between electricity and magnetism".

Can someone summarize how magnetism is a relativistic effect?

The explanation given here is pretty decent:

http://en.wikipedia.org/wiki/Classical_electromagnetism_and_...

The main thing is to consider how charge densities change as we switch reference frames. Because the lengths contract when we switch to a reference frame where things are in motion, we see higher charge densities (same charge per less length).

A simple demonstration: Say we have a charge neutral, current carrying wire. We model it as a bunch of positive charges staying still, and some negative ones moving. The positive and neutral balance, but there is still a current because only the negatives are moving. Now imagine we switch to a different reference frame, one where the negative charges aren't moving, but the positive one's are, we are flying along parallel to the current. Now the positive charges contract relativisticly, so the density of positive charges is now greater than the negatives, and hence the wire appears to be carrying a net charge.

Re: Objects vs closures

#19

Post by supersillyus » Fri, Dec 10, 2010, 10:57 PM UTC

swannodette wrote: post #17

supersillyus wrote: post #11

Earlier quoted context omitted.

It seems very likely to me that the JVM is recognizing that "bar" and "baz" don't do anything and (after some warm-up) optimizing them away. Microbenchmarking JVM is hard.

Not true. Timings are completely different if you take a method out. I'm not saying that the JVM is not doing any magic here - but here is a closure that gets method dispatch as fast as the host can provide.

You're probably right. I took 500ms for 1B iterations and saw that you're looking at ~0.25ns a call, and that seemed a bit low. However, based on your code, you ran it 100M times, not 1B (1e8 vs 1e9). That changes it to 2.5ns per call. I ran the code on my machine (similar to yours, Macbook Pro 2.66ghz) with Clojure 1.2.0, and I got just over 2500ms for 1e8 iterations, which is about 12.5ns per call.

For comparison, looping 1e8 times with two calls to empty functions in a static language takes ~639ms, gives me ~3ns per call. So, you can see why my first suspicion was that the JVM was doing something like just inlining the methods and avoiding the call altogether. Considering the differences in our reported numbers, you may have a newer JVM than me, and if it is beating simple CALL instructions, it must be inlining them or avoiding some of the looping.