there are no consing semantics. when i said theyll be 'call with values' on
the inside, i meant that theyd have to do the same thing internally as
call-with-values is currently doing, if they wanted to maintain continuation
safety. theres no way to avoid it, and the current implementation is
On Feb 4, 2008 12:13 PM, John Cowan <[EMAIL PROTECTED]> wrote:
> felix winkelmann scripsit:
>
> > > This is why I'm proposing a simple extension to lambda-lists: a fixnum
> > > in a lambda-list declares that the procedure returns exactly that
> > > many values.
> >
> > Sorry, too ugly. :-)
>
Wha
felix winkelmann scripsit:
> > This is why I'm proposing a simple extension to lambda-lists: a fixnum
> > in a lambda-list declares that the procedure returns exactly that
> > many values.
>
> Sorry, too ugly. :-)
Okay, then I guess multiple-value performance will remain crappy on
Chicken. What
On Feb 4, 2008 7:35 AM, John Cowan <[EMAIL PROTECTED]> wrote:
> felix winkelmann scripsit:
>
> > It can only be deduced at runtime whether a continuation is
> > multiple-value aware or not
>
> This is why I'm proposing a simple extension to lambda-lists: a fixnum
> in a lambda-list declares that th
felix winkelmann scripsit:
> It can only be deduced at runtime whether a continuation is
> multiple-value aware or not
This is why I'm proposing a simple extension to lambda-lists: a fixnum
in a lambda-list declares that the procedure returns exactly that
many values.
--
They tried to pierce yo
On Feb 2, 2008 4:48 AM, Shawn W. <[EMAIL PROTECTED]> wrote:
> it would be a good idea to increase the default stack size on 64-bit
> hosts.
Good point. I'll set the default stack-size to 256k on x86-64.
cheers,
felix
___
Chicken-users mailing list
C
On Feb 1, 2008 7:55 PM, Will Farr <[EMAIL PROTECTED]> wrote:
> Hi Kon,
>
>
> would be expensive. You must create a closure, cons up a rest list,
> and I bet that apply uses some C varargs magic that probably is much
> slower than a straight function call.
Something like that, yes.
> But, how har
On Feb 1, 2008 5:46 PM, Will Farr <[EMAIL PROTECTED]> wrote:
> Isn't a call to values completely equivalent to:
>
> (values v1 ...) => (call/cc (lambda (k) (k v1 ...)))
>
> so
>
> (define (values . rest) (call/cc (lambda (k) (apply k rest
>
> (which seems like the point that John is making)? S
On Feb 1, 2008, at 7:24 PM, Zbigniew wrote:
Thanks Shawn. Your results are really similar to Ivan's Xeon,
which was
running 64-bit. You both had a huge number of major GCs, in the 6-7k
range. I believe that you are seeing not only the effect of the
stack frame
difference we're seeing on
Thanks Shawn. Your results are really similar to Ivan's Xeon, which was
running 64-bit. You both had a huge number of major GCs, in the 6-7k
range. I believe that you are seeing not only the effect of the stack frame
difference we're seeing on certain 32-bit systems, but also the double
word siz
Thanks Ivan! Thanks to your results, I reproduced the problem.
I thought this might be a gcc version issue, since the fast versions were
compiled with 4.2.3 and the slow ones with 4.1 (Linux) or 4.0.1 (OS X). But,
recompiling with 4.1.3 on Linux did not reproduce the issue.
However, on my Debia
On Feb 1, 2008, at 10:52 AM, Zbigniew wrote:
The program is identical and generated by the same compiler (SVN
head) with -Ob
and the stack size is identical (128k). We saw it was very fast on
a Pentium M
and an Athlon 1600 on Linux, and it was very slow on a 2GHz Core 2
Duo (OS X),
an unk
Here are some results for Core 2 Duo and 4-core Xeon in Linux. I get a
small difference in performance of values vs. list on the Core 2 Duo:
System 1 (Core 2 Duo):
$ cat /proc/cpuinfo | grep model | head -2
model: 15
model name : Intel(R) Core(TM)2 CPU T7200
Hi Kon,
Thanks for running the tests---that was quick! It's true that, as written,
(define (values . rest) (call/cc (lambda (k) (apply k rest
would be expensive. You must create a closure, cons up a rest list,
and I bet that apply uses some C varargs magic that probably is much
slower than
The program is identical and generated by the same compiler (SVN head) with -Ob
and the stack size is identical (128k). We saw it was very fast on a Pentium M
and an Athlon 1600 on Linux, and it was very slow on a 2GHz Core 2 Duo (OS X),
an unknown OS X box and a PPC (probably OS X). I wonder if
Hi Will,
On Feb 1, 2008, at 8:46 AM, Will Farr wrote:
Isn't a call to values completely equivalent to:
(values v1 ...) => (call/cc (lambda (k) (k v1 ...)))
so
(define (values . rest) (call/cc (lambda (k) (apply k rest
(which seems like the point that John is making)? Since call/cc is
f
Isn't a call to values completely equivalent to:
(values v1 ...) => (call/cc (lambda (k) (k v1 ...)))
so
(define (values . rest) (call/cc (lambda (k) (apply k rest
(which seems like the point that John is making)? Since call/cc is
free in Chicken, wouldn't this be as fast as any procedure
Zbigniew scripsit:
> A multiple-value call takes the following route under Chicken:
> C_call_with_values -> C_do_apply -> C_values -> values_continuation ->
> C_do_apply. A single-value call is compiled to a function call. You
> can see why returning a single list value and destructuring it shou
Tobia Conforto scripsit:
> I see what John is proposing here, and it makes sense to me.
Umm, not so fast. I wasn't *proposing* anything, just expressing
a theoretical possibility that is totally irrelevant for Chicken
because of the way it works.
> We could choose values and receive (or let-val
From the other thread
Elf wrote:
John Cowan wrote:
It also occurs to me that rec and let-values and all need not
expand into call-values--that's just the *portable* expansion of
them.
they'll all be call-with-values on the inside, or the equivalent
thereof.
Not necessarily.
I see what
On Feb 1, 2008 9:12 AM, Jörg F. Wittenberger
>
> What I'm wandering about: if the multiple value implementation in
> chicken is slow, why not change it? A distinguished data type for
> multiple values some magic (details of which I can't judge about right
> now) to hide the manual deconstruction.
On Feb 1, 2008 8:40 AM, Zbigniew <[EMAIL PROTECTED]> wrote:
>
> This is a huge disparity and is worth investigating, unless one of the
> master Chicken hackers can explain it right off the bat.
>
I couldn't, but it is worth mentioning that the performance of a
chicken-compiled program is extremely
Am Freitag, den 01.02.2008, 00:41 -0600 schrieb Zbigniew:
> A multiple-value call takes the following route under Chicken:
> C_call_with_values -> C_do_apply -> C_values -> values_continuation ->
> C_do_apply. A single-value call is compiled to a function call. You
> can see why returning a sing
On 2/1/08, John Cowan <[EMAIL PROTECTED]> wrote:
> Zbigniew scripsit:
> > I ran Alex's test on a fast machine (Intel C2D 2GHz).
> > I got the same disparity as Alex. I would be curious as to what
> > platform you're running on
> An ancient Dell Latitude D610 laptop running Ubuntu Gutsy.
You menti
If that last mail wasn't wrapped correctly, I apologize.
It is entirely the fault of gmail.
On 2/1/08, Zbigniew <[EMAIL PROTECTED]> wrote:
> A multiple-value call takes the following route under Chicken:
___
Chicken-users mailing list
Chicken-users@non
Zbigniew scripsit:
> I ran Alex's test on a fast machine (Intel C2D 2GHz). Compiled with
> `csc -Ob values.scm`, Chicken 3.0.1 macosx-unix-gnu-x86, results below.
> I got the same disparity as Alex. I would be curious as to what
> platform you're running on, because I want it.
An ancient Dell L
On 1/31/08, John Cowan <[EMAIL PROTECTED]> wrote:
> Well, as I said, in Chicken values (multiple or otherwise) become the
> arguments of the continuation function, so they may or may not be on
> the C stack depending on what gcc does with them.
A multiple-value call takes the following route under
Alex Shinn scripsit:
> In general, unless the compiler natively takes MV into consideration
> and goes through the effort to place them on the stack (a complication
> which can make other optimizations more difficult, and which few
> compilers do anyway), then LIST is usually at least as fast as V
I really, really, loathe multiple values. I've argued the reasons
countless times before, and I'm not in the mood to do it again.
What I will do is point out is that the most natural (though not only)
alternative, just returning a first-class list, already has just as
concise syntax if you use MA
29 matches
Mail list logo
