Transactional memory?

[8l]

Hi, what is your plan about Restricted Transactional Memory (RTM)?

https://en.wikipedia.org/wiki/Transacti ... Extensions
http://arstechnica.com/business/2012/02 ... l-haswell/

[piotr5]

as I understood parallella aims at real-time-signal-processing and not at becoming some sort of internet server or database. so what exaactly is the benefit of transactional memory when you know quite exactly from the beginning how the data will flow? and even if I would let parallella handle some on-line requests with epiphany-programming directly, wouldn't software-side transactional memory make more sense here? I mean, there is hardware-support: everything done on-core stays on-core and can be (not so atomically) transmitted by dma at the end. so all you need is to somehow program the system responsible for dma-transfers to do stuff atomically. unlike with x86 that is actually possible, and unlike x86 there are additional processors available for such tasks. memory might be shared here, but that doesn't mean the compiler must under all circumstanes grant access to the memory used by other cores. it's as if you'd ask parallella to implement memory-protection...

[8l]

it is not about database, it is about general purpose programming.

[piotr5]

I said database or server! the point is that usually multithreaded wont access the same memory, unless user-input forces it to. and a single user isn't enough for that, a single user wants to see a single data. in other words, what applications for transactional memory do you foresee on the parallella? or more accurately, what advantages do you see in implementing it at runtime as opposed to emulating it at compile-time? starting a thread and then scratching it afterwards just because it accessed invalid data doesn't sound very efficient to me, a compiler could do it much more graciously...

[timpart]

It could be useful in any situation where multiple cores want to access the same memory, e.g. malloc will look at a shared linked list and update it. IT is a replacement for a mutualy exclusive function. Instead of claiming a mutex (which will work most of the time) and releasing it, the program starts a transaction does the list search and update then completes the transaction. It moves the burden of the progrmmer to the processor. It's rather a big burden too as the processor has to track all the reads and updates and compare them across cores. Not sure how a compier could do it without mutexes.

Tim

[piotr5]

imho it's the same situation as with garbage-collection: c++ doesn't need to collect garbage since all objects are automatically destroyed when they get out of scope. memory-management is a matter of object orjented programming, objects wont need any mutex when they are not in the global scope. there are many technologies in that direction, hardware-support seems to be the least efficient one. when using some lib, the multithreading is usually well-hidden. as for a memory-allocation table, there I see even less sense in resorting to transactional/versioned memory instead of whatever locking. as for multithreading with compile-time locking, I think it should be possible for a compiler to know how much time some function will take if that function is quite straight-forward, and I think there should be possibilities for giving the compiler hints on how to reorder the program's atoms so that all cores are used to the max, or maybe do that automatically too. sad thing is I know of no such attempts for extending languages to parse and generate runtime-speed hints or dependency hints, but it really isn't all that difficult on Epiphany through the clearly predictable assembler-behaviour in terms of speed...

[notzed]

This is for concurrency, not for databases or the like. It sounds a bit like an extended/automatic version of the atomic units in the CELL BEs.

In those you explicitly reserved up to four cache lines (iirc 128 bytes each) of global memory, and when they are written (the spu's can only read/write 128 bytes of global mem at a time) the atomic unit would discard the result if any other cpu had written to them since the reservation. So it's basically like a spin-lock but you always do some work within the loop. From memory it uses L1 or some hardware register, so it was very fast and not only an easy way to implement various concurrency primitives, it allowed for a bunch more stuff too.

Thing is, it still needs centrally managed arbitration (or at least a single point of monitoring like snooping the external adress bus), and it wouldn't scale very well to the sizes of the epiphany without a different approach. For starters you'd want it in LDS instead, which means the reservation would have to be local to the LDS, which means it would have to track reservations from all cpu's in the chip somehow.

[piotr5]

not that I would have any actual knowledge on the hardware side, but wouldn't it make sense if the transactional memory only were about special areas of memory that get accessed only through the underlying bus-system between the cores? I mean, if I have some shared area, then I don't need to treat it as local on-chip memory, and every core, including the one where it's stored, would access it through this bus-system and never through the machine-codes directly...

as for concurrency, I still am not convinced it really needs transactional memory. if I have sensors or whatever stream of input, then I need a buffer, but beyond that I see no need for protecting data, only the input and output. but then I guess that's because I tend to use parallellism for things that can be processed in parallel without overlapping data. if I need the same data for two processes then I just copy it since none of the programming languages I have seen really supports context-oriented objects (i.e. the same data-structure having completely different interface and data-type-protection depending on the context where it's used). true, for parallella such a programming language would be useful, to save on memory, maybe transactional memory is all it needs to force people into designing such a programming language or c++-lib or whatever...