<bslsk05>
'I, Robot - Human emotions scene' by Facundo Verdun (00:01:52)
<mrvn>
GeDaMo: barely
<GeDaMo>
I might be able to design one but building one is beyond me :P
particleflux_ has joined #osdev
particleflux has quit [Ping timeout: 240 seconds]
particleflux_ is now known as particleflux
h4zel has quit [Ping timeout: 268 seconds]
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
ZipCPU has quit [Ping timeout: 245 seconds]
Ram-Z has quit [Ping timeout: 245 seconds]
wootehfoot has joined #osdev
<gorgonical>
Friday afternoon off-topic: I have just learned that the only trappist brewery in the US has ceased production. This will stifle my plans to try all the trappist beers
poyking16 has quit [Quit: WeeChat 3.6]
ZipCPU has joined #osdev
<mrvn>
better hurry before they are sold out
Ram-Z has joined #osdev
hypoalgesia has joined #osdev
tsraoien has quit [Ping timeout: 252 seconds]
Starfoxxes has quit [Ping timeout: 276 seconds]
GeDaMo has quit [Quit: There is as yet insufficient data for a meaningful answer.]
Starfoxxes has joined #osdev
tsraoien has joined #osdev
bradd has quit [Ping timeout: 252 seconds]
pretty_dumm_guy has quit [Ping timeout: 245 seconds]
<bslsk05>
lists.riscv.org: Re: Requirements for 128-bit atomic operations
<clever>
STM on haskell also operates in a manner similar to load/store exclusive on arm
<moon-child>
ll/sc is basically a just a transaction on one cache line
<moon-child>
(or word? idk, w/e)
<clever>
basically, the first time your STM code reads an atomic variable, the engine will save the serial# and current value of that variable, and report the value to your code
<clever>
and if you try to write to an atomic variable, it will just note the current serial# of that var, and store that as well
<clever>
once you try to commit all changes, the engine will grab a global mutex, and check the serial# of every atomic var you touched in any way
<clever>
if the serial#'s all match, then it commits the writes you requested, and increments the serial# for each atomic you modified
<clever>
and releases the global lock
<mjg>
wut?
<clever>
if you lost the race (same as conditional store-exclusive on arm), then the write doesnt happen
<mjg>
how global is it so to speak
<mjg>
i mean what's the scope
<clever>
and the engine re-tries the entire codeblock
<mjg>
is this for any stm use?
<clever>
moon-child: i think its for any stm usage, within the process
<mjg>
well you make it sound as it does not perform for shit
<clever>
the idea, is that all of the computation is done lockless
<clever>
and only when you commit the data, does it check if it lost the race or not
<mjg>
which given a fp language would not be particualaly surprising
<mjg>
will have to look at haskell benchmarks at some point
<clever>
the critical part, that really relies on a FP language, is that the engine can potentially re-run this atomic chunk of code many times
<clever>
and there should not be any side-effects from running it a dozen times
<bslsk05>
groups.google.com: STM criticism from Azul Systems
<clever>
haskell solves that, by just not giving you IO, which is required for side-effects
<clever>
STM then lets you build any complex atomic operation you want, like atomicly moving data from one fifo to another
<clever>
moon-child: i have also seen STM backfire heavily, when lazyness also gets involved
<clever>
but that also involved lazy blackholing, and hash tables
<clever>
moon-child: have you heard about blackholing and lazy black holing?
<moon-child>
nope
<clever>
moon-child: basically, most functional languages break the code up into thunks, as a very crude example, (5*10)+30, might get broken up into a=5*10; b=a+30;
<clever>
and each thunk, has a type (integer, thunk), and a value (5, or a function pointer)
<clever>
and as the engine recursively turns thunks into concrete values, it will temporarily change the type to black-hole
<clever>
and if it encounters another black hole, then it has ran into its own stack trace, and you essentially have an `a = a;` case
<clever>
where you can never determine the value of an expression
<clever>
but when threads get involved, you need to change the rules some, every thunk now needs: the type to be blackhole, and a mutex you can wait on, with a way to know if your thread already holds it
<clever>
moon-child: so if one thread starts computing the value of `a`, and a second thread also needs `a`, it can wait for the mutex to be released, and then read the result
<clever>
moon-child: the problem then, is that you dont want to grab a whole mutex, just to compute a simple 5*10, and write it back to a slot!
<clever>
which is where lazy blackholing comes in, you just dont set the type as blackhole
<clever>
and you write the result to the slot when your done computing
<clever>
if a second thread was racing you, it overwrites the result of 5*10, with the result of 5*10, and no harm happens
<moon-child>
hmm
<moon-child>
what if you unsafeperformio?
<clever>
i believe the compiler knows thats unsafe, and wont be lazy about that blackhole
<clever>
so it gets a proper mutex, and only runs in one thread
<moon-child>
I thought the whole point of unsafeperformio is that it's opaque wrt the type system
<moon-child>
and--say, it's in another tu or whatever
<clever>
i'm fuzzy on the exact implementation details, and there is an even more unsafe one, just wait till you see its name :P