IRC channel logs

<spk121>paroneayea: saw your question about breakpoints. mattw has a nice one liner called "trap-here-0" that he describes in http://lists.gnu.org/archive/html/guile-user/2017-02/msg00155.html

<paroneayea>oh cool

<wingo>moin

<peterbrett_work>Hey wingo

<webshinra>huw. I realise I have missed something in my scheme journey

<webshinra>if you get a symbol as argument, how can you get the value associated to this symbol in the current context?

<wingo>scheme doesn't have a concept of a context that you can look up values in. identifiers in scheme are lexically scoped, and statically so: you can't look up a symbol in a scope like that, generally.

<wingo>there is (ice-9 local-eval) tho

<wingo>but generally it's not recommended

<wingo>see e.g. hygiene in https://www.gnu.org/software/guile/manual/html_node/Syntax-Rules.html#Syntax-Rules

<wingo>two identifiers can have the same name but be distinct

<webshinra>okay, i'll use a less ideous but more verbose option :D

<wingo>:)

<webshinra>hideous*

<webshinra>(thanks)

<wingo>yaaaaaay https://github.com/WebAssembly/gc/blob/3866e9bd8e429cb8d35be74ed2c9d65b130eeeb2/proposals/gc/Overview.md

<webshinra>:)

<xvilka>btw, from benchmarks I understood, that guile supports R7RS

<xvilka>but there is no easy way to enable it?

<xvilka>like rnrs (6)

<wingo>guile doesn't have that yet. perhaps by 2.2.1 or 2.2.2.

<Petit_Dejeuner>webshinra: You might want to look at this too.

<Petit_Dejeuner>It gives you similar semantics to *special-variables* in lisp. (Dynamically bound.)

<Petit_Dejeuner>But parameter is per-thread.

<wingo>more or less per-thread :P

<wingo> https://www.gnu.org/software/guile/manual/html_node/Thread-Local-Variables.html#Thread-Local-Variables

<Petit_Dejeuner>Eh, it's the semantics that makes sense to me.

<Petit_Dejeuner>Maybe I haven't written enough threaded scheme.

<webshinra>by this, you mean R7RS ?

<Petit_Dejeuner>webshinra: Sorry, I've been up for 24+ hours now. https://www.gnu.org/software/guile/manual/html_node/Parameters.html#Parameters

<Petit_Dejeuner>Although, I'm beginning to think this isn't what you want.

<webshinra>well, that's interesting and I didn't know about it, so thank you :P

<webshinra>et quand on ne dort pas, on est privé de Petit_Dejeuner, ce qui est dommage.

<wingo>:)

<Petit_Dejeuner>1,1The joke is I'm not french and had to look up all the verbs in that except for 'est'.

<webshinra>:o)

<wingo>:)

<dsmith>Greetn's Guilers

<stis>Tja guilers!

<ArneBab_>wingo: I now have benchmarks in which I see a (car L) (with L as (iota N) taking about 1ns longer than an empty (λ() #t) and (+ N m) taking about 3ns. I have a core i3, 3.1GHz, is this the maximum performance I can expect?

<ArneBab_>In Fortran I see about 2ns per addition (when operating on about 3 MiB of data)

<ArneBab_>I also see (+ (+ (+ N m) 1) 2) taking 1e-8 seconds while (+ N m) takes 0.5e-8 seconds.

<ArneBab_>so these two additions are about 5ns, or 15 cycles

<ArneBab_>In fortran I see a sum operation over 2e7 random numbers taking 0.02s (1ns per number)

<ArneBab_>(apply + L) with L as (iota 2e7 1 0) takes 1s

<ArneBab_>so there rI have 50ns per number, but with (+ N m) I need only 10ns

<ArneBab_>(gc-disable) gets me down to 0.5s for (apply + L)

<ArneBab_>python takes 1.3 seconds for the same task

<ArneBab_>ah, no, 0.13s …

<ArneBab_>wingo: do you know tricks to make this faster?

<ArneBab_>this is with 2.2.0

<ArneBab_>doing this in a plain loop in Python takes 0.6s → guile is faster there

<davexunit>ArneBab_: iota builds a list!

<davexunit>that's not a great way to sum numbers

<ArneBab_>davexunit: how would you store the numbers?

<ArneBab_>(to allow easy summing)

<davexunit>ArneBab_: how are you storing them in fortran?

<ArneBab_>davexunit: in a fixed array

<davexunit>then you're not comparing apples to apples

<davexunit>you're using 2 different data structures. try making a bytevector.

<ArneBab_>I know that, but I don’t know how to replicate the fortran task with Guile

<davexunit>are these integers?

<davexunit>you can use a u32vector or u64vector

<ArneBab_>I’ll try that

<ArneBab_>how do I add them then?

<davexunit>with a loop

<davexunit>iterate over the vector and track the sum

<daviid> ArneBab_: if it is to measure +, you may as well use do

<ArneBab_>with this I still get 0.6s: ,time (let lp ((n (- (u32vector-length a) 1))) (when (> n 0) (u32vector-ref a n)(lp (- n 1))))

<ArneBab_>with (define a (make-u32vector (inexact->exact 2e7) 1))

<ArneBab_>ah, that’s the time for the u32vector-ref …

<ArneBab_>which fortran does not have to do explicitly

<daviid>inexact->exact as well

<ArneBab_>davexunit, daviid: thank you for your support — I’ll be back later

<daviid>ArneBab_: not sure what youe are trying to do, but is this close? ,time (let ((n 3)) (do ((i 0 (+ i 1))) ((= i 2000000)) (+ i n)))

<ArneBab_>ah, nice!

<daviid>;; 0.062915s real time, 0.062868s run time. 0.000000s spent in GC.

<ArneBab_>daviid: yes

<daviid>with 2.2.0.9-bcfc3

<ArneBab_>ah… misses one zero

<ArneBab_>,time (let ((n 3)) (do ((i 0 (+ i 1))) ((= i 20000000)) (+ i n)))

<ArneBab_>0.16s

<ArneBab_>so it’s 8ns per step

<ArneBab_>this shows what it does: ,x (λ ()(let ((n 3)) (do ((i 0 (+ i 1))) ((= i 20000000)) (+ i n))))

<amz3`>heya

<ArneBab_>looks like 4 operations in the tight loop (between L1 and L2), each taking 2ns

<ArneBab_>daviid: thank you!

<ArneBab_>daviid: I’m pretty sure fortran does not have a (handle-interrupts) operation in the loop

<amz3`>wingo: the link about gc in webassembly seems interesting

<amz3`>I found out that biwascheme is slow and/or get slower using firefox 45 (debian stable version)

<amz3`>Petit_Dejeuner: what's the difference between paramter and fluids? do you know?

<Petit_Dejeuner>amz3`: iirc, parameters are defined in terms of fluids, but I don't know anything else

<amz3`>ArneBab_: Do the sum must happen on values that are precalculated? do you know in advance all of them?

<amz3`>Petit_Dejeuner: it seems to me they are semantically equivalent. Only the API is different.

<ArneBab_>amz3`: the values should not be precalculated, it was just the easiest thing to test. If I do the same in Fortran, the compiler just optimizes away all my code and precalculates the result, therefore I have to use random numbers :)

IRC channel logs

2017-04-11.log