Re: [racket-dev] [plt] Push #29098: master branch updated
On Fri, Jul 25, 2014 at 10:39 AM, wrote: > > | As far as I can tell, we have to compute ourselves whether a > | date is in daylight-saving time based on specifications of > | when daylight and standard times start. That part seems tricky > | and could use extra review. >From a quick search of the repository, it looks like `scheme_get_seconds` and `seconds_to_date` aren't used anywhere else in the C code, and thus could be rewritten in Racket using the FFI, which might make the extra review easier. :) Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket hash tables vs. Python dicts - Performance
This is probably not responsible for much of the performance difference,
but the racket code has (random 23) where it looks like it ought to be
(random 26), resulting in a smaller space of possible random keys. This
will cause the branch with the lookup to happen somewhat more often than in
the python version.
On Fri, Jul 25, 2014 at 1:34 AM, Laurent wrote:
> Even more idiomatic:
> (time (for ([w words])
> (hash-update! d w add1 0)))
>
> But it seems to be slightly slower that Robby's version.
>
> Laurent
>
>
> On Thu, Jul 24, 2014 at 11:26 AM, Robby Findler <
> ro...@eecs.northwestern.edu> wrote:
>
>> Not an answer to your direction question, but this is the more
>> idiomatic way to write that and it seems to be a bit faster:
>>
>> (time (for ([w (in-list words)])
>> (hash-set! d w (add1 (hash-ref d w 0)
>>
>> On Wed, Jul 23, 2014 at 10:54 AM, Pedro Ramos
>> wrote:
>> > Hi,
>> >
>> > I've been developing an implementation of Python in Racket, where I'm
>> > implementing Python's dictionaries over Racket custom hash tables.
>> >
>> > While my occasional benchmarks typically show better performance on
>> Racket
>> > programs than their Python equivalents, Racket's hash tables generally
>> seem
>> > to be slower than Python's dicts.
>> >
>> > I've set up this benchmark in Racket:
>> >
>> >
>> > #lang racket
>> >
>> > (define alphabet "abcdefghijklmnopqrstuvwxyz")
>> > (define (random-word n)
>> > (build-string n (lambda (x) (string-ref alphabet (random 23)
>> >
>> > (define words (for/list ([k 100])
>> > (random-word 3)))
>> > (define d (make-hash))
>> >
>> > (time (for ([w words])
>> > (if (hash-has-key? d w)
>> > (hash-set! d w (add1 (hash-ref d w)))
>> > (hash-set! d w 1
>> >
>> >
>> > And its equivalent in Python:
>> >
>> >
>> > import random
>> > import time
>> >
>> > alphabet = "abcdefghijklmnopqrstuvwxyz"
>> > def random_word(n):
>> > return ''.join([random.choice(alphabet) for i in range(n)])
>> >
>> > words = [random_word(3) for k in xrange(100)]
>> > d = {}
>> >
>> > a = time.time()
>> > for w in words:
>> > if w in d:
>> > d[w] = d[w] + 1
>> > else:
>> > d[w] = 1
>> > b = time.time()
>> > print b-a, 'seconds'
>> >
>> >
>> > The Racket example yields running times of around 500 ms (running on
>> Racket
>> > v6.0.1) while the Python example yields running times of around 330 ms
>> > (running on Python 2.7.3).
>> >
>> > I find this unusual because Python is somewhat more dynamic than Racket,
>> > since
>> > (a) Python's equality and hashing functions have to dispatched at
>> runtime
>> > for each key;
>> > (b) referencing and setting values in a Python dict is done using a very
>> > general operator, [], whose behaviour also has to be dispatched at
>> runtime,
>> > unlike the more specific hash-ref and hash-set! Racket functions.
>> >
>> > Is there something I'm missing about Racket's hash tables which explains
>> > this slower speed?
>> >
>> > Thanks,
>> > Pedro Ramos
>> >
>> > _
>> > Racket Developers list:
>> > http://lists.racket-lang.org/dev
>> >
>> _
>> Racket Developers list:
>> http://lists.racket-lang.org/dev
>>
>
>
> _
> Racket Developers list:
> http://lists.racket-lang.org/dev
>
>
--
A warb degombs the brangy. Your gitch zanks and leils the warb.
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] A tricky chaperone puzzle
I only thought of it because the first thing I tried was to break the chaperone invariant, thinking that 2 might already have been the behavior. I only came up with the access control variant when that didn't work. Sam On Jul 25, 2014 6:04 AM, "Matthew Flatt" wrote: > Unless I still have it wrong, the implementation of 2 was > straightforward. > > I would have overlooked the need to restrict `chaperone-struct` to > chaperones of accessors and mutators if you hadn't mentioned it. > > At Thu, 24 Jul 2014 15:45:18 -0400, Sam Tobin-Hochstadt wrote: > > Consider the following module: > > > > (module m racket > > (struct x [a]) > > (define v1 (x 'secret)) > > (define v2 (x 'public)) > > (provide v1 v2) > > (provide/contract [x-a (-> x? (not/c 'secret))])) > > > > It appears that this ensures that you can't get 'secret. But, it turns > > out that I can write a function outside of `m` that behaves like `x-a` > > without the contract: > > > > (require (prefix-in m: 'm)) > > > > (define (x-a v) > > (define out #f) > > (with-handlers ([void void]) > > (m:x-a (chaperone-struct v m:x-a (λ (s v) (set! out v) v > > out) > > > > Now this works: > > > > (displayln (x-a m:v1)) ;; => 'secret > > > > The problem is that `m:x-a` is treated as a > > `struct-accessor-procedure?`, which is a capability for accessing the > > a field, even though it's a significantly restricted capability. > > > > There are a couple possible solutions I've thought of: > > > > 1. Require a non-chaperoned/impersonated accessor. > > 2. Actually use the chaperoned/impersonatored accessor to get the > > value out instead of the underlying accessor. > > > > 1 is a little less expressive. But note that 2 means that you have to > > only allow chaperoned procedures with `chaperone-struct`, and imposes > > significant complication on the runtime. > > > > I favor 1. > > > > Sam > > > > _ > > Racket Developers list: > > http://lists.racket-lang.org/dev > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] A tricky chaperone puzzle
Unless I still have it wrong, the implementation of 2 was straightforward. I would have overlooked the need to restrict `chaperone-struct` to chaperones of accessors and mutators if you hadn't mentioned it. At Thu, 24 Jul 2014 15:45:18 -0400, Sam Tobin-Hochstadt wrote: > Consider the following module: > > (module m racket > (struct x [a]) > (define v1 (x 'secret)) > (define v2 (x 'public)) > (provide v1 v2) > (provide/contract [x-a (-> x? (not/c 'secret))])) > > It appears that this ensures that you can't get 'secret. But, it turns > out that I can write a function outside of `m` that behaves like `x-a` > without the contract: > > (require (prefix-in m: 'm)) > > (define (x-a v) > (define out #f) > (with-handlers ([void void]) > (m:x-a (chaperone-struct v m:x-a (λ (s v) (set! out v) v > out) > > Now this works: > > (displayln (x-a m:v1)) ;; => 'secret > > The problem is that `m:x-a` is treated as a > `struct-accessor-procedure?`, which is a capability for accessing the > a field, even though it's a significantly restricted capability. > > There are a couple possible solutions I've thought of: > > 1. Require a non-chaperoned/impersonated accessor. > 2. Actually use the chaperoned/impersonatored accessor to get the > value out instead of the underlying accessor. > > 1 is a little less expressive. But note that 2 means that you have to > only allow chaperoned procedures with `chaperone-struct`, and imposes > significant complication on the runtime. > > I favor 1. > > Sam > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket hash tables vs. Python dicts - Performance
Even more idiomatic:
(time (for ([w words])
(hash-update! d w add1 0)))
But it seems to be slightly slower that Robby's version.
Laurent
On Thu, Jul 24, 2014 at 11:26 AM, Robby Findler wrote:
> Not an answer to your direction question, but this is the more
> idiomatic way to write that and it seems to be a bit faster:
>
> (time (for ([w (in-list words)])
> (hash-set! d w (add1 (hash-ref d w 0)
>
> On Wed, Jul 23, 2014 at 10:54 AM, Pedro Ramos
> wrote:
> > Hi,
> >
> > I've been developing an implementation of Python in Racket, where I'm
> > implementing Python's dictionaries over Racket custom hash tables.
> >
> > While my occasional benchmarks typically show better performance on
> Racket
> > programs than their Python equivalents, Racket's hash tables generally
> seem
> > to be slower than Python's dicts.
> >
> > I've set up this benchmark in Racket:
> >
> >
> > #lang racket
> >
> > (define alphabet "abcdefghijklmnopqrstuvwxyz")
> > (define (random-word n)
> > (build-string n (lambda (x) (string-ref alphabet (random 23)
> >
> > (define words (for/list ([k 100])
> > (random-word 3)))
> > (define d (make-hash))
> >
> > (time (for ([w words])
> > (if (hash-has-key? d w)
> > (hash-set! d w (add1 (hash-ref d w)))
> > (hash-set! d w 1
> >
> >
> > And its equivalent in Python:
> >
> >
> > import random
> > import time
> >
> > alphabet = "abcdefghijklmnopqrstuvwxyz"
> > def random_word(n):
> > return ''.join([random.choice(alphabet) for i in range(n)])
> >
> > words = [random_word(3) for k in xrange(100)]
> > d = {}
> >
> > a = time.time()
> > for w in words:
> > if w in d:
> > d[w] = d[w] + 1
> > else:
> > d[w] = 1
> > b = time.time()
> > print b-a, 'seconds'
> >
> >
> > The Racket example yields running times of around 500 ms (running on
> Racket
> > v6.0.1) while the Python example yields running times of around 330 ms
> > (running on Python 2.7.3).
> >
> > I find this unusual because Python is somewhat more dynamic than Racket,
> > since
> > (a) Python's equality and hashing functions have to dispatched at runtime
> > for each key;
> > (b) referencing and setting values in a Python dict is done using a very
> > general operator, [], whose behaviour also has to be dispatched at
> runtime,
> > unlike the more specific hash-ref and hash-set! Racket functions.
> >
> > Is there something I'm missing about Racket's hash tables which explains
> > this slower speed?
> >
> > Thanks,
> > Pedro Ramos
> >
> > _
> > Racket Developers list:
> > http://lists.racket-lang.org/dev
> >
> _
> Racket Developers list:
> http://lists.racket-lang.org/dev
>
_
Racket Developers list:
http://lists.racket-lang.org/dev
