similar to: [LLVMdev] About clock and wait instruction

On Fri, 19 Dec 2003, Yueqiang wrote: > In high level languge there are usually have time and sync instruction, > to handle async and sync operation. > I want to know how LLVM take an count of these. I'm not sure exactly what 'time' and 'sync' operations you're talking about, or what languages support them. However, LLVM is designed to make it trivial to

hi, In high level languge there are usually have time and sync instruction, to handle async and sync operation. I want to know how LLVM take an count of these. thanks yueqiang 2003/12/19 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20031218/07381085/attachment.html>

Chris Lattner wrote: > On Fri, 19 Dec 2003, Yueqiang wrote: > > >>In high level languge there are usually have time and sync instruction, >>to handle async and sync operation. >>I want to know how LLVM take an count of these. > > > I'm not sure exactly what 'time' and 'sync' operations you're talking > about, or what languages

On 05/05/2015 07:21 PM, Jeremy Fitzhardinge wrote: > On 05/03/2015 10:55 PM, Juergen Gross wrote: >> I did a small measurement of the pure locking functions on bare metal >> without and with my patches. >> >> spin_lock() for the first time (lock and code not in cache) dropped from >> about 600 to 500 cycles. >> >> spin_unlock() for first time dropped

On 05/05/2015 07:21 PM, Jeremy Fitzhardinge wrote: > On 05/03/2015 10:55 PM, Juergen Gross wrote: >> I did a small measurement of the pure locking functions on bare metal >> without and with my patches. >> >> spin_lock() for the first time (lock and code not in cache) dropped from >> about 600 to 500 cycles. >> >> spin_unlock() for first time dropped

On 05/03/2015 10:55 PM, Juergen Gross wrote: > I did a small measurement of the pure locking functions on bare metal > without and with my patches. > > spin_lock() for the first time (lock and code not in cache) dropped from > about 600 to 500 cycles. > > spin_unlock() for first time dropped from 145 to 87 cycles. > > spin_lock() in a loop dropped from 48 to 45 cycles.

* Juergen Gross <jgross at suse.com> wrote: > On 05/05/2015 07:21 PM, Jeremy Fitzhardinge wrote: > >On 05/03/2015 10:55 PM, Juergen Gross wrote: > >>I did a small measurement of the pure locking functions on bare metal > >>without and with my patches. > >> > >>spin_lock() for the first time (lock and code not in cache) dropped from >

Reid Spencer <reid at x10sys.com> wrote: >> Currently we do little more than let programs use pthreads or some >> other threading library, but we do intend to eventually add first-class >> synchronization support to LLVM. This will develop as there is a need. > There _is_ a need :) .. let me know if I can help in this area, it is > one of the key things I need for

Does LLVM called the pthread directly? and what time do you plan to release Java front end? I'll try this. ----- Original Message ----- From: "Chris Lattner" <sabre at nondot.org> To: "yue" <qiangyue at ict.ac.cn> Cc: <llvmdev at cs.uiuc.edu> Sent: Wednesday, December 24, 2003 12:47 PM Subject: Re: [LLVMdev] GCC3.5 tree-ssa > On Wed, 24 Dec 2003,

Just as I create a ZFS pool and copy the root partition to it.... the performance seems to be really good then suddenly the system hangs all my sesssions and displays on the console: Oct 10 00:23:28 sunrise arcmsr: WARNING: arcmsr0: dma map got ''no resources'' Oct 10 00:23:28 sunrise arcmsr: WARNING: arcmsr0: dma allocate fail Oct 10 00:23:28 sunrise arcmsr: WARNING: arcmsr0:

On Wed, 24 Dec 2003, yue wrote: > I try to run lli with "--load=/lib/libpthread.so", but it shows: > --------------------------------------------------- > [yue at RH9 test]$ ./pthread.ll > Error opening '/lib/libpthread.so.0': /lib/libpthread.so.0: symbol > _errno, version GLIBC_2.0 not defined in file libc.so.6 with link time > reference > -load request

On Tue, Nov 17, 2015 at 08:08:18PM -0800, Venkatesh Srinivas wrote: > On Mon, Nov 16, 2015 at 7:46 PM, Xie, Huawei <huawei.xie at intel.com> wrote: > > > On 11/14/2015 7:41 AM, Venkatesh Srinivas wrote: > > > On Wed, Nov 11, 2015 at 02:34:33PM +0200, Michael S. Tsirkin wrote: > > >> On Tue, Nov 10, 2015 at 04:21:07PM -0800, Venkatesh Srinivas wrote: >

On 11/18/2015 12:28 PM, Venkatesh Srinivas wrote: > On Tue, Nov 17, 2015 at 08:08:18PM -0800, Venkatesh Srinivas wrote: >> On Mon, Nov 16, 2015 at 7:46 PM, Xie, Huawei <huawei.xie at intel.com> wrote: >> >>> On 11/14/2015 7:41 AM, Venkatesh Srinivas wrote: >>>> On Wed, Nov 11, 2015 at 02:34:33PM +0200, Michael S. Tsirkin wrote: >>>>> On Tue,

On Mon, Nov 16, 2015 at 7:46 PM, Xie, Huawei <huawei.xie at intel.com> wrote: > On 11/14/2015 7:41 AM, Venkatesh Srinivas wrote: > > On Wed, Nov 11, 2015 at 02:34:33PM +0200, Michael S. Tsirkin wrote: > >> On Tue, Nov 10, 2015 at 04:21:07PM -0800, Venkatesh Srinivas wrote: > >>> Improves cacheline transfer flow of available ring header. > >>> >

On Mon, Nov 16, 2015 at 7:46 PM, Xie, Huawei <huawei.xie at intel.com> wrote: > On 11/14/2015 7:41 AM, Venkatesh Srinivas wrote: > > On Wed, Nov 11, 2015 at 02:34:33PM +0200, Michael S. Tsirkin wrote: > >> On Tue, Nov 10, 2015 at 04:21:07PM -0800, Venkatesh Srinivas wrote: > >>> Improves cacheline transfer flow of available ring header. > >>> >

Hi Silky, On 14/01/13 01:47, Silky Arora wrote: > I need to profile the code for branches (branch mis predicts > simulation), load/store instructions (for cache hits/miss rate), and a > couple of other things and therefore, would need to instrument the code. > However, I would like to know if writing the output to a file would > increase the execution time, or is it the profiling

kill dead ocfs_empty stuff, cleanup d_revalidate handling. Index: dcache.c =================================================================== --- dcache.c (revision 1091) +++ dcache.c (working copy) @@ -44,24 +44,11 @@ #define OCFS_DEBUG_CONTEXT OCFS_DEBUG_CONTEXT_DCACHE -static int ocfs_empty_func(struct dentry *dentry, void *ignore); - -/* - * ocfs_dentry_revalidate() - * - */ -#if

On Nov 30, 2010, at 2:19 PM, Xinliang David Li wrote: > I understand that, but that implies that you have some model for code locality. Setting a global code growth limit is (in my opinion) a hack unless you are aiming for the whole program to fit in the icache (which I don't think anyone tries to do :). > > Yes, global growth limit may be good for size control, but is a hack for

On Tue, Nov 30, 2010 at 2:29 PM, Chris Lattner <clattner at apple.com> wrote: > > On Nov 30, 2010, at 2:19 PM, Xinliang David Li wrote: > > I understand that, but that implies that you have some model for code >> locality. Setting a global code growth limit is (in my opinion) a hack >> unless you are aiming for the whole program to fit in the icache (which I

On 11/14/2015 7:41 AM, Venkatesh Srinivas wrote: > On Wed, Nov 11, 2015 at 02:34:33PM +0200, Michael S. Tsirkin wrote: >> On Tue, Nov 10, 2015 at 04:21:07PM -0800, Venkatesh Srinivas wrote: >>> Improves cacheline transfer flow of available ring header. >>> >>> Virtqueues are implemented as a pair of rings, one producer->consumer >>> avail ring and