Could a CAML derivative language for the JVM gain the same traction that F# is
gaining on .NET?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e
--~--~-~--~~~---~--~~
You received this message because you are subscribed
On Sunday 11 November 2007 15:34, David MacIver wrote:
On Nov 11, 2007 1:54 PM, Jon Harrop [EMAIL PROTECTED] wrote:
Explicit types also have disadvantages. I think it is only fair to
consider both approaches.
Certainly. I'm perfectly willing to consider implicit types as a
valuable thing
On Sunday 20 April 2008 14:50:25 Jon Harrop wrote:
Running the SciMark benchmark on my 32-bit WinXP Athlon64 X2 4400+ 2Gb RAM
machine:
Sun JDK 6: 385
.NET 3.5: 367
Here .NET is 5% slower than the JVM.
I hadn't actually noticed that the .NET port of SciMark was written by a Java
On Tuesday 22 April 2008 08:39:03 hlovatt wrote:
@John,
Your benchmarking does not seem consistent with this paper:
http://www.orcca.on.ca/~ldragan/synasc2005/2005-synasc-scigmark-final.pdf
They show Java faster than C# on most of the benchmarks in the SciMark
suite. But not the Monte
On Tuesday 22 April 2008 12:49:16 Antonio Cuni wrote:
Jon Harrop wrote:
You generated code that turned out to be less efficient on the CLR in
this particular case but you cannot validly generalize that to all
non-standard code.
right, I can't generalize to all non-standard code, but it's
On Thursday 24 April 2008 19:08:53 Charles Oliver Nutter wrote:
Ola Bini wrote:
My top five:
JRuby
Scala
Clojure
ioke
Duby.
You want justifications for those? =)
No, but how about a description and status update for ioke I can use in
the talk :)
I'd appreciate any
On Friday 25 April 2008 02:05:50 hlovatt wrote:
- are you certain you are running the right benchmarks?
Yes. And I have run them on more than one machine and obtained the same
results.
I also found a bug in the SciGMark code, specifically the C++ was printing the
wrong score for the MultPoly
On Friday 25 April 2008 12:08:25 David MacIver wrote:
On Fri, Apr 25, 2008 at 11:49 AM, easieste [EMAIL PROTECTED]
wrote:
And I would put 'Fortress' up there, but I don't know if Sun has
released easily inspectable source code yet.
They have, but Fortress probably shouldn't really be
On Friday 25 April 2008 21:54:57 John Rose wrote:
At the risk of prolonging the benchmark battle, I have to admit that
scimark is not the sort of app. I had in mind when I was bragging
about the JVM earlier on this thread.
Ah, I see. Can you cite a more suitable benchmark?
--
Dr Jon D
On Sunday 11 January 2009 03:04:46 Charles Oliver Nutter wrote:
Jon Harrop wrote:
Wonderful. I wanted to benchmark a Java version against my OCaml/LLVM and
F#/CIL versions. Thanks!
Looking forward to seeing that and other comparisons! We shall band
together to make sure BF/JVM
On Wednesday 28 January 2009 09:48:09 David Welton wrote:
There's also http://langpop.com/ which is very up-front about its
methodology -Tim
Yeah, that's mine, thanks for mentioning it!
Can you add F#, Scala and Clojure, please?
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http
was also
surprised to discover huge variations in the amount of widely-used code
written in similarly-popular languages, i.e. some language communities churn
out huge numbers of libraries that nobody ever uses.
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
As I understand it, the implementation of tail calls in OpenJDK is complete
but Sun are not adding this feature to their JVM. Is that correct?
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
--~--~-~--~~~---~--~~
You received
of the strongest selling points of the JVM.
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups JVM
Languages group.
To post to this group, send email
On Thursday 02 April 2009 15:36:38 kirk wrote:
Jon Harrop wrote:
On Thursday 02 April 2009 15:09:12 Charles Oliver Nutter wrote:
It's not necessarily Sun's choice when it exhibits external behavioral
changes. Such changes must be standardized so all JVMs will support
them. If it were
On Thursday 02 April 2009 20:19:14 Charles Oliver Nutter wrote:
Jon Harrop wrote:
The problem is not my building and installing a custom JDK and testing it
to make sure that it is reliable myself. The problem is that requiring
customers to do that is such a substantial barrier to adoption
calls back into Kawa, where does Kawa get the current CallContext
from when it has not been passed in as the first argument?
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
--~--~-~--~~~---~--~~
You received this message because you
is not statically known. So
that program cannot be written correctly in Scala or Clojure.
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
On Friday 03 April 2009 06:31:38 Charles Oliver Nutter wrote:
Jon Harrop wrote:
You mean if I wanted to tinker with it? Sure, but there is little point
in me running it if my customers will not.
So you're really not looking for a solution then, unless it's someone
else (Sun) putting
On Friday 03 April 2009 14:59:03 Charles Oliver Nutter wrote:
Jon Harrop wrote:
If you cannot get tail calls accepted into the required standard, then
release an additional non-standard JVM that includes the existing
implementation of tail call elimination (and potentially other useful
On Friday 03 April 2009 15:51:22 Antonio Cuni wrote:
Jon Harrop wrote:
If you want to see how much of a benefit tail calls are in practice, look
at .NET (which has had them for the best part of a decade).
.NET tail calls are totally inefficient.
totally inefficient vs broken.
--
Dr Jon
person on Earth you should listen to in this context.
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups JVM
Languages group.
To post
On Thursday 23 April 2009 21:18:50 John Cowan wrote:
On Thu, Apr 23, 2009 at 12:52 PM, Jon Harrop j...@ffconsultancy.com wrote:
http://neopythonic.blogspot.com/2009/04/tail-recursion-elimination.html
Not worth reading. Guido has absolutely no idea what he is talking about
need to reimplement a mini-heap local to your
thread and that is left up to the user on VMs like the JVM and CLR.
JVM-based languages could perform the same inlining and use monomorphization
to avoid type erasure but the lack of value types is an insurmountable on the
JVM.
--
Dr Jon Harrop
On Friday 20 November 2009 02:30:13 Daniel Hicks wrote:
On Nov 16, 7:33 pm, Jon Harrop j...@ffconsultancy.com wrote:
I see allocation as contention because the heap is a global shared
resource. If you want to recover the performance of the previous
generation of standalone languages
On Tuesday 17 November 2009 04:14:10 Charles Oliver Nutter wrote:
On Mon, Nov 16, 2009 at 7:33 PM, Jon Harrop j...@ffconsultancy.com wrote:
I see allocation as contention because the heap is a global shared
resource. If you want to recover the performance of the previous
generation
the OCamlJava project that tries to run OCaml on the
JVM:
http://ocamljava.x9c.fr/
To the best of my knowledge, this project is also almost entirely unused.
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
--
You received this message because you are subscribed
benchmarked a hand-rolled JVM-based float-float hash table
against .NET's default one but the JVM is incapable of expressing value types
including entries in a hash table so you're probably still taking an
unnecessary performance hit.
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http
On Monday 30 November 2009 18:48:36 Charles Oliver Nutter wrote:
On Fri, Nov 20, 2009 at 10:54 PM, Jon Harrop j...@ffconsultancy.com wrote:
I was referring to a thread local *heap* rather than a generation. For
example, linked lists held as an array of cons cells where tails are
indexes
annotation
that makes type parameters acts as templates. I suppose they box /
unbox primitives in method signatures that uses the type parameters
though
I see.
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
--
You received this message because you are subscribed
On Monday 07 December 2009 18:31:55 John Cowan wrote:
On Mon, Dec 7, 2009 at 2:19 PM, Jon Harrop j...@ffconsultancy.com wrote:
The JVM is incapable of expressing structs so no JVM-based language can
support them. CLR-based languages supporting structs (e.g. C# and F#)
simply delegate
forthcoming option may be VMKit, which is a JVM and CLR built upon LLVM
(which provides TCO so it should be relatively easy to add if it has not been
done already). Or, of course, use or build a completely different VM already
provides TCO...
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http
and TCO can delete that stack frame.
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
--
You received this message because you are subscribed to the Google Groups JVM
Languages group.
To post to this group, send email to jvm-langua...@googlegroups.com
On Tuesday 08 December 2009 18:24:30 John Cowan wrote:
On Tue, Dec 8, 2009 at 9:53 AM, Jon Harrop j...@ffconsultancy.com wrote:
If you want JVM+TCO then you should already be able to use OpenJDK.
Another forthcoming option may be VMKit, which is a JVM and CLR built
upon LLVM (which provides
them by using the same workarounds that FPLs targetting C
have used (i.e. goto when possible and trampolines otherwise). They'll just
be slow and uninteroperable but lots of things are already slow because of
the lack of structs which cannot be worked around.
--
Dr Jon Harrop, Flying Frog
35 matches
Mail list logo
