On Mon, Apr 23, 2012 at 5:56 PM, Jeffrey Squyres wrote:
> On Apr 23, 2012, at 5:53 PM, George Bosilca wrote:
>
>> However, I did a quick grep and most of our headers are larger than a single
>> line of cache (even Itanium L2) so I suppose that making
>> opal_cache_line_size equal to the L2 cache
On Apr 23, 2012, at 5:53 PM, George Bosilca wrote:
> However, I did a quick grep and most of our headers are larger than a single
> line of cache (even Itanium L2) so I suppose that making opal_cache_line_size
> equal to the L2 cache line size will not be a too big waste of memory overall.
Easy
I guess at the end is a trade-off between performance and space. What we wanted
with this code is to avoid false sharing of cache lines between our data
(internal header we add in from of elements in lists) and the content of the
data (whatever is coming from the upper layer).
If the header is
On 4/23/2012 8:22 AM, Jeffrey Squyres wrote:
On Apr 23, 2012, at 1:40 AM, Eugene Loh wrote:
[rhc@odin001 ~/svn-trunk]$ mpifort --showme
gfortran -I/nfs/rinfs/san/homedirs/rhc/openmpi/include
-I/nfs/rinfs/san/homedirs/rhc/openmpi/lib
-L/nfs/rinfs/san/homedirs/rhc/openmpi/lib -lmpi_usempi -lmpi_
On Mon, Apr 23, 2012 at 4:21 PM, Jeffrey Squyres wrote:
> No one replied to this RFC. Does anyone have an opinion about it?
>
> I have attached a patch (including some debugging output) showing my initial
> implementation. If no one objects by the end of this week, I'll commit to
> the trunk.
Good catch; fixed.
On Apr 23, 2012, at 4:40 PM, George Bosilca wrote:
> No strong opinion. However, the comment about the initial value of
> opal_cache_line_size is wrong (opal/runtime/opal.h), as it states that the
> default value is -1 while it is 128.
>
> george.
>
> On Apr 23, 2012, at 1
No strong opinion. However, the comment about the initial value of
opal_cache_line_size is wrong (opal/runtime/opal.h), as it states that the
default value is -1 while it is 128.
george.
On Apr 23, 2012, at 16:21 , Jeffrey Squyres wrote:
> No one replied to this RFC. Does anyone have an opi
No one replied to this RFC. Does anyone have an opinion about it?
I have attached a patch (including some debugging output) showing my initial
implementation. If no one objects by the end of this week, I'll commit to the
trunk.
Terry: please add this to the agenda tomorrow.
On Mar 30, 2012,
On Apr 23, 2012, at 1:40 AM, Eugene Loh wrote:
>> [rhc@odin001 ~/svn-trunk]$ mpifort --showme
>> gfortran -I/nfs/rinfs/san/homedirs/rhc/openmpi/include
>> -I/nfs/rinfs/san/homedirs/rhc/openmpi/lib
>> -L/nfs/rinfs/san/homedirs/rhc/openmpi/lib -lmpi_usempi -lmpi_mpifh -lmpi
>> -lopen-rte -lopen-p
On Apr 21, 2012, at 10:36 AM, Eugene Loh wrote:
> Another probably-Fortran-merge problem. Three issues in this e-mail.
Thanks for digging in to these!
> #1) Isn't there supposed to be some diplomatic message about trying to use
> openib without threads?
>
> Woke up on the wrong side of bed,
On 4/22/2012 9:53 AM, Ralph Castain wrote:
Hmmm…I don't see that happening, Eugene:
[rhc@odin001 ~/svn-trunk]$ mpifort --showme
gfortran -I/nfs/rinfs/san/homedirs/rhc/openmpi/include
-I/nfs/rinfs/san/homedirs/rhc/openmpi/lib
-L/nfs/rinfs/san/homedirs/rhc/openmpi/lib -lmpi_usempi -lmpi_mpifh -l
11 matches
Mail list logo
