Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Clojure vs Java speed (was: Alternatives to C)

Reply
Thread Tools

Clojure vs Java speed (was: Alternatives to C)

 
 
fft1976
Guest
Posts: n/a
 
      07-29-2009
On Jul 28, 9:46*pm, Oxide Scrubber <(E-Mail Removed)> wrote:

> >> fft1976 wrote:
> >>> Java: 1.5x slower than C as a rule of thumb.
> >> I think it can achieve parity.

>
> > I disagree. I don't think the JIT can do much about the memory layout
> > of the data structures. Compare a vector of complex numbers or of 3D
> > vectors (NOT of pointers to them) in C/C++ and Java. Run some tests. I
> > did and I looked at others'.

>
> > For me, 1.5x is a good trade-off for safety though.

>
> The JIT can't, but the coder can. If you want a vector of N
> double-precision complex numbers in Java that is contiguous in memory,
> for example, you could use a Java array of 2xN doubles and index into it
> appropriately.


This is fanboy fantasy, not reality. If I have a library for dealing
with 3D vectors, I'm not going to lay out my data in flat arrays and
copy the vectors back and forth. Also, this trick won't work with non-
homogeneous records.

> >> With Java, in most cases you can slap "implements Cloneable" on a
> >> class and make the clone method public,

>
> > Java's "clone" does a shallow copy only (check the docs).

>
> True. If you want a deep copy you will have to implement it yourself.


That's what I wrote. What was the point of your comment?


> Or
> you can make a deepCopy static utility method that exploits
> "Serializable" to deep copy anything that's serializable simply by
> serializing and deserializing it (which can use memory, or a temp file,
> and not much memory if you make an auxiliary class implement both
> InputStream and OutputStream, with its OutputStream methods writing to a
> growable buffer and its InputStream methods consuming (possibly blocking
> if necessary) from same. Closing the OutputStream aspect EOFs the
> InputStream aspect. Then wrap in ObjectInput/OutputStream. You can use a
> BlockingQueue of byte arrays of length 8192 (or whatever), serialize to
> one end and deserialize from the other in concurrent threads, and it
> will tend to not use much memory. Limit the BlockingQueue length to 1
> item and it will never use much more than 8Kbyte (the OutputStream
> aspect will block until the InputStream aspect consumes from the queue).


Ouch...

> If the bulk of the time is spent performing arithmetic operations on
> just a few values,


We are talking number crunching here, not useless ****ing contests,
like calculating the digits of Pi.

> If the arithmetic is bignum, the bulk of your time will be spent
> performing individual bignum operations.


Contrary to what the term sounds like, number crunching is rarely
about bignums.

> If the arithmetic is on smallnums in arrays and the computations are
> mostly mutations, then you may want to use Java arrays,


That's what I said.

> In practice,
> Clojure access to Java arrays, even primitive arrays, seems to
> be slow. This may be addressed in a future version.


Yeah, yeah...

I noticed that you decided to delete this, by the way:

In practice, experts seem to
agree that Clojure is 5-10 times slower than Java:

http://groups.google.com/group/cloju...b33476c0507478

(relevant follow-up set)
 
Reply With Quote
 
 
 
 
SG
Guest
Posts: n/a
 
      07-29-2009
On 29 Jul., 07:55, fft1976 <(E-Mail Removed)> wrote:
> On Jul 28, 9:46*pm, Oxide Scrubber <(E-Mail Removed)> wrote:
>
> > The JIT can't, but the coder can. If you want a vector of N
> > double-precision complex numbers in Java that is contiguous in memory,
> > for example, you could use a Java array of 2xN doubles and index into it
> > appropriately.

>
> This is fanboy fantasy, not reality. If I have a library for dealing
> with 3D vectors, I'm not going to lay out my data in flat arrays and
> copy the vectors back and forth. Also, this trick won't work with non-
> homogeneous records.


Agreed. I can confirm that C++ is much better for my kind of number
chrunching tasks. I have to solve big nonlinear optimization problems
and switched from Java to C++ two years ago. I'm not looking back. The
ability to write user-defined types that are handled like builtin
types (no indirection, no heap allocations) combined with "true
genericity" is key.

> > In practice,
> > Clojure access to Java arrays, even primitive arrays, seems to
> > be slow. This may be addressed in a future version.


Are we talking about the language "Clojure" (lisp dialect) or the
cloSure proposal for Java 7?

Cheers!
SG
 
Reply With Quote
 
 
 
 
Oxide Scrubber
Guest
Posts: n/a
 
      07-29-2009
fft1976 failed for the second time to respect the Followup-To header:
> On Jul 28, 9:46 pm, Oxide Scrubber <(E-Mail Removed)> wrote:
>
>>>> fft1976 wrote:
>>>>> Java: 1.5x slower than C as a rule of thumb.
>>>> I think it can achieve parity.
>>> I disagree. I don't think the JIT can do much about the memory layout
>>> of the data structures. Compare a vector of complex numbers or of 3D
>>> vectors (NOT of pointers to them) in C/C++ and Java. Run some tests. I
>>> did and I looked at others'.
>>> For me, 1.5x is a good trade-off for safety though.

>> The JIT can't, but the coder can. If you want a vector of N
>> double-precision complex numbers in Java that is contiguous in memory,
>> for example, you could use a Java array of 2xN doubles and index into it
>> appropriately.

>
> This is fanboy fantasy, not reality.


Stop attacking me. I have done nothing to deserve your repeated flamage.
You must have the wrong target. Recheck and then go flame the correct
target.

> If I have a library for dealing with 3D vectors, I'm not going to lay
> out my data in flat arrays and copy the vectors back and forth.


If you have a library for dealing with X, in any language, you'll use
the data as laid out by that library.

A performant Java library for numerics should lay out its data in an
appropriate manner so as to achieve performance, of course.

> Also, this trick won't work with non-homogeneous records.


It will work for records of a primitive type, such as double. It won't
work if for some odd reason you want to mix ints and doubles in the same
vector, no. In that unusual case you may be better off either using
multiple separate arrays, but allocated one right after the other so
probably close together, one with all the ints and one with all the
doubles, or else resorting to JNI to implement some things.

>>>> With Java, in most cases you can slap "implements Cloneable" on a
>>>> class and make the clone method public,
>>> Java's "clone" does a shallow copy only (check the docs).

>> True. If you want a deep copy you will have to implement it yourself.

>
>> Or
>> you can make a deepCopy static utility method that exploits
>> "Serializable" to deep copy anything that's serializable simply by
>> serializing and deserializing it (which can use memory, or a temp file,
>> and not much memory if you make an auxiliary class implement both
>> InputStream and OutputStream, with its OutputStream methods writing to a
>> growable buffer and its InputStream methods consuming (possibly blocking
>> if necessary) from same. Closing the OutputStream aspect EOFs the
>> InputStream aspect. Then wrap in ObjectInput/OutputStream. You can use a
>> BlockingQueue of byte arrays of length 8192 (or whatever), serialize to
>> one end and deserialize from the other in concurrent threads, and it
>> will tend to not use much memory. Limit the BlockingQueue length to 1
>> item and it will never use much more than 8Kbyte (the OutputStream
>> aspect will block until the InputStream aspect consumes from the queue).

>
> Ouch...


No ouch. You'd only have to do this once, and then deepCopy would work
on every serializable type in Java, including ones that didn't exist
when you wrote deepCopy.

>> If the bulk of the time is spent performing arithmetic operations on
>> just a few values,

>
> We are talking number crunching here


Yes, I know.

>> If the arithmetic is bignum, the bulk of your time will be spent
>> performing individual bignum operations.

>
> Contrary to what the term sounds like, number crunching is rarely
> about bignums.


I never said otherwise.

>> If the arithmetic is on smallnums in arrays and the computations are
>> mostly mutations, then you may want to use Java arrays,

>
> That's what I said.


Now that the debate is over, please respect the followup-to header.

It would have been better, of course, had you chose to end it *before*
demonstrating to the entire world that you're unimaginative and
ignorant. Ignorant of numerous performance tricks for Java and other JVM
languages, ignorant of performant functional algorithms for various
things, and ignorant of the actual facts from timing operations, which
show all three languages capable of achieving the same top speed in
numeric calculations. And unimaginative enough not only to be unable to
think up any of these things, but also unable to think up arguments that
aren't laced heavily with ad hominems and other rhetoric. "This is
fanboy fantasy, not reality," "What was the point of your comment?,"
"Ouch...," "We are talking number crunching here, not useless ****ing
contests," "Yeah, yeah...," and so forth do not constitute rational
arguments.
 
Reply With Quote
 
Oxide Scrubber
Guest
Posts: n/a
 
      07-29-2009
SG wrote:
> On 29 Jul., 07:55, fft1976 <(E-Mail Removed)> wrote:
>> On Jul 28, 9:46 pm, Oxide Scrubber <(E-Mail Removed)> wrote:
>>> The JIT can't, but the coder can. If you want a vector of N
>>> double-precision complex numbers in Java that is contiguous in memory,
>>> for example, you could use a Java array of 2xN doubles and index into it
>>> appropriately.

>> This is fanboy fantasy, not reality. If I have a library for dealing
>> with 3D vectors, I'm not going to lay out my data in flat arrays and
>> copy the vectors back and forth. Also, this trick won't work with non-
>> homogeneous records.

>
> Agreed. I can confirm that C++ is much better for my kind of number
> chrunching tasks. I have to solve big nonlinear optimization problems
> and switched from Java to C++ two years ago. I'm not looking back. The
> ability to write user-defined types that are handled like builtin
> types (no indirection, no heap allocations) combined with "true
> genericity" is key.
>
>>> In practice,
>>> Clojure access to Java arrays, even primitive arrays, seems to
>>> be slow. This may be addressed in a future version.

>
> Are we talking about the language "Clojure" (lisp dialect) or the
> cloSure proposal for Java 7?


The former.

And since you clearly didn't even know what "Clojure" was referring to,
your claims that C++ is necessarily "much better" ring hollow.

In fact, Clojure, having macros and access to Java arrays, is capable of
working with contiguous blocks of doubles or similarly and treating
them as structured into discrete complex numbers, vectors, or
what-have-you, and is capable of "true genericity". Lisps in general are
much more capable of "true genericity" than C++ is.

Even Java can be made to perform at C-like speeds with suitable
structuring of your data; it's just that you can't always encapsulate
that data into discrete Java objects and keep that performance.
Although, objects allocated sequentially tend to be allocated at
close-together memory locations in Java, and the new G-1 garbage
collector should help further with keeping objects that are used
together close together in memory, improving locality of memory access
patterns.

Regardless, actual benchmark numbers show all three languages achieving
comparable speeds at comparable numerical tasks, IF the code in each
language is performance-tuned by someone reasonably expert in the use of
that language. Of course, when an ignoramus such as either of the
preceding posters, who clearly know only the bare bones about Java and
nothing at all about Clojure, attempt to write performant code in those
languages, they can expect to do poorly.

And of course, the savings from using a smart algorithm beat a
few-percent or even a few-tens-of-percent difference in raw execution
speed anyday.

(defn fib[n]
(nth (map second (iterate (fn [[a b]] [b (+ a b)]) [0 1])) n))

in clojure will be hugely faster than

int fib (int n) {
if (n == 0 || n == 1) return 1;
return fib(n - 1) + fib(n - 2);
}

anyday. (And won't wrap after 1836311903, or, worse, after 28657, either.)
 
Reply With Quote
 
fft1976
Guest
Posts: n/a
 
      07-29-2009
On Jul 29, 1:18*am, Oxide Scrubber <(E-Mail Removed)> wrote:
> fft1976 failed for the second time to respect the Followup-To header:
>


Everyone who decides to reply to this joker, watch out: he's silently
adding "Followup-To: alt.olympics" to his messages, trying to trick
you into not posting here, so he would have the last word.

Is this what Clojure fanboys must resort to when they lose an
argument? I thought Haskell and Common Lisp had the worst fanboys till
today.
 
Reply With Quote
 
Oxide Scrubber
Guest
Posts: n/a
 
      07-29-2009
fft1976 wrote:
> On Jul 29, 1:18 am, Oxide Scrubber <(E-Mail Removed)> wrote:
>> fft1976 failed for the second time to respect the Followup-To header:

>
> Everyone who decides to reply to this joker, watch out: he's silently
> adding "Followup-To: alt.olympics" to his messages


No, I am not. I am adding a followup-to for atl.olympics. (Note spelling.)

It's currently an empty newsgroup, so it seemed appropriate as a place
to redirect your useless and illogical flamage.

> Is this what Clojure fanboys must resort to when they lose an
> argument?


I wouldn't know, since that's never happened to me.
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      07-29-2009
fft1976 wrote:
> On Jul 29, 1:18 am, Oxide Scrubber <(E-Mail Removed)> wrote:
>> fft1976 failed for the second time to respect the Followup-To header:
>>

>
> Everyone who decides to reply to this joker, watch out: he's silently
> adding "Followup-To: alt.olympics" to his messages, trying to trick
> you into not posting here, so he would have the last word.
>
> Is this what Clojure fanboys must resort to when they lose an
> argument? I thought Haskell and Common Lisp had the worst fanboys till
> today.


fft1976 is the one who "silently" decided to drag this flamewar into
clj.programmer. We were doing just fine without it.

f/u set to comp.programming and please keep your flamewar out of clj groups.

--
Lew
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      07-30-2009
Oxide Scrubber wrote:
> fft1976 wrote:
>> Is this what Clojure fanboys must resort to when they lose an
>> argument?

>
> I wouldn't know, since that's never happened to me.


Thanks for that very informative comment !



Arne
 
Reply With Quote
 
fft1976
Guest
Posts: n/a
 
      07-30-2009
On Jul 29, 12:24*pm, Jon Harrop <(E-Mail Removed)> wrote:

> > This is fanboy fantasy, not reality.

>
> Yes. Clojure has some nice features but its most serious deficiencies are
> inherited from the JVM and there is nothing Clojure can do about it, e.g.
> value types and TCO.


Not as far as speed is concerned, in practice. If you give up 1.5x
speed by going from C++ to Java, and 5-10 by going from Java to
Clojure [1], than the latter is much more relevant.

I actually think 1.5x is a good trade for memory safety, as I stated.
It's beyond me why this "(E-Mail Removed)" fella decided to argue
about it, when he obviously knows nothing about number crunching. What
a nut case.

[1] http://groups.google.com/group/cloju...b33476c0507478
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      07-30-2009
fft1976 wrote:
> I actually think 1.5x is a good trade for memory safety, as I stated.
> It's beyond me why this "(E-Mail Removed)" fella decided to argue
> about it, when he obviously knows nothing about number crunching. What
> a nut case.


Flame war, flame war, flame war. Go on to comp.programming and have a great time.

--
Lew
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Clojure based objects rahul Perl Misc 4 12-08-2009 12:03 PM
Re: Ants: Clojure vs. Common Lisp fft1976 Java 7 06-19-2009 08:37 AM
Apache Tapestry Creator to Speak on Clojure, Tapestry 5 Shaguf Ruby 0 12-11-2008 11:06 AM
Re: what do lispers think of clojure? Xah Lee Java 18 11-28-2008 02:00 AM



Advertisments