CPUs are slower than X86 CPUs (especially for FP); the timing
numbers won't be comparable. But the locking bottlenecks should be
the same.
If you want to do this, email me cliffc at acm.org with a library
tarball and a *bare* java command line - no scripts please as I have
to replace the java comma
A bunch of separate real concerns here:
---
On the issue of STM Slowdown:
- Clojure is typically slower than Java by an interesting amount when
doing Plain Olde Java Stuff, unless great care is taken (it's possible
to take great care). Such a slowdown matters less than the ability t
Some generic STM bits of wisdom:
- STMs in "standard" languages (e.g. C, C++) suffer from having to
track all memory references. THis overhead means the STM code
typically starts 3x to 10x slower than non-STM code, which is a pretty
stiff penalty to recover from. If you're only getting a 3x spe
As a compiler writer I do a lot of graph-work, but nearly all of it
has cycles.
There was a thread earlier about defining cyclic graphs in Clojure.
Can someone point me to it?
Thanks,
Cliff
On Feb 22, 7:55 am, Rich Hickey wrote:
> On Feb 22, 2009, at 10:11 AM, Jeffrey Straszheim wrote:
>
> > J
I think TCO is very doable and likely to appear in some common JVMs at
some point.
Continuations, on the other hand, are likely to require a massive
infrastructure overhaul.
Cliff
On Jan 26, 4:38 am, Rich Hickey wrote:
> On Jan 26, 3:20 am, Konrad Hinsen wrote:
>
> > On 25.01.2009, at 21:33,
fyi... non of the bytecode machines made much headway; once you get
above a certain (actually fairly small) size device you can afford a
tiny JIT - and even a trivial JIT instantly blows away pure bytecode
interpreters; to the point that the energy consumed is actually less
even counting the JIT c
Some comments:
1- If you think that HotSpot/Java is slower than C++ by any
interesting amount, I'd love to see the test case. Being the
architect of HotSpot "-server" I've a keen interest in where
performance isn't on par with C. Except for a handful of specialized
uses (e.g. high-level interpr
HotSpot folds FP constants in a few rare cases, and I don't thing
Math.log is one of them. For instance you can't fold "x+0.0" into "x"
in case "x" happens to be negative 0. Math.log is a pure function so
it would be possible, but I don't think it made the short-list of hot
FP functions to optim
On Nov 4, 10:53 am, Rich Hickey <[EMAIL PROTECTED]> wrote:
> Once detected, a deadlock can still be a bear to reproduce/debug, and
> often does not appear until the worst possible time - production.
So far, my experience (both direct & observed from others) with
deadlocks has been:
- indeed you
> Hi Cliff,
> It was great meeting you at the JVM Summit - I learned a lot, thanks!
> I know the test is over, but wanted to get you a version of your simple test
> that demonstrates Clojure's ability to get to the metal on primitive numerics
> when given type hints.
> Attached is a new clojure.
log nil "Hello World!")
>
> both versions work here (standard OSX Java).
>
> $ java -version
> java version "1.5.0_13"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-
> b05-237)
> Java HotSpot(TM) Client VM (build 1.5.0_13-119, mixed mode, s
I downloaded clojure to my pc. I tried the "Getting Started" page:
user=> (+ 1 2 3)
6
Worked great... next step:
user=> (. javax.swing.JOptionPane (showMessageDialog nil "Hello
World"))
This hangs for me; the java process is idle. No output, no dialog box
or GUI. I'm using HotSpot 1.6
I downloaded clojure to my pc. I tried the "Getting Started" page:
user=> (+ 1 2 3)
6
Worked great... next step:
user=> (. javax.swing.JOptionPane (showMessageDialog nil "Hello
World"))
This hangs for me; the java process is idle. No output, no dialog box
or GUI.
I'm using HotSpot 1.6.0
13 matches
Mail list logo