scrive / pool

A high-performance striped resource pooling implementation for Haskell
Other
18 stars 11 forks source link

Number of stripes is non-configurable #13

Closed parsonsmatt closed 1 year ago

parsonsmatt commented 1 year ago

Version 2 would accept an Int parameter for how many stripes to create. Version 3 uses getNumCapabilites unconditionally.

We're running into problems upgrading, and I think this may be related. Previously, with a createPool _ _ 1 3600 4 call, you'd have 1 stripe and 4 resources per stripe. But now you will have 4 stripes, with 1 resource per stripe. Locally, I'm seeing errors about "refusing to create resource 12", when we have a createPool _ _ 1 3600 4 call.

getNumCapabilities on my machine returns 20, so when we calculate the max resources, we get 4 (4 resources, 1 stripe). Then we get 20 stripes, each with 1 resource each.

I'd suggest adding a field for configuring stripe count on PoolConfig - that should alleviate this issue.

parsonsmatt commented 1 year ago

IMO it seems pretty dodgy that poolMaxResources is actually a lower bound on how many resources can be created, and that it can create potentially many more.

I'm going to submit a patch that accepts a poolNumStripes config parameter. The smallest change is to use that instead of getNumCapabilities when it is present. A more invasive change is to ensure that only enough Stripes are created such that poolMaxResources is never exceeded (ie requesting poolMaxResources = 4 and poolNumStripes = 5 only actually creates 4 stripes, so that we definitely do not exceed the poolMaxResources).

arybczak commented 1 year ago

Then we get 20 stripes, each with 1 resource each.

Out of curiosity, why are you running 20 capabilities? Do you have a machine with 20 physical cores?

parsonsmatt commented 1 year ago

Yes, my laptop has 20 cores. getNumCapabilities >>= print shows 20.

arybczak commented 1 year ago

I see. How many of these are physical? Asking since according to my experimentations running more capabilities than physical cores (and if you run with +RTS -N, getNumCapabilities will give you the number of logical cores) reduces performance, most likely due to GC overhead (and perhaps redundant context switches).

parsonsmatt commented 1 year ago

Huh apparently I have 14 physical cores, 8 "effiicency" and 6 "performance." Wild! And I guess hyperthreading gets me up to 20.