Re: About peformance of user defined procedures

just a wild guess:

On Jul 31 2011, Pedro Henrique Antunes de Oliveira wrote:

>Hey.
>
>I have a file map.scm, which contais this code:
>
>(define (mymap1 op ls)
>  (let loop ((ls ls) (acc '()))
>    (if (null? ls)
>        (reverse acc)
>        (loop (cdr ls) (cons (op (car ls)) acc)))))
                              ^^^^
This compiles (*probably* and depending on optimisation switches you pass
to the compiler) one call equivalend to (procedure? op).

Since everything around is zero-effort, you basically check loop and
call performance here.

You might also find it funny to try:

(define (mymap1b op ls)
  (let loop ((op op) (ls ls) (acc '()))
    (if (null? ls)
        (reverse acc)
        (loop op (cdr ls) (cons (op (car ls)) acc)))))

which would avoid one indirection per call at the expense of
yet another loop parameter.  Please let me know how much of a difference

Re: About peformance of user defined procedures

Interesting point.

But I tried it out. In average, it took about the same amount of time
(actualy this was about 0.1s slower).

Maybe because the amount of time spent on binding arguments to
parameters is larger than the amount of time of that (procedure? op).

I've heard that some compilers can do something like memoization for
stuff like (procedure? op) (it is possible for that to be done in this
case), which would speed that up.

I've tried compiling with csc -O3 -unsafe (to avoid those checks if
something is a procedure or not), and no actual difference too.

On Mon, Aug 1, 2011 at 2:36 PM, Jörg F. Wittenberger
<Joerg.Wittenberger <at> softeyes.net> wrote:
> just a wild guess:
>
> On Jul 31 2011, Pedro Henrique Antunes de Oliveira wrote:
>
>> Hey.
>>
>> I have a file map.scm, which contais this code:
>>
>> (define (mymap1 op ls)
>>  (let loop ((ls ls) (acc '()))
>>   (if (null? ls)
>>       (reverse acc)
>>       (loop (cdr ls) (cons (op (car ls)) acc)))))

Re: About peformance of user defined procedures

On Aug 1 2011, Pedro Henrique Antunes de Oliveira wrote:

>Interesting point.
>
>But I tried it out. In average, it took about the same amount of time
>(actualy this was about 0.1s slower).

Looking closer (since you made me curious); there is little magic
about the definition of "map" as far as I can see.
No special code generation, just:

(define (##sys#map p lst0)
  (let loop ((lst lst0))
    (cond ((eq? lst '()) lst)
	  ((pair? lst)
	   (cons (p (##sys#slot lst 0)) (loop (##sys#slot lst 1))) )
	  (else (##sys#error-not-a-proper-list lst0 'map)) ) ))

(define map)

(##sys#slot lst 0) is in effect (car lst) sans any kind of checks
or calls.  Maybe this helps?

>
>Maybe because the amount of time spent on binding arguments to
>parameters is larger than the amount of time of that (procedure? op).
>
>I've heard that some compilers can do something like memoization for
>stuff like (procedure? op) (it is possible for that to be done in this
>case), which would speed that up.

Re: About peformance of user defined procedures

On Aug 1 2011, Kon Lovett wrote:

>
>On Aug 1, 2011, at 1:05 PM, Jörg F. Wittenberger wrote:
>
>> On Aug 1 2011, Pedro Henrique Antunes de Oliveira wrote:
>> 
>>> Interesting point.
>>> 
>>> But I tried it out. In average, it took about the same amount of time
>>> (actualy this was about 0.1s slower).
>> 
>> Looking closer (since you made me curious); there is little magic
>> about the definition of "map" as far as I can see.
>> No special code generation, just:
>
> I think it is open coded. See "compiler-syntax.scm" for built-in 
> compiler-macros.

Ah' I see.  A nice chance to learn something about the compiler internals!

AFAIK This would save some allocations when building the result list.
Is this the case/rationale here?  Or did I miss the point?

>
>> 
>> (define (##sys#map p lst0)
>> (let loop ((lst lst0))
>>   (cond ((eq? lst '()) lst)
>> 	  ((pair? lst)

LLVM fails on Mac OS X 10.7

I have a similar, or same issue as reported here (
http://lists.gnu.org/archive/html/chicken-users/2010-12/msg00159.html ) from David
Dreisigmeyer. Running make appears to work fine, but when I run make install it hangs at chicken-update
-update-db. Also running 'csi' does nothing ( no errors, just sits there ). Running 'csi -:d' gives me:

[debug] application startup...
[debug] heap resized to 500000 bytes
[debug] stack bottom is 0x0. <---- Someone I spoke to on IRC said this was odd, and probably important.
[debug] entering toplevel toplevel...
[debug] stack resized to 131072 bytes
[debug] entering toplevel library_toplevel…

Output of gcc -v:
Using built-in specs.
Target: i686-apple-darwin11
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2335.15~25/src/configure
--disable-checking --enable-werror --prefix=/Developer/usr/llvm-gcc-4.2 --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm-
--program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib
--build=i686-apple-darwin11
--enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2335.15~25/dst-llvmCore/Developer/usr/local
--program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11
--target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)

I was able to successfully install using the below params thanks to zbigniew's help on #chicken:

make C_COMPILER=gcc-4.2 PLATFORM=macosx  

Re: LLVM fails on Mac OS X 10.7

To add, llvm-gcc is now the default on 10.7, so any Lion user would probably see this issue.  That is why it was
necessary to set gcc-4.2 explicitly.

On Aug 5, 2011, at 11:32 PM, Josh Chaney wrote:

> I have a similar, or same issue as reported here (
http://lists.gnu.org/archive/html/chicken-users/2010-12/msg00159.html ) from David
Dreisigmeyer. Running make appears to work fine, but when I run make install it hangs at chicken-update
-update-db. Also running 'csi' does nothing ( no errors, just sits there ). Running 'csi -:d' gives me:
> 
> [debug] application startup...
> [debug] heap resized to 500000 bytes
> [debug] stack bottom is 0x0. <---- Someone I spoke to on IRC said this was odd, and probably important.
> [debug] entering toplevel toplevel...
> [debug] stack resized to 131072 bytes
> [debug] entering toplevel library_toplevel…
> 
> Output of gcc -v:
> Using built-in specs.
> Target: i686-apple-darwin11
> Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2335.15~25/src/configure
--disable-checking --enable-werror --prefix=/Developer/usr/llvm-gcc-4.2 --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm-
--program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib
--build=i686-apple-darwin11
--enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2335.15~25/dst-llvmCore/Developer/usr/local
--program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11
--target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
> Thread model: posix
> gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)

CHICKEN Scheme <at> FrOSCon 2011

Dear Chicken fans,

we are happy that the FrOSCon guys agreed to have us again at this
year's event in Bonn near Cologne / Germany. 

Moritz has been fast enough to get us a developer room track at this
year's FrOSCon venue. This means that there will be workshops around
CHICKEN all saturday!

We have planned the following topics so far:

* Introduction into Scheme
* The CHICKEN Scheme ecosystem
* How to lay proper eggs
* Making use if the FFI to generate bindings to foreign libs (?)

This is not the complete or final list and we are still open to
suggestions! Moritz will fill in the blanks for FrOSCon's even planner
next week to publish the schedule.

You are invited to:

* Drop by and talk to us and learn something you might not yet know

* Submit a topic idea you are interested in

* Contribute with your own talk about an interesting topic around the
CHICKEN world (no joke :))

The party will be at 

Interesting case.

I ran into some old code, which might never have been used;
however now it compiles with warning:

  access to variable `tmp7448' which has an undefined value

The code itself was silly, however: the procedure had a rest argument
by the name of "values", i.e.:
(define (sillything a b . values) ...)

Renaming "values" to "rest" got me rid of the warning.  However I believe
this cures the symptom instead of the issue.

/Jerry
.............

Re: Interesting case.

On Thu, Aug 11, 2011 at 11:05:25PM +0200, J?rg F. Wittenberger wrote:
> I ran into some old code, which might never have been used;
> however now it compiles with warning:
> 
>   access to variable `tmp7448' which has an undefined value
> 
> The code itself was silly, however: the procedure had a rest argument
> by the name of "values", i.e.:
> (define (sillything a b . values) ...)
> 
> Renaming "values" to "rest" got me rid of the warning.  However I believe
> this cures the symptom instead of the issue.

On which version of Chicken are you compiling this?  I'm using 4.7.0,
and don't see any warning neither in the interpreter nor from the
compiler.

CHICKEN
(c)2008-2011 The Chicken Team
(c)2000-2007 Felix L. Winkelmann
Version 4.7.0 
linux-unix-gnu-x86-64 [ 64bit manyargs dload ptables ]
compiled 2011-05-25 on gemini (Linux)

--

-- 
Erik Falor
Registered Linux User #445632 http://counter.li.org

_______________________________________________

Re: Interesting case.

From: Jörg F. Wittenberger <Joerg.Wittenberger <at> softeyes.net>
Subject: [Chicken-users] Interesting case.
Date: 11 Aug 2011 23:05:25 +0200

> I ran into some old code, which might never have been used;
> however now it compiles with warning:
> 
>  access to variable `tmp7448' which has an undefined value
> 
> The code itself was silly, however: the procedure had a rest argument
> by the name of "values", i.e.:
> (define (sillything a b . values) ...)
> 
> Renaming "values" to "rest" got me rid of the warning.  However I
> believe
> this cures the symptom instead of the issue.

Hm, I think this must be something different. You could check the output
of "-debug 2" and look for "tmp7448", which might shine some light on this.

cheers,
felix