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

[John Meacham]

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/