Re: Transducers v0.3.0 - R7RS edition

[Damien MATTEI]

hello Jeremy,

i just have a glance at your source code and it is more developped than 
the guile version which i personally ported to racket so it would be 
hard to compare (in term of speed,etc) also i never used chicken ,just 
guile and racket but i will use chicken in future as i want to port my 
Scheme+ to chicken as it has the necessary srfi 105.


I did not know SRFI 42, using Python ,i see it provides what Python has 
: comprehension and i will use it for sure to port code from Python to 
Scheme. In contrast to Python i think Scheme miss some feature , for 
example in Python you can declare a hashtable like this :


dict  =  {'Name':  'Zara',  'Age':  7,  'Class':  'First'}

but not in Scheme ,i want to add such feature (if no srfi alread do it) 
in Scheme+.


Damien

Le 17/04/2023 à 06:25, Jeremy Steward a écrit :

Hey Damian, I must have missed this message when I announced v0.3.0.

On 4/3/23 00:08, Damien Mattei wrote:

Hello,

does this transducers implementation add some significant speed to code
when using them? i ask the question because i used transducers with
Guile with very poor speed improvement compared to normal code.



This question is going to be difficult to answer in any meaningful 
way. For starters, I'll assume you're using SRFI 171 with Guile?


Relative to the SRFI-171 base implementation, I'm not sure that the 
transducers library I've written is ever going to be "faster" than a 
hand-written / hand-optimized loop. I assume this is what you mean by 
"normal code." I believe SRFI 42 can be significantly faster, but is 
considerably different in terms of both purpose and implementation.


Nevertheless, I think there's a problem with the way the question is 
posed. Some thoughts:


- "normal code" is ill-defined here, and I think it's 
counter-intuitive to think about libraries relative to code with zero 
abstractions in terms of performance alone, especially in Scheme. 
Generally speaking, I'd say that if you can get good performance with 
what code you have and you don't see a maintenance problem, then maybe 
an abstraction isn't necessary.


- Asking about SRFI-171 in Guile relative to transducers in CHICKEN 
seems like it has a bunch of problems on its own. CHICKEN can 
generally be faster than many Scheme implementations but there's a 
wide number of reasons that code on Guile may perform worse or better.


- You've provided no real indication of what you were doing. It would 
be difficult to say how transducers might help improve (or not 
improve) performance for some nebulous set of problems.


Anyways, this is not to lambast you for the question -- I'm sure it 
comes from a genuine place. I'd encourage you to try the library out 
and use CHICKEN's profiler (call your application with the argument 
"-:p" without quotes, see 
). 
It's often better to measure what you can and then make a decision 
from there.


I'd also encourage you to read the documentation for transducers if 
you haven't already - it should give you an idea of what is being done 
and what kind of performance to expect 
().

Re: Transducers v0.3.0 - R7RS edition

[Jeremy Steward]

Hey Damian, I must have missed this message when I announced v0.3.0.

On 4/3/23 00:08, Damien Mattei wrote:

Hello,

does this transducers implementation add some significant speed to code
when using them? i ask the question because i used transducers with
Guile with very poor speed improvement compared to normal code.



This question is going to be difficult to answer in any meaningful way. 
For starters, I'll assume you're using SRFI 171 with Guile?


Relative to the SRFI-171 base implementation, I'm not sure that the 
transducers library I've written is ever going to be "faster" than a 
hand-written / hand-optimized loop. I assume this is what you mean by 
"normal code." I believe SRFI 42 can be significantly faster, but is 
considerably different in terms of both purpose and implementation.


Nevertheless, I think there's a problem with the way the question is 
posed. Some thoughts:


- "normal code" is ill-defined here, and I think it's counter-intuitive 
to think about libraries relative to code with zero abstractions in 
terms of performance alone, especially in Scheme. Generally speaking, 
I'd say that if you can get good performance with what code you have and 
you don't see a maintenance problem, then maybe an abstraction isn't 
necessary.


- Asking about SRFI-171 in Guile relative to transducers in CHICKEN 
seems like it has a bunch of problems on its own. CHICKEN can generally 
be faster than many Scheme implementations but there's a wide number of 
reasons that code on Guile may perform worse or better.


- You've provided no real indication of what you were doing. It would be 
difficult to say how transducers might help improve (or not improve) 
performance for some nebulous set of problems.


Anyways, this is not to lambast you for the question -- I'm sure it 
comes from a genuine place. I'd encourage you to try the library out and 
use CHICKEN's profiler (call your application with the argument "-:p" 
without quotes, see 
). 
It's often better to measure what you can and then make a decision from 
there.


I'd also encourage you to read the documentation for transducers if you 
haven't already - it should give you an idea of what is being done and 
what kind of performance to expect 
().

--
Jeremy Steward

Re: Transducers v0.3.0 - R7RS edition

[Damien Mattei]

Hello,

does this transducers implementation add some significant speed to code 
when using them? i ask the question because i used transducers with 
Guile with very poor speed improvement compared to normal code.


regards,

damien

Le 03/04/2023 à 01:05, Jeremy Steward a écrit :

Hey all,

Just wanted to ping the list to tell you all that Transducers v0.3.0 
should soon be available. This version won't mean much if you're 
already using the transducers egg in your code anywhere, because the 
main change is that I've transitioned the egg into an R7RS module. See:




I haven't made this compatible with any other Scheme implementation 
yet, but if others want to upstream a patch to do so I'd be more than 
happy to review & accept it. :)


For now I'll leave the project name as `chicken-transducers` since 
that is part of the URL for the release-info file, but know that it is 
a full R7RS library and that it should be pretty easy to port as long 
as you have a few SRFIs available (srfi-1, srfi-133, srfi-143, srfi-160).


Looking into other active issues 
(), I 
think I'll start seriously aiming to support transducers across more 
data types. I'd appreciate any feedback on which common Scheme eggs / 
data types are most useful to folks.


Otherwise, I'll keep hacking away. :)