Benjamin Franksen wrote:
David Barbour wrote:
Create an extra TVar Int for every `chunk` in the array (e.g every 256
elements, tuned to your update patterns). Read-write it (increment it, be
sure to force evaluation) just before every time you write an element or
slice it or slice the array
On Sun, Oct 30, 2011 at 6:20 PM, Ben Franksen ben.frank...@online.dewrote:
According to the original STM paper the implementation does an equality
test, albeit only for pointer equality.
It strikes me as bad form to depend on characteristics of `the
implementation`.
An incremented integer
David Barbour wrote:
Create an extra TVar Int for every `chunk` in the array (e.g every 256
elements, tuned to your update patterns). Read-write it (increment it, be
sure to force evaluation) just before every time you write an element or
slice it or slice the array element.
Incrementing and
On Tue, Oct 25, 2011 at 1:46 PM, Ben Franksen ben.frank...@online.dewrote:
IME, there are (at least) two possible problems
here, 1) transactions scale (quadratically, I think) with the number of
TVars touched,
Ouch! What would be the reason for that? I thought it would be linear... I
The main question is: does the STM transaction actually see that I
changed
part of the underlying array, so that the transaction gets re-tried? Or do
I
have to implement this manually, and if yes: how?
The transaction does not detect anything inside the unsafeIOtoSTM. But to
implement
I have an application in mind where concurrent access to large arrays (up to
millions of elements) of mostly small elements (Int or Double) is common.
Typical access patterns would be chunk-wise, i.e. reads or writes from index
n up to index m. Imagine stuff like images, scientific data, etc.
As far as I lnow the function 'unsafeIOToSTM' is not transactional in nature
- IO actions will be performed immediately and are not rolled back, and are
then re-performed on retry.
On Oct 25, 2011 12:49 PM, Ben Franksen ben.frank...@online.de wrote:
I have an application in mind where concurrent
On Tue, Oct 25, 2011 at 10:47 AM, Ben Franksen ben.frank...@online.dewrote:
The main question is: does the STM transaction actually see that I
changed
part of the underlying array, so that the transaction gets re-tried? Or do I
have to implement this manually, and if yes: how?
Create an
David Barbour wrote:
On Tue, Oct 25, 2011 at 10:47 AM, Ben Franksen
ben.frank...@online.dewrote:
The main question is: does the STM transaction actually see that I
changed
part of the underlying array, so that the transaction gets re-tried? Or do
I
have to implement this manually, and
Ben Franksen ben.frank...@online.de writes:
An array of TVars is certainly *much* too inefficient for what I have in
mind w.r.t. both memory and cpu time.
You must be a lot more confident than I if you say this without
benchmarking first. :-) IME, there are (at least) two possible problems
On Tue, Oct 25, 2011 at 1:24 PM, Ketil Malde ke...@malde.org wrote:
You must be a lot more confident than I if you say this without
benchmarking first. :-) IME, there are (at least) two possible problems
here, 1) transactions scale (quadratically, I think) with the number of
TVars touched, so
Ketil Malde wrote:
Ben Franksen ben.frank...@online.de writes:
An array of TVars is certainly *much* too inefficient for what I have in
mind w.r.t. both memory and cpu time.
You must be a lot more confident than I if you say this without
benchmarking first. :-)
Ok, not science, but an
12 matches
Mail list logo
