search for: txns

...the value in the first row of the dataframe is zero, and following rows add to this running balance. This is easy to write in a loop, but I can't seem to get it working in vectorised code. Hopefully the example below will explain what I'm trying to do... ##### # create a dummy dataframe txns <- data.frame(LETTERS) set.seed(123) # randomly specify debit / credit columns txns$drcr <- sample(c('d','c'), nrow(txns), replace=T) txns$dr <- 0 txns$cr <- 0 # give values to the debits / credits... txns[txns$drcr == 'd', 'dr'] <- runif(nrow(txns[tx...

...a txn begin do not get reused until a matching commit). LLVM currently skips stack slot coloring if setjmp is called in the function, so one could extend this to handling an returns- twice attribute. However, this coarse approach is costly (testing it with a microbenchmark (accessing a tree with txns), it decreased performance by 30%). 2) Functions that are called from txns get cloned and the clones get instrumented. The ABI requirements regarding how to store the clone functions in native code and how to look them up are not finalized yet, but it may require LLVM support as well. If devel...

...et reused > until a matching commit). LLVM currently skips stack slot coloring if setjmp > is called in the function, so one could extend this to handling an returns- > twice attribute. However, this coarse approach is costly (testing it with a > microbenchmark (accessing a tree with txns), it decreased performance by 30%). Just curious if LLVM's zero cost exception system (lib unwind like behavior), would have any effect on the above? > > 2) Functions that are called from txns get cloned and the clones get > instrumented. The ABI requirements regarding how to stor...

Hi Torvald, > I would like to know whether the community is interested in getting support > for Transactional Memory (TM) merged in upstream LLVM. I guess not :( TM basically gives you > transaction properties (eg, virtually atomic + isolated execution) for > ordinary program code. Thus, to make incrementing a counter thread-safe, you > could say __transaction { counter++; } and

...Torvald to see if he has ideas or insight? > http://llvm.org/pubs/2008-02-23-TRANSACT-TangerObjBased.html Yeah, this is TM-like with the begin/end/abort+rollback. Thanks for the pointer, but it seems like Tanger's implementation doesn't support explicit aborts probably "Because our txns never abort." So there wasn't a need to give a label to tanger_begin() to lead to an abort block. Ed

Hi, I would like to know whether the community is interested in getting support for Transactional Memory (TM) merged in upstream LLVM. TM basically gives you transaction properties (eg, virtually atomic + isolated execution) for ordinary program code. Thus, to make incrementing a counter thread-safe, you could say __transaction { counter++; } and the compiler would transform this code so

On Apr 19, 2008, at 1:30 PM, Edward Lee wrote: > On Sat, Apr 19, 2008 at 2:16 PM, Chris Lattner <sabre at nondot.org> > wrote: >> No. The reason we don't allow this is because it violates the CFG. > So if I *don't* violate the CFG, would I still need to do something > close to "big and nasty"? It sounds like you're doing something STM like, have

On Sat, Apr 19, 2008 at 2:16 PM, Chris Lattner <sabre at nondot.org> wrote: > No. The reason we don't allow this is because it violates the CFG. So if I *don't* violate the CFG, would I still need to do something close to "big and nasty"? ; save the address of %otherPath to use later call @llvm.checkpoint(label %otherPath) ; trick the rest of the compiler to

...do virsh list > /dev/null ; done Which takes approx 1m 45 seconds to complete. During this test run the CPU usage shown by top gives xenstored 70% utilization and xend about 15%. As noted before xenstored is bottlenecked doing disk I/O, since each txn requires a copy of the tdb database - 30 txns * 200 kb =~ 6 MB of I/O. As a quick ''hack'' I changed xend init script to have mkdir /dev/shm/xenstored mount --bind /dev/shm/xenstored /var/lib/xenstored Which puts xenstored''s database on tmpfs (ie RAM). This reduced the runtime of the test to 55 seconds on...

...1 Mount => Opts: 0x1 AtimeQuanta: 60 Cluster => Stack: o2cb Name: BC4F4550BEA74F92BDCC746AAD2EC0BF Version: 1.0 DownCnvt => Pid: 7330 Count: 0 WakeSeq: 149 WorkSeq: 149 Recovery => Pid: -1 Nodes: None Commit => Pid: 7335 Interval: 0 Needs: 1 Journal => State: 1 NumTxns: 32521 TxnId: 67 Stats => GlobalAllocs: 140 LocalAllocs: 192825 SubAllocs: 73299 LAWinMoves: 140 SAExtends: 72 Steal => Slot: -1 NumStolen: 0 Slots => Num Node RecoGen * 0 92 2 1 96 0 2 -1...

Please review the list of patches being applied to the ocfs2 1.4 tree. All patches list the mainline commit hash. Thanks Sunil

Hi, The following patches comprise the bulk of Ocfs2 updates for the 2.6.30 merge window. Aside from larger, more involved fixes, we're adding the following features, which I will describe in the order their patches are mailed. Sunil's exported some more state to our debugfs files, and consolidated some other aspects of our debugfs infrastructure. This will further aid us in debugging