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

[John Meacham]

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 <john at repetae.net> 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 <kiwamu at debian.or.jp> wrote:
>> Hi John,
>>
>> On Tue, Jun 10, 2014 at 8:49 PM, John Meacham <john at repetae.net> 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/