In the lazy version, there seems to be more optimizations for aborting transations. In the eager version there are 2 writes before commit, one to memory and one to the undo buffer. If there is an abort, then there is a 3rd write to undo the instruction.
For this lazy implementation, however, if there is an abort, there is only a single write to the write buffer, while there is up to 2 total writes for a commit.
On the next slide, it says that lazy implementation has slower commits. Could this be explained?
bpr
@anamdev, when running in a transaction, a program will generate several writes to different locations in memory. With lazy, these writes are in the buffer, not in memory. On commit, each of these "lazy" writes must be propagated to memory, while "eager" writes are committed "for free". Note, the write / undo buffer is often an on-chip hardware structure, so the writes to the buffer are much cheaper than those to memory.
cuiwei
With eager versioning, say I write to a variable X 10 times, then I would incur 10 writes to memory at &X 10 times, as well as the write log 10 times. With lazy versioning, I only write to write buffer 10 times and to memory &X once. So though lazy versioning has slower commits, it has overall bettie performance, right?
wxt
@cuiwei it depends. To me, the concept of eager vs. lazy versioning seems very similar to the concept of write-through vs write-back caching. While one results in an up-to-date version in memory at all times, this isn't always necessary, say when writes and reads are spaced out into disjoint blocks of code (many writes, followed by many reads). As with all concepts in this class, it makes sense to choose the architecture that works best for your code, or write code that best fits your architecture.
In the lazy version, there seems to be more optimizations for aborting transations. In the eager version there are 2 writes before commit, one to memory and one to the undo buffer. If there is an abort, then there is a 3rd write to undo the instruction. For this lazy implementation, however, if there is an abort, there is only a single write to the write buffer, while there is up to 2 total writes for a commit.
On the next slide, it says that lazy implementation has slower commits. Could this be explained?
@anamdev, when running in a transaction, a program will generate several writes to different locations in memory. With lazy, these writes are in the buffer, not in memory. On commit, each of these "lazy" writes must be propagated to memory, while "eager" writes are committed "for free". Note, the write / undo buffer is often an on-chip hardware structure, so the writes to the buffer are much cheaper than those to memory.
With eager versioning, say I write to a variable X 10 times, then I would incur 10 writes to memory at &X 10 times, as well as the write log 10 times. With lazy versioning, I only write to write buffer 10 times and to memory &X once. So though lazy versioning has slower commits, it has overall bettie performance, right?
@cuiwei it depends. To me, the concept of eager vs. lazy versioning seems very similar to the concept of write-through vs write-back caching. While one results in an up-to-date version in memory at all times, this isn't always necessary, say when writes and reads are spaced out into disjoint blocks of code (many writes, followed by many reads). As with all concepts in this class, it makes sense to choose the architecture that works best for your code, or write code that best fits your architecture.