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
On Feb 1, 2008, at 11:01 AM, David Brown wrote:
I'm noticing that most eggs and even a lot of the builtin libraries
use
strings to manipulate binary data. There is also a lot better
support for
string manipulation (SRFI-13).
Yeah, but see below.
However, R5RS doesn't require strings t
I'm noticing that most eggs and even a lot of the builtin libraries use
strings to manipulate binary data. There is also a lot better support for
string manipulation (SRFI-13).
However, R5RS doesn't require strings to be bytes.
So, am I safe, in Chicken, to use strings for binary data? I start
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
Available at http://synthcode.com/scheme/hato/
Hato is a full mail suite including an MTA which emphasizes
single-process user-level filtering of messages to keep spawning
of processes and copying and reparsing of mail to a minimum,
while allowing easy configuration and flexibility for users.
New
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
https://galinha.ucpel.tche.br/cgi-bin/svnwiki/default/r-kent-dybvig-oscar-waddell-bob-hieb-carl-bruggeman
someone might want to remove the node, i just made it empty.
./rm
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.o
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 Jan 31, 2008 5:45 PM, Mark Fredrickson <[EMAIL PROTECTED]> wrote:
>
> I assume you mean extending (declare (exports )) to something like
> (declare
>(exports
> ((square ((required int) (docstring "Returns the square of it's
> input"))
>
I recommend not to use "declare". There i
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
On Feb 1, 2008 7:35 AM, Daishi Kato <[EMAIL PROTECTED]> wrote:
> Hi,
>
> The example in the page of smtp egg doesn't work.
> I'd suggest to add a finalizer to the port generated by smtp:open.
> Or any other solution?
It is probably easier to simply close the port properly. Sorry for the
silly mist
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
21 matches
Mail list logo
