Nevertheless: maybe it would be feasible to do all second gen
gc in a dedicated thread and force a minor gc before passing data
between threads? Would it?
Unfortunately, execution and garbage collection are tightly interleaved
in the cheney-on-the-mta model.
But the idea is intriguing.
Felix scripsit:
Unfortunately, execution and garbage collection are tightly interleaved
in the cheney-on-the-mta model.
Minor collection is, but major collection could be run in a separate
thread so that it can run concurrently (even on a second core) with the
rest of the program. As it
*cringe*
This will certainly expose what is and is not thread-safe within
Chicken. I've worked with a /team/ in implementing such behaviour in the
Unreal engine, albeit a frankenengine of sorts, and with three dedicated
programmers the endeavour required about a month. But we had the benefit
From: John Cowan co...@mercury.ccil.org
Subject: Re: [Chicken-users] Best way to share memory between C and Chicken
Date: Mon, 6 May 2013 08:21:34 -0400
Felix scripsit:
Unfortunately, execution and garbage collection are tightly interleaved
in the cheney-on-the-mta model.
Minor
I cannot answer your question about performance, but you have prompted me
to create a simple example with POSIX shared memory. Attached are two
files, producer.c and consumer.scm. The producer (a C program) writes
strings to a POSIX shared memory file, and the consumer (a Scheme program)
reads
From: Thomas Chust ch...@web.de
Subject: Re: [Chicken-users] Best way to share memory between C and Chicken
Date: Sat, 04 May 2013 00:57:25 +0200
On 2013-05-04 00:26, Ivan Raikov wrote:
[...]
I really strongly advise _against_ using SRFI-4 vectors for 4G files,
as I have experienced serious
On 2013-05-05 13:54, Felix wrote:
[...]
SRFI-4 vectors live in the normal, heap that is subject to garbage
collection,
[...]
But note that the SRFI-4 constructors accept an optional argument
which specifies that the vector should be allocated in static,
non-GC'd memory.
[...]
Ah, cool.
I'll probably write the wiki page while taking the bus to work next
week, but for now I'm unaware of any issues and have a working example.
There's a test.scm file in the repo that gives a quick rundown on how to
use a (non-shared) semaphore. That is to say, if you're using fork() and
only
On May 4 2013, Ivan Raikov wrote:
I think you can try to have native threads by running a separate instance
of the Chicken runtime for each thread, but are you sure that you will
really achieve a significant speedup over Unix processes and/or MPI?
It's not the early nineties anymore... I
With semaphores and shared memory you can basically emulate the
behaviour you would expect from native threads. Though I'm not certain
about how comparable it is in performance, I understand it to be quite
zippy.
Ie, shm_open will give you a file descriptor, which you can then treat
as a
Hi all,
Sorry if this question is obvious, but I couldn't find what I were looking
for in the documentation so maybe you guys can help me.
I am developing a prototype of a server that would serve 3D seismic images
across the network. This task requires to process big files (~4 GB) with
existing
If it's heterogeneous data I tend to use blobs with helper functions to
cast segments to records without undertaking a copy.
https://wiki.call-cc.org/man/4/Unit%20library#blobs
If it's homogenous data then the srfi-4 unit provides all sorts of
vectors that you can use.
On 2013-05-03 20:04, Pedro Melendez wrote:
[...]
I am developing a prototype of a server that would serve 3D seismic
images across the network.
[...]
Hello Pedro,
it's nice to see I'm not the only geophysicist who likes to use Scheme :-)
[...]
Giving the size of the file, I want to share
Hello,
I really strongly advise _against_ using SRFI-4 vectors for 4G files, as
I have experienced serious performance issues even with vectors of a few
million elements. If your C code is to be linked with your Chicken code,
you can pass the pointer to your data from C to Scheme and use
On 2013-05-04 00:26, Ivan Raikov wrote:
[...]
I really strongly advise _against_ using SRFI-4 vectors for 4G files,
as I have experienced serious performance issues even with vectors of a
few million elements.
[...]
Hello,
would that be related to the fact that CHICKEN has a copying garbage
I was just poking through posix, posix-shm, posix-utils, and
posix-extras and it seems that none of them implement semaphores!
Am I missing something, or is this actually the case?
-Dan
On 5/3/2013 3:26 PM, Ivan Raikov wrote:
Hello,
I really strongly advise _against_ using SRFI-4 vectors
Hello,
Yes, it seems that copying/moving around large vectors puts a lot of
pressure on the memory subsystem. Other than that, SRFI-4 vectors are fine.
Ivan
On May 4, 2013 7:57 AM, Thomas Chust ch...@web.de wrote:
On 2013-05-04 00:26, Ivan Raikov wrote:
[...]
I really strongly advise
Are you talking about POSIX semaphores, sem_wait(3) and friends, or just
the general semaphor data structure? If the former, then the Chicken
developers are eagerly awaiting your patches ;-) If the latter, take a look
at the synch and mailbox eggs. They have mutex-like functionality that can
be
Yah, I meant sem_wait et al.
I was under the impression that synch and mailbox rely on srfi-18
structures, which would make them 'green' threads-only and not
particularly suitable for multi process synchronization.
Relatedly, is anyone poking at implementing native threads?
I've been digging
I think you can try to have native threads by running a separate instance
of the Chicken runtime for each thread, but are you sure that you will
really achieve a significant speedup over Unix processes and/or MPI?
It's not the early nineties anymore... I suggest prototyping code and
running
20 matches
Mail list logo
