:(
--Robert McIntyre
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
Also: the benchmarks are totally a numbers game: throw idioms and readability out the window. Clojure 1.3 should be able to match Java performance if you basically write Java-in-Clojure. On Clojure 1.2 you will have to do stranger things to get there.
Stu
Has Clojure 1.3 been released?
If you choose to throw idioms and readability out the window thendon't be surprised at the comments that will be made about Clojure.
If you have to "do stranger things to get there" with Clojure 1.2 then
doesn't that simply suggest Clojure 1.2 performance doesn't match Java
performance?
No, but since the num/prim/equiv work specifically targets performance, we want to collect people's experiences comparing 1.2 and 1.3. This is totally separate from the benchmark submission process and for our own information.
>> Also: the benchmarks are totally a numbers game: throw idioms and readability out the window. Clojure 1.3 should be able to match Java performance if you basically write Java-in-Clojure. On Clojure 1.2 you will have to do stranger things to get there.
>
> If you choose to throw idioms and readability out the window then
> don't be surprised at the comments that will be made about Clojure.
Let me reduce the stridency of my previous statement: "throwing things out the window" is too strong. Benchmarks are a numbers contest, not a beauty contest. But, there's no saying the resulting programs will be ugly (or even non-idiomatic). Try things. Measure. It is simply the case that some idiomatic code (i.e. numeric code with no hints in the body) is faster in master/1.3 than in 1.2, and that some benchmark-useful things (fns taking/returning primitives) are available only post 1.2.
> If you have to "do stranger things to get there" with Clojure 1.2 then
> doesn't that simply suggest Clojure 1.2 performance doesn't match Java
> performance?
If I had wanted to suggest that, I would have said "you can't get there". With Clojure 1.2, you can get fast programs easily, or screaming-fast programs with effort. Some of the work in Clojure 1.3 reduces that effort.
Stu
The phrase "idiomatic code" often seems to be used to mean - codewritten in a natural way for that language and as if performance
doesn't matter - whereas I seem to have the strange notion that both
code written as if performance matters and code written as if
performance doesn't matter can be "idiomatic code".
I have a project that is development and will still be for some time.
I don't mind if it does not work perfectly before 1.3 and I will be
very happy to have it very fast when 1.3 is ready.
I am quite happy to make a branch to check improvement vs 1.2, but I
wouldn't know how to change my code to benefit from the features of
1.3.
Is there some links about that?
Are the prim/equiv work in master yet? And the :static defn with
primitives arg? And the protocols with primitive?
Are there other improvements?
I have a lot of primitives that are spread in a big part of the code,
so I think I would benefit from that?
Best,
Nicolas.
For most of the code, being slower (in a reasonable limit) is not
important if you are correct and easily maintable, and reusable.
(definterface BodyIsh
(^double getMass [])
(setMass [^double x])
(^double getPosX [])
.....)
(deftype Body [^double ^{:unsynchronized-mutable true} mass ^double
^{:unsynchronized-mutable true} posX .....]
BodyIsh
(getMass [x] mass)
(setMass [x m] (set! mass m)
.....)
And then rewriting the program using Body (and a type annotation on
bodies, of course)
I used interfaces and not protocols here because I am not sure 1.2
supports protocols with primitives.
Best,
Nicolas.
Sincerely
Meikel
Very interesting. Clojure is faster than several languages
(surprisingly so in some cases - at least for me) but seems to use
more code to express solutions - which really surprised me!
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
--
If that is the case, I doubt there is any choice for Haskell.
Huh ? point ? it was just a casual comment, no point was intended. And
I have read some comments by Don that what is in the shoutout is way
faster than Data.HashTable
>
>
>> And Data.HashTable also use some mutable array thing so it is still not
>> the idiomatic Haskell of everything is immutable.
>
> afaict idiomatic is everything referentially transparent not
> everything immutable, as in - "I needed a halfway decent mutable
> collection type – having a properly tested mutable collection that
> actually performs well would be a godsend."
>
how can you assure that(let's put aside the under the hood things
where it is done in C) if you break the assumption that value can be
changed.
BTW, it seems that to verteran Haskellers, the speed of Data.HashTable
is not a concern to them as they said they don't see the need of
that(mutable hasktable) in their usage. There seems to be a bug(as in
it is slow) filed for this package for quite a while but no one even
bother to attempt to improve it.
That was referring to the original comment about 'making a mutable
implementation' meaning the program itself ASKED for that particular
functionality. The one in the shoutout is one implementation of it,
the one in Data.HashTable is another. When I said no choice, I was
saying no choice but to implement a mutable hash table, in respond to
the underlying message of 'why did they implement a mutable hashtable'
as if making it mutable is only for performance purpose.
>
>
>> >> And Data.HashTable also use some mutable array thing so it is still not
>> >> the idiomatic Haskell of everything is immutable.
>>
>> > afaict idiomatic is everything referentially transparent not
>> > everything immutable, as in - "I needed a halfway decent mutable
>> > collection type – having a properly tested mutable collection that
>> > actually performs well would be a godsend."
>>
>> how can you assure that(let's put aside the under the hood things
>> where it is done in C) if you break the assumption that value can be
>> changed.
>
>
> Reading the first paragraph "Introduction to Uniqueness Typing" of
> this paper should help you with that question -
>
> http://www.st.cs.ru.nl/papers/2008/vrie08-IFL07-UniquenessTypingSimplified.pdf
>
>
Would try to digest that.
> I'm not going to speculate about what unnamed "verteran Haskellers"
> have or have not said.
>
> Read the bug report and you'll see that the root problem was GC - do
> you think changing GC is a quick fix?
>
Don suggested on reddit for some fixes that tackle the GC issue(not
changing the GC, but the way to get around the performance caused by
GC), using similar approach as in the shoutout.
I know they did it to get a faster program, but under the requirement of :
IT MUST BE MUTABLE HASHTABLE
If you change the requirement to something else that acheives the end
result without this specific requirement, they may not use hashtable
at all. Which is also the message I get from various place like reddit
or stackoverlow about this same issue. That is 'use your language's
strength to solve the problem, not to mimic other language, i.e. the
what not the how'.
And this sentiment is not unique to Haskell. I recently saw similar
questions on J language of 'how can I write a Haskell style
filter(HOF)', the overall answers there are 'you don't need haskell
style filter and can achieve the same result in a J way'. Similarly
for Haskell which is 'you don't need to use mutable hash table and can
very likely get the same result using other immutable data structure'
But in this case the problem is 'implement a mutable hashtable' which
is what my 'no choice' was referring to. Unlike language say Python or
F# where hash table is in general considered to be part of the
language, Data.HashTable is not. It is just one 'sample' of
implementation of mutable hash table which happens to be slow.
I read this part, trying to fit that into this mutable hashtable
context. Below this paragraph, it mentioned some
requirement/assumption that file0, file1 ... cannot be 're-used' which
I don't know how to apply to hashtable.
You mean the why not Data.Hashtable comment ? I don't think so.
>
> If you change the requirement to something else you'd simply be
> missing the point - which was to look at hashtable updates and
> strings.
I know perfectly well what you want to measure and I was not implying
if those measure is valid or not, I am totally neutral to the whole
thing.
My initial comment was all about 'it seems that Haskell submission is
not the typical elegant form' and to me because of the specific you
want to measure, there is no acceptable elegant Haskell form.
>
> Does it actually say that the hashtable updates have to be
> destructive?
If want to go that route, be my guest.
> There's no choice in binary-trees either - you must use binary-trees
> and you must allocate all the memory.
>
> There's no choice in pi-digits either - you must use that particular
> step-by-step spigot algorithm taken from that Haskell paper.
>
> There's no choice in fannkuch-redux either - you must use that
> particular ordering of permutations taken from that Lisp paper.
>
> etc etc
Indeed. Your benchmark suite are very specific about how certain
things must be done in order to measure a specific aspect you want to
measure.
>
> Forgive me but you do seem to be belabouring the obvious.
>
I think you are too sensitive
For real life cases, call an exnternal library, use another language,
transform the solution into something that would not hit the weak
point of the language(I recently saw an example of this on J about a
simple but interesting quiz).
>
>
>> > Does it actually say that the hashtable updates have to be
>> > destructive?
>>
>> If want to go that route, be my guest.
>
> I don't understand what you mean, didn't you say - it must be a
> mutable hashtable?
>
> Why couldn't it be a hashtable that copied values?
As I said, be my guest.
>
>
>> Indeed. Your benchmark suite are very specific about how certain
>> things must be done in order to measure a specific aspect you want to
>> measure.
>
> The other complaint is that it's not specific enough and allows too
> much play, with programs in one language being too different to
> programs in other languages.
>
not sure what you want to say.