Re: [Haskell-cafe] [Rejected Paper] Experience Report: Writing NetBSD Sound Drivers in Haskell

Hmm.. well in any case, collecting the whole context into a handy struct is a good cleanup anyway, even if there is just a single global one. So I should backport that as well as the pthreads code. On Tue, Jun 10, 2014 at 5:07 AM, John Meacham wrote:

Yeah, find_cache is fairly slow. In fact, just checking if it is NULL noticibly slows things down.

So, something that could be done is generate a struct with each cache used as offsets in it, basically putting the entire generate s_cache table in a struct then initializing them all when the arena is allocated. that would add a single redirect thruogh the arena to the caches which might not be too bad...

what would be better is to use a thread or processor local register.

John

On Tue, Jun 10, 2014 at 4:58 AM, Kiwamu Okabe wrote:

...

Hi John,

On Tue, Jun 10, 2014 at 8:49 PM, John Meacham wrote:

...

The main issue would be how it affects allocation speed, its okay to make the GC slower as long as allocation is still fast, Before pre-populating the cache pointers sped things up considerably, how would it make sure to use one from the current arena without slowing down allocation in general?

So I don't have any benchmark for it today. I worry about the cost initializing arena when C=>Haskell. Current jgc has no cost, but my jgc initializes arena when C=>Haskell everytime. Please imagine the cost call all of find_cache().

Regards, -- Kiwamu Okabe at METASEPI DESIGN

-- John Meacham - http://notanumber.net/

-- John Meacham - http://notanumber.net/