On Tue, Mar 14, 2017 at 4:59 PM, Jed Brown wrote:
> Richard Mills writes:
>
> > On Tue, Mar 14, 2017 at 2:18 PM, Jed Brown wrote:
> >
> >> Richard Mills writes:
> >>
> >> > On Tue, Mar 14, 2017 at 1:23 PM, Jed Brown wrote:
> >> >
> >> >> Barry Smith writes:
> >> >>
> >> >> >> On Mar 13, 2017
Richard Mills writes:
> On Tue, Mar 14, 2017 at 2:18 PM, Jed Brown wrote:
>
>> Richard Mills writes:
>>
>> > On Tue, Mar 14, 2017 at 1:23 PM, Jed Brown wrote:
>> >
>> >> Barry Smith writes:
>> >>
>> >> >> On Mar 13, 2017, at 1:27 PM, Jed Brown wrote:
>> >> >>
>> >> >> Satish Balay writes:
>
On Tue, Mar 14, 2017 at 2:18 PM, Jed Brown wrote:
> Richard Mills writes:
>
> > On Tue, Mar 14, 2017 at 1:23 PM, Jed Brown wrote:
> >
> >> Barry Smith writes:
> >>
> >> >> On Mar 13, 2017, at 1:27 PM, Jed Brown wrote:
> >> >>
> >> >> Satish Balay writes:
> >> >>> stash the metadata for each
On Tue, Mar 14, 2017 at 2:17 PM, Jed Brown wrote:
> Barry Smith writes:
> >Well it actually does something malloc doesn't do. It allows for
> >multiple malloc backends,
>
> A malloc implementation can have multiple arenas.
>
Sure. But are we confident that one of these multiple-arena m
Richard Mills writes:
> On Tue, Mar 14, 2017 at 1:23 PM, Jed Brown wrote:
>
>> Barry Smith writes:
>>
>> >> On Mar 13, 2017, at 1:27 PM, Jed Brown wrote:
>> >>
>> >> Satish Balay writes:
>> >>> stash the metadata for each allocation (and pointers for corresponding
>> >>> free) in a hash table
Barry Smith writes:
>Well it actually does something malloc doesn't do. It allows for
>multiple malloc backends,
A malloc implementation can have multiple arenas.
>and possibly allows for other things like tracking how often the
>malloced space is accessed.
How?
>And keeps
> On Mar 14, 2017, at 4:04 PM, Jed Brown wrote:
>
> Barry Smith writes:
>
>>> On Mar 14, 2017, at 3:23 PM, Jed Brown wrote:
>>>
>>> Barry Smith writes:
>>>
> On Mar 13, 2017, at 1:27 PM, Jed Brown wrote:
>
> Satish Balay writes:
>> stash the metadata for each allocation
Barry Smith writes:
>> On Mar 14, 2017, at 3:23 PM, Jed Brown wrote:
>>
>> Barry Smith writes:
>>
On Mar 13, 2017, at 1:27 PM, Jed Brown wrote:
Satish Balay writes:
> stash the metadata for each allocation (and pointers for corresponding
> free) in a hash table for a
On Tue, Mar 14, 2017 at 1:23 PM, Jed Brown wrote:
> Barry Smith writes:
>
> >> On Mar 13, 2017, at 1:27 PM, Jed Brown wrote:
> >>
> >> Satish Balay writes:
> >>> stash the metadata for each allocation (and pointers for corresponding
> >>> free) in a hash table for all mallocs that we need to t
> On Mar 14, 2017, at 3:23 PM, Jed Brown wrote:
>
> Barry Smith writes:
>
>>> On Mar 13, 2017, at 1:27 PM, Jed Brown wrote:
>>>
>>> Satish Balay writes:
stash the metadata for each allocation (and pointers for corresponding
free) in a hash table for all mallocs that we need to tra
Barry Smith writes:
>> On Mar 13, 2017, at 1:27 PM, Jed Brown wrote:
>>
>> Satish Balay writes:
>>> stash the metadata for each allocation (and pointers for corresponding
>>> free) in a hash table for all mallocs that we need to track? [this
>>> avoids the wasted 'space' in each alloc.]
>>
>>
> On Mar 13, 2017, at 1:27 PM, Jed Brown wrote:
>
> Satish Balay writes:
>> stash the metadata for each allocation (and pointers for corresponding
>> free) in a hash table for all mallocs that we need to track? [this
>> avoids the wasted 'space' in each alloc.]
>
> Sure, but this is just dupli
> On Mar 13, 2017, at 9:37 PM, Jeff Hammond wrote:
>
> OpenMP did not prevent OpenCL, C11, C++11 or Fortran 2008 from introducing
> parallelism. Not sure if your comment was meant to be serious, but it appears
> unfounded nonetheless.
Ahh, but note that all of the "introduced parallelisms"
Jeff Hammond writes:
> OpenMP did not prevent OpenCL,
This programming model isn't really intended for architectures with
persistent caches.
> C11, C++11
These are basically pthreads, which predates OpenMP.
> or Fortran 2008
A different language and doesn't play well with others.
> from i
OpenMP did not prevent OpenCL, C11, C++11 or Fortran 2008 from introducing
parallelism. Not sure if your comment was meant to be serious, but it
appears unfounded nonetheless.
Jeff
On Sun, Mar 12, 2017 at 11:16 AM Jed Brown wrote:
> Implementation-defined, but it's exactly the same as malloc, w
On Mon, Mar 13, 2017 at 11:27 AM, Jed Brown wrote:
> Satish Balay writes:
> > stash the metadata for each allocation (and pointers for corresponding
> > free) in a hash table for all mallocs that we need to track? [this
> > avoids the wasted 'space' in each alloc.]
>
> Sure, but this is just dup
On Mon, Mar 13, 2017 at 11:21 AM, Satish Balay wrote:
> On Sun, 12 Mar 2017, Karl Rupp wrote:
>
> >
> > > > If, however, the long-term goal is to get rid of global state, then
> we
> > > > would have to store a matching deallocation routine with the raw
> buffer.
> > > > Actually, you could store
Satish Balay writes:
> stash the metadata for each allocation (and pointers for corresponding
> free) in a hash table for all mallocs that we need to track? [this
> avoids the wasted 'space' in each alloc.]
Sure, but this is just duplicating an implementation of malloc.
signature.asc
Descriptio
On Sun, 12 Mar 2017, Karl Rupp wrote:
>
> > > If, however, the long-term goal is to get rid of global state, then we
> > > would have to store a matching deallocation routine with the raw buffer.
> > > Actually, you could store the function pointers to malloc/realloc/free in
> > > the first bytes
> On Mar 11, 2017, at 2:36 PM, Jed Brown wrote:
>
> Barry Smith writes:
>
>>> I think it's accurate in the sense that the performance of real
>>> applications using a page migration system will be sufficiently close to
>>> the best manual page mapping strategy that nobody should bother with th
On Fri, Mar 10, 2017 at 11:52 AM, Barry Smith wrote:
>
> > On Mar 10, 2017, at 12:04 AM, Richard Mills
> wrote:
> [...]
> > Personally, I think that memkind is something we should support it in
> PETSc.
>
>Yes, the question is how do we "support it"? Do we have a PETSc malloc
> API and then
On Sat, Mar 11, 2017 at 12:36 PM, Jed Brown wrote:
> Barry Smith writes:
>
> >> I think it's accurate in the sense that the performance of real
> >> applications using a page migration system will be sufficiently close to
> >> the best manual page mapping strategy that nobody should bother with
Implementation-defined, but it's exactly the same as malloc, which also doesn't
promise unfaulted pages. This is one reason some of us keep saying that OpenMP
sucks. It's a shitty standard that obstructs better standards from being
created.
On March 12, 2017 11:19:49 AM MDT, Jeff Hammond wrote
my only concern with this solution is that the lookup via indices relies on
global state. Since PETSc relies on global state at a bunch of other places
(e.g. logging), this may not be a relevant concern.
The OS keeps a little global state around too :-( What's the harm in this little tabl
On Sat, Mar 11, 2017 at 9:00 AM Jed Brown wrote:
> Jeff Hammond writes:
> > I agree 100% that multithreaded codes that fault pages from the main
> thread in a NUMA environment are doing something wrong ;-)
> >
> > Does calloc *guarantee* pages are not mapped? If I calloc(8), do I get
> the zero
Barry Smith writes:
>> I think it's accurate in the sense that the performance of real
>> applications using a page migration system will be sufficiently close to
>> the best manual page mapping strategy that nobody should bother with the
>> manual system.
>
>Will such a page migration system
> On Mar 11, 2017, at 1:11 PM, Jed Brown wrote:
>
> Barry Smith writes:
>
>>> On Mar 10, 2017, at 1:52 PM, Barry Smith wrote:
>>>
>>>
>>> Now I have read through all the old email from Jed to understand why he
>>> hates memkind so much.
>>>
>>
>> I have read through all the emails and
Barry Smith writes:
>> On Mar 10, 2017, at 1:52 PM, Barry Smith wrote:
>>
>>
>> Now I have read through all the old email from Jed to understand why he
>> hates memkind so much.
>>
>
>I have read through all the emails and admit I still don't understand
> anything. I have pasted all t
Jeff Hammond writes:
> I agree 100% that multithreaded codes that fault pages from the main thread
> in a NUMA environment are doing something wrong ;-)
>
> Does calloc *guarantee* pages are not mapped? If I calloc(8), do I get the
> zero page or part of the arena that's already mapped that is z
On 10 March 2017 at 22:51, Jeff Hammond wrote:
>
>
> On Fri, Mar 10, 2017 at 9:09 AM, Barry Smith wrote:
>
>>
>> > On Mar 10, 2017, at 9:58 AM, Lisandro Dalcin wrote:
>> >
>> > On 10 March 2017 at 03:19, Barry Smith wrote:
>> > PetscMallocRegister(malloc,realloc,free,&basicmalloc);
>> >
> On Mar 10, 2017, at 12:42 PM, Jed Brown wrote:
>
> Jeff Hammond writes:
>> My intuition is that any HPC code that benefits from mapping the zero page
>> vs memset is doing something wrong.
>
> The relevant issue is the interface, from
>
> a = malloc(size);
> // need to fault the memory u
Why should Apple support some crappy programming model?
> On Mar 10, 2017, at 8:52 PM, Jeff Hammond wrote:
>
>>
>> Disappointing on my Mac.
>>
>> WARNING: Could not locate OpenMP support. This warning can also occur if
>> compiler already supports OpenMP
>> checking omp.h usability... no
>
> Disappointing on my Mac.
>
> WARNING: Could not locate OpenMP support. This warning can also occur if
> compiler already supports OpenMP
> checking omp.h usability... no
> checking omp.h presence... no
> checking for omp.h... no
> omp.h is required for this library
>
Blame Apple for not s
> On Mar 10, 2017, at 1:52 PM, Barry Smith wrote:
>
>
> Now I have read through all the old email from Jed to understand why he
> hates memkind so much.
>
I have read through all the emails and admit I still don't understand
anything. I have pasted all the juicier bits at the bottom.
Jeff Hammond writes:
> My intuition is that any HPC code that benefits from mapping the zero page
> vs memset is doing something wrong.
The relevant issue is the interface, from
a = malloc(size);
// need to fault the memory using first-touch
#pragma omp parallel
{
// memset my part
> On Mar 10, 2017, at 12:04 AM, Richard Mills wrote:
>
> On Thu, Mar 9, 2017 at 9:05 PM, Jeff Hammond wrote:
>
>
> On Thu, Mar 9, 2017 at 8:08 PM, Richard Mills wrote:
> On Thu, Mar 9, 2017 at 7:45 PM, Jeff Hammond wrote:
>
> I started to play with memkind last summer. At that time, there
On Fri, Mar 10, 2017 at 9:09 AM, Barry Smith wrote:
>
> > On Mar 10, 2017, at 9:58 AM, Lisandro Dalcin wrote:
> >
> > On 10 March 2017 at 03:19, Barry Smith wrote:
> > PetscMallocRegister(malloc,realloc,free,&basicmalloc);
> > PetscMallocRegister(PetscMallocDebug,PetscReallocDebug,
> Pe
> On Mar 10, 2017, at 9:58 AM, Lisandro Dalcin wrote:
>
>
> On 10 March 2017 at 03:19, Barry Smith wrote:
> PetscMallocRegister(malloc,realloc,free,&basicmalloc);
>
> PetscMallocRegister(PetscMallocDebug,PetscReallocDebug,PetscFreeDebug,&debugmalloc);
>
> PetscMallocRegister(Pets
> On Mar 10, 2017, at 8:45 AM, Karl Rupp wrote:
>
> Hey,
>
> my only concern with this solution is that the lookup via indices relies on
> global state. Since PETSc relies on global state at a bunch of other places
> (e.g. logging), this may not be a relevant concern.
The OS keeps a littl
On 10 March 2017 at 03:19, Barry Smith wrote:
> PetscMallocRegister(malloc,realloc,free,&basicmalloc);
> PetscMallocRegister(PetscMallocDebug,PetscReallocDebug,
> PetscFreeDebug,&debugmalloc);
> PetscMallocRegister(PetscMallocHBW,PetscReallocHBW,PetscFreeHBW,&
> hbwmalloc);
>
I'm won
Hey,
my only concern with this solution is that the lookup via indices relies
on global state. Since PETSc relies on global state at a bunch of other
places (e.g. logging), this may not be a relevant concern.
If, however, the long-term goal is to get rid of global state, then we
would have t
On Thu, Mar 9, 2017 at 9:05 PM, Jeff Hammond wrote:
>
>
> On Thu, Mar 9, 2017 at 8:08 PM, Richard Mills
> wrote:
>
>> On Thu, Mar 9, 2017 at 7:45 PM, Jeff Hammond
>> wrote:
>>
>>>
I started to play with memkind last summer. At that time, there were
plenty of sayings online like this:
On Thu, Mar 9, 2017 at 7:45 PM, Jeff Hammond wrote:
>
>> I started to play with memkind last summer. At that time, there were
>> plenty of sayings online like this:
>> "the *hbwmalloc* interface is stable but *memkind* interface is only
>> partially stable."
>>
>>
> If you want the most stable in
On Thu, Mar 9, 2017 at 7:04 PM, Zhang, Hong wrote:
>
> On Mar 9, 2017, at 8:50 PM, Barry Smith wrote:
>
>
> On Mar 9, 2017, at 8:29 PM, Zhang, Hong wrote:
>
>
> On Mar 9, 2017, at 7:38 PM, Barry Smith wrote:
>
>
> On Mar 9, 2017, at 7:18 PM, Richard Mills wrote:
>
> Hi Barry,
>
> I like the s
>
>
> I started to play with memkind last summer. At that time, there were
> plenty of sayings online like this:
> "the *hbwmalloc* interface is stable but *memkind* interface is only
> partially stable."
>
>
If you want the most stable interface, just use libnuma. It took me less
than a day to re
On Mar 9, 2017, at 8:50 PM, Barry Smith
mailto:bsm...@mcs.anl.gov>> wrote:
On Mar 9, 2017, at 8:29 PM, Zhang, Hong
mailto:hongzh...@anl.gov>> wrote:
On Mar 9, 2017, at 7:38 PM, Barry Smith
mailto:bsm...@mcs.anl.gov>> wrote:
On Mar 9, 2017, at 7:18 PM, Richard Mills
mailto:richardtmi...@g
> On Mar 9, 2017, at 8:02 PM, Richard Mills wrote:
>
> On Thu, Mar 9, 2017 at 5:38 PM, Barry Smith wrote:
>
> > On Mar 9, 2017, at 7:18 PM, Richard Mills wrote:
> >
> > Hi Barry,
> >
> > I like the sound of this, but I think we'd need to be careful about not
> > messing up data alignment if
> On Mar 9, 2017, at 8:29 PM, Zhang, Hong wrote:
>
>
>> On Mar 9, 2017, at 7:38 PM, Barry Smith wrote:
>>
>>
>>> On Mar 9, 2017, at 7:18 PM, Richard Mills wrote:
>>>
>>> Hi Barry,
>>>
>>> I like the sound of this, but I think we'd need to be careful about not
>>> messing up data alignmen
> On Mar 9, 2017, at 7:38 PM, Barry Smith wrote:
>
>
>> On Mar 9, 2017, at 7:18 PM, Richard Mills wrote:
>>
>> Hi Barry,
>>
>> I like the sound of this, but I think we'd need to be careful about not
>> messing up data alignment if we do this. If we want a malloc that is going
>> to let us
On Thu, Mar 9, 2017 at 5:38 PM, Barry Smith wrote:
>
> > On Mar 9, 2017, at 7:18 PM, Richard Mills
> wrote:
> >
> > Hi Barry,
> >
> > I like the sound of this, but I think we'd need to be careful about not
> messing up data alignment if we do this. If we want a malloc that is going
> to let us
> On Mar 9, 2017, at 7:18 PM, Richard Mills wrote:
>
> Hi Barry,
>
> I like the sound of this, but I think we'd need to be careful about not
> messing up data alignment if we do this. If we want a malloc that is going
> to let us put the start of an array on, say, a 64 byte alignment boundar
Hi Barry,
I like the sound of this, but I think we'd need to be careful about not
messing up data alignment if we do this. If we want a malloc that is going
to let us put the start of an array on, say, a 64 byte alignment boundary,
then we need to not mess that up by putting this integer value th
Using different mallocs for different objects/arrays in PETSc is very iffy
because each free() has to match the malloc used for that memory. This is even
true with just -malloc_debug in that certain initialization functions in PETSc
need to use the raw malloc() because we cannot be sure if th
53 matches
Mail list logo
