Re: Total vs per-cpu memory
Hi again > On Fri, Feb 01, 2008 at 04:10:25PM +0100, Gudjon I. Gudjonsson wrote: >> Since you are discussing this. I spent yesterday on trying to debug >> ngspice on amd64 with gdb and valgrind. It segfaults on amd64 but not on >> i386. Can you point out some good documents on where to put those checks >> you mention? > > The main thing to watch out for it people using int's as pointers. > pointers should always be void * or longs. If you are interested there is a Debian package on my server: deb http://195.198.146.229/debian/ amd64/ deb-src http://195.198.146.229/debian/ source/ You just need to start the program and it will segfault :) The debugging symbols are stripped even if it is run with the nostrip option but they exist in src/ngspice. Thanks Gudjon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Total vs per-cpu memory
On Fri, Feb 01, 2008 at 04:10:25PM +0100, Gudjon I. Gudjonsson wrote: > Since you are discussing this. I spent yesterday on trying to debug > ngspice on amd64 with gdb and valgrind. It segfaults on amd64 but not on > i386. Can you point out some good documents on where to put those checks > you mention? The main thing to watch out for it people using int's as pointers. pointers should always be void * or longs. Do you have an example of how to make it segfault? >Unfortunately often I don't know when a data structure can be freed. When you know you won't try to access it again. Also setting the pointer to NULL after freeing it and then checking that a pointer is not NULL before trying to access it (and if it is null when you don't think it should be, spit out an error message). -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Total vs per-cpu memory
Hi >> absolutely true. But then, who is so diligent to always do so, >> especially >> when developing your own code for scientific computation? I've written >> some, >> and only when it was for "public consumption" I cared to put all the >> checks >> in all the places... :P > > Ehm, anyone that wants to avoid embareshing things like segfaults in > their programs. It can save a lot of headaches debuging the problem > later to just do things right to begin with. Since you are discussing this. I spent yesterday on trying to debug ngspice on amd64 with gdb and valgrind. It segfaults on amd64 but not on i386. Can you point out some good documents on where to put those checks you mention? Unfortunately often I don't know when a data structure can be freed. Thanks Gudjon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Total vs per-cpu memory
On Fri, Feb 01, 2008 at 02:01:35PM +0100, Giacomo Mulas wrote: > absolutely true. But then, who is so diligent to always do so, especially > when developing your own code for scientific computation? I've written some, > and only when it was for "public consumption" I cared to put all the checks > in all the places... :P Ehm, anyone that wants to avoid embareshing things like segfaults in their programs. It can save a lot of headaches debuging the problem later to just do things right to begin with. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Total vs per-cpu memory
On Thu, 31 Jan 2008, Lennart Sorensen wrote: Insufficient ram does not EVER cause a segmentation fault. Only buggy code causes segmentation faults. If a bad programmer simply calls malloc and doesn't check that it succeeded before using it, then you get a segmentation fault, but only because the programmer didn't write proper code. absolutely true. But then, who is so diligent to always do so, especially when developing your own code for scientific computation? I've written some, and only when it was for "public consumption" I cared to put all the checks in all the places... :P Ciao Giacomo -- _ Giacomo Mulas <[EMAIL PROTECTED]> _ OSSERVATORIO ASTRONOMICO DI CAGLIARI Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA) Tel. (OAC): +39 070 71180 248 Fax : +39 070 71180 222 Tel. (UNICA): +39 070 675 4916 _ "When the storms are raging around you, stay right where you are" (Freddy Mercury) _ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Total vs per-cpu memory
On Thu, 2008-01-31 at 07:39 -0800, Francesco Pietra wrote: > This question is related to problems in running a docking computation. With > big > cases, RAM proves insufficient, resulting in immediate "segmentation fault", > so > that "top" cannot inform. Though, from the code it is clear that memory is > insufficient to rotate the object in a non-parallelized part of the program. > Smaller objects do not give problems. > > My question is: with Tyan S2895 Thunder K8WE, two dual opterons and 1GB RAM > per > cpu (amd64 etch), are the 16GB available to the single cpu involved in the > computation, or are 4GB available? Where did 16GiB come from? I count 2x2 in the above scenario -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Total vs per-cpu memory
On Thu, 2008-01-31 at 09:12 -0800, Francesco Pietra wrote: > Hi Len: > I agree. However, these are no standardized codes. Actually, it is a code in > development that is faced with extreme situations that could not have been in > the mind of the developer. Docking a large molecule onto a protein without > bias > is a challenging task, that the program accomplices nicely up to a certain > size > of the ligand. I am pushing the program beyond the limits for which it was > devised. That "pushing" in order to tell where the program needs to be > revised. > The developer is not putting together known routines, he is inventing the way > to come out. > > That said, you are certainly able to answer my question about how RAM is used > by a single cpu in my Tyan (all 8 sets of memory occupied) when the other cpus > are dormant. If not, the only way I can invent is to look at top -i when the > ligand is large but not so large to induce segmentation fault. Every memory slot on an Opteron system is "owned" by a particular CPU socket. If there is no CPU there, then the memory won't work. If there is a CPU there, but a different CPU requires access to the memory, the one CPU can "ask" another CPU for access to a block of memory -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Total vs per-cpu memory
On Thu, Jan 31, 2008 at 09:12:52AM -0800, Francesco Pietra wrote: > Hi Len: > I agree. However, these are no standardized codes. Actually, it is a code in > development that is faced with extreme situations that could not have been in > the mind of the developer. Docking a large molecule onto a protein without > bias > is a challenging task, that the program accomplices nicely up to a certain > size > of the ligand. I am pushing the program beyond the limits for which it was > devised. That "pushing" in order to tell where the program needs to be > revised. > The developer is not putting together known routines, he is inventing the way > to come out. Any time you see segmentation fault, the programmer made a mistake. The situation is completely irrelevant. If you don't check return codes of system calls then you made a mistake. Simple as that. > That said, you are certainly able to answer my question about how RAM is used > by a single cpu in my Tyan (all 8 sets of memory occupied) when the other cpus > are dormant. If not, the only way I can invent is to look at top -i when the > ligand is large but not so large to induce segmentation fault. If it is a single system, then all ram is available in one big pool. If it is an opteron then some ram will be faster for some CPUs (that being whatever ram is connected directly is slightly faster than ram connected to another CPU, but only slightly). If you run 32bit programs, then you can have at most 3GB of ram as far as I recall with linux. Certainly no more than 4GB. With a 64bit programs you can allocate any amount of ram, as long as the system still has any left and assuming there aren't any user limits applied that could prevent you from allocating anymore. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Total vs per-cpu memory
Hi Len: I agree. However, these are no standardized codes. Actually, it is a code in development that is faced with extreme situations that could not have been in the mind of the developer. Docking a large molecule onto a protein without bias is a challenging task, that the program accomplices nicely up to a certain size of the ligand. I am pushing the program beyond the limits for which it was devised. That "pushing" in order to tell where the program needs to be revised. The developer is not putting together known routines, he is inventing the way to come out. That said, you are certainly able to answer my question about how RAM is used by a single cpu in my Tyan (all 8 sets of memory occupied) when the other cpus are dormant. If not, the only way I can invent is to look at top -i when the ligand is large but not so large to induce segmentation fault. Thanks francesco --- Lennart Sorensen <[EMAIL PROTECTED]> wrote: > On Thu, Jan 31, 2008 at 07:39:43AM -0800, Francesco Pietra wrote: > > This question is related to problems in running a docking computation. With > big > > cases, RAM proves insufficient, resulting in immediate "segmentation > fault", so > > that "top" cannot inform. Though, from the code it is clear that memory is > > insufficient to rotate the object in a non-parallelized part of the > program. > > Smaller objects do not give problems. > > Insufficient ram does not EVER cause a segmentation fault. Only buggy > code causes segmentation faults. > > If a bad programmer simply calls malloc and doesn't check that it > succeeded before using it, then you get a segmentation fault, but only > because the programmer didn't write proper code. > > -- > Len Sorensen > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Total vs per-cpu memory
On Thu, Jan 31, 2008 at 07:39:43AM -0800, Francesco Pietra wrote: > This question is related to problems in running a docking computation. With > big > cases, RAM proves insufficient, resulting in immediate "segmentation fault", > so > that "top" cannot inform. Though, from the code it is clear that memory is > insufficient to rotate the object in a non-parallelized part of the program. > Smaller objects do not give problems. Insufficient ram does not EVER cause a segmentation fault. Only buggy code causes segmentation faults. If a bad programmer simply calls malloc and doesn't check that it succeeded before using it, then you get a segmentation fault, but only because the programmer didn't write proper code. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
