Nice chart. Let's get real work done now.
On Nov 7, 2012, at 1:40 PM, Ray Racine wrote:
> Personally I'm am far less interested in ball-park performance positioning
> between Racket and some Scheme. Nice as they all are, and I've personally
> spent time with all of them. Larceny, our summer
Personally I'm am far less interested in ball-park performance positioning
between Racket and some Scheme. Nice as they all are, and I've personally
spent time with all of them. Larceny, our summer fling was special. I'll
never forget you.
Let's talk Heavy Weight Division here: Racket - Haskell
Guys:
- Gambit is awesome (and not just because the name is so cool)
- LLVM is a worthy project; one from academia even!
- Benchmarks don't really say much about a language implementation.
Lets not get too excited.
Thanks,
Robby
On Tue, Nov 6, 2012 at 9:53 AM, Neil Van Dyke wrote:
> (CC
(CC list trimmed.)
Greg Hendershott wrote at 11/06/2012 10:22 AM:
It sounds like this is morphing into benchmarking C compilers?
I think architecting a compiler to target the wildly popular GCC, as the
default configuration, is totally fair.
Sounds like Apple pulled a switcheroo, broke
f Gambit.
>>
>>
>> Message: 1
>> Date: Mon, 5 Nov 2012 08:09:19 -0500
>> From: Sam Tobin-Hochstadt
>> To: Matthew Flatt
>> Cc: "users@racket-lang.org"
>> Subject: Re: [racket] translate from Racket to Common Lisp
>> Message-ID:
>&
t; of Gambit.
>
>
> Message: 1
> Date: Mon, 5 Nov 2012 08:09:19 -0500
> From: Sam Tobin-Hochstadt
> To: Matthew Flatt
> Cc: "users@racket-lang.org"
> Subject: Re: [racket] translate from Racket to Common Lisp
> Message-ID:
>
> Content-Type: tex
: Sam Tobin-Hochstadt
To: Matthew Flatt
Cc: "users@racket-lang.org"
Subject: Re: [racket] translate from Racket to Common Lisp
Message-ID:
Content-Type: text/plain; charset=UTF-8
It's impressive to note the change in relative performance for Racket
over past 3 years since yo
On 05/11/2012 19:14, Asumu Takikawa wrote:
A follow-up blog post detailing what's improved performance-wise would
be great.
Indeed, speed is an important point for many people choosing a PL
implementation. And it's becoming even more important with ubiquitous
virtualisation and energy conside
On 2012-11-05 08:09:19 -0500, Sam Tobin-Hochstadt wrote:
> It's impressive to note the change in relative performance for Racket
> over past 3 years since you published the benchmarks on the blog --
> Racket has gone from slower than Gambit on the majority of benchmarks,
> sometimes by a significan
Indeed thank you Matthew! But it's hard to thank all of you enough for this
amazing piece that is Racket (and all that revolves around it), and the
support that comes with it.
Laurent
On Mon, Nov 5, 2012 at 3:18 PM, Matthias Felleisen wrote:
>
> On Nov 5, 2012, at 8:09 AM, Sam Tobin-Hochstadt w
On Nov 5, 2012, at 8:09 AM, Sam Tobin-Hochstadt wrote:
> It's impressive to note the change in relative performance for Racket
> over past 3 years since you published the benchmarks on the blog --
> Racket has gone from slower than Gambit on the majority of benchmarks,
> sometimes by a significan
... which of course just means that the 'unsafe' implementation exposes a
weakness in the programmer's reasoning while the Typed Racket implementation
appears to achieve the same level of performance as UNSAFE SBCL *with a proof*
that it is safe.
Thanks this is a nice confirmation of our work
On Mon, Nov 5, 2012 at 7:58 AM, Matthew Flatt wrote:
> At Sun, 4 Nov 2012 21:03:15 -0500, Sam Tobin-Hochstadt wrote:
>> > but, anyway... I think
>> > that benchmark turns out to measure mostly allocation. Racket in 32-bit
>> > mode, where pair and vectors take up half as much space, runs almost
>>
At Sun, 4 Nov 2012 21:03:15 -0500, Sam Tobin-Hochstadt wrote:
> > but, anyway... I think
> > that benchmark turns out to measure mostly allocation. Racket in 32-bit
> > mode, where pair and vectors take up half as much space, runs almost
> > twice as fast as Racket in 64-bit mode.
>
> Is the Gambi
On Sun, Nov 4, 2012 at 8:51 PM, Matthew Flatt wrote:
> At Sun, 4 Nov 2012 20:35:30 -0500, Sam Tobin-Hochstadt wrote:
>> Do you have a sense of why Racket performs poorly on the `paraffins`
>> benchmark?
>
> I wouldn't go so far as "poor" for that result,
I only ventured that characterization beca
On Sun, Nov 4, 2012 at 8:48 PM, Robby Findler
wrote:
> I think it is difficult to see that those integers do not escape
> fixnum range. :)
In particular, we can learn from the Online Encyclopedia of Integer
Sequences that they escape Racket's fixnum range on a 32 bit machine
like the one I'm typi
At Sun, 4 Nov 2012 20:35:30 -0500, Sam Tobin-Hochstadt wrote:
> Do you have a sense of why Racket performs poorly on the `paraffins`
> benchmark?
I wouldn't go so far as "poor" for that result, but, anyway... I think
that benchmark turns out to measure mostly allocation. Racket in 32-bit
mode, wh
I think it is difficult to see that those integers do not escape
fixnum range. :)
On Sun, Nov 4, 2012 at 7:42 PM, Matthias Felleisen wrote:
>
> Hmph. I would expect TR to perform as fast as 'unsafe'.
>
>
> On Nov 4, 2012, at 7:40 PM, Matthew Flatt wrote:
>
>> 2668 msecs when I declare `cycle-leng
I tried using the type `(Fixnum -> Fixnum)', but there's a
multiplication in the function.
At Sun, 4 Nov 2012 20:42:48 -0500, Matthias Felleisen wrote:
>
> Hmph. I would expect TR to perform as fast as 'unsafe'.
>
>
> On Nov 4, 2012, at 7:40 PM, Matthew Flatt wrote:
>
> > 2668 msecs when I dec
Hmph. I would expect TR to perform as fast as 'unsafe'.
On Nov 4, 2012, at 7:40 PM, Matthew Flatt wrote:
> 2668 msecs when I declare `cycle-length' as `(Integer -> Integer)' and
> change `(even? n)' to `else', or 2809 msecs if I add `[else 0]' instead
> of changing `(even? n)'.
>
> At Sun, 4 N
On Sun, Nov 4, 2012 at 8:00 PM, Matthew Flatt wrote:
> At Sun, 4 Nov 2012 16:38:25 -0800 (PST), Hugh Aguilar wrote:
>> Has anybody done any benchmarks comparing Racket, Gambit, Chicken, or
>> any other Scheme, for speed?
>
> As it happens, as a sanity check on various changes that I've made
> rece
At Sun, 4 Nov 2012 16:38:25 -0800 (PST), Hugh Aguilar wrote:
> Has anybody done any benchmarks comparing Racket, Gambit, Chicken, or
> any other Scheme, for speed?
As it happens, as a sanity check on various changes that I've made
recently, I've recently re-run a bunch of conventional Scheme
bench
Nice! Thanks.
Robby
On Sun, Nov 4, 2012 at 6:40 PM, Matthew Flatt wrote:
> 2668 msecs when I declare `cycle-length' as `(Integer -> Integer)' and
> change `(even? n)' to `else', or 2809 msecs if I add `[else 0]' instead
> of changing `(even? n)'.
>
> At Sun, 4 Nov 2012 18:30:21 -0600, Robby Find
2668 msecs when I declare `cycle-length' as `(Integer -> Integer)' and
change `(even? n)' to `else', or 2809 msecs if I add `[else 0]' instead
of changing `(even? n)'.
At Sun, 4 Nov 2012 18:30:21 -0600, Robby Findler wrote:
> And just to complete the list, how does the TR version fare?
>
> Robby
16:25:09 + (UTC)
From: daniel rupistraliz avez
To: users@racket-lang.org
Subject: [racket] translate from Racket to Common Lisp
Message-ID:
Content-Type: text/plain; charset=us-ascii
I would like to make a program that translate from Racket to Common Lisp.
One motivation is speed
And just to complete the list, how does the TR version fare?
Robby
On Sun, Nov 4, 2012 at 6:26 PM, Matthew Flatt wrote:
> Thanks!
>
> Sometimes, a x3 difference means that we're missing a straightforward
> opportunity in performance, and that was the case here. The Racket
> program spent most of
Thanks!
Sometimes, a x3 difference means that we're missing a straightforward
opportunity in performance, and that was the case here. The Racket
program spent most of its time in generic `/' by pessimistically
expecting a non-integer result.
I've adjusted the JIT to optimistically compute and che
I don't think anyone is maintaining Dorai's package anymore.
He has become a master of toasts and doesn't have time for
his hobby anymore.
Consider taking it on as a service to the CL and Racket
communities -- Matthias
On Nov 4, 2012, at 2:31 PM, daniel rupistraliz wrote:
> Matthias Fellei
Matthias Felleisen writes:
>
>
> What Matthew and everyone else said is critical. Read those
> before reading on. Also consider using optimizations in Racket
> or converting to TR and asking for fixed-point numbers.
>
> ;; ---
>
> However, we do understand the need for running programs in
What Matthew and everyone else said is critical. Read those
before reading on. Also consider using optimizations in Racket
or converting to TR and asking for fixed-point numbers.
;; ---
However, we do understand the need for running programs in both worlds
(Racke and CL). An alternative is to
racket:
Welcome to Racket v5.2.1.
> (define (cycle-length n)
(cond
[(= n 1)
1]
[(odd? n)
(add1 (cycle-length (add1 (* 3 n]
[(even? n)
(add1 (cycle-length (/ n 2)))]))
(time (for ([i (in-range 1 100)])
(cycle-length i)))
>
cpu time:
At Fri, 2 Nov 2012 16:25:09 + (UTC), daniel rupistraliz avez wrote:
> One motivation is speed, for example a recent example in the racket blog
> about
> the 2n+1 problem gives 1200 milliseconds in Racket and 500 in sbcl (without
> declaring fixnum or any other optimization).
Although it's n
It is flattering for the Racket language that someone would go to all
the trouble of making a translator so that they could continue to
program in Racket, even though they were using a Common Lisp backend. :)
I think that blog entry was an introductory programming tutorial, and it
was not focu
On Fri, Nov 02, 2012 at 04:25:09PM +, daniel rupistraliz avez wrote:
>
> Hello.
>
> I would like to make a program that translate from Racket to Common Lisp.
>
> Do you know about some attempts in this directions?
Guy Steele's master's thesis, a compiler for Scheme.
ftp://publica
Hello.
I would like to make a program that translate from Racket to Common Lisp.
One motivation is speed, for example a recent example in the racket blog about
the 2n+1 problem gives 1200 milliseconds in Racket and 500 in sbcl (without
declaring fixnum or any other optimization).
I w
35 matches
Mail list logo
