[prev in list] [next in list] [prev in thread] [next in thread]
List: beowulf
Subject: Re: [Beowulf] Please help test compiler/hardware issue
From: "Peter St. John" <peter.st.john () gmail ! com>
Date: 2007-05-04 14:53:33
Message-ID: e4d4fd070705040753x7c3e0937n4311301ea79e5ccd () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
I don't understand what "allocatable" and "allocate" do. It would seem that
atob writes an integer (assigned by a(i) = i) to an address which had also
been specified by the a(i)=i assignment, and was not necessarily allocated
to a. That would be expected to generate random errors, and since the
example has hardcoded numbers like 8460901, it could write to a range that
**normally** is writeable in user space, but which is not guaranteed to be
by the allocation.
If it were C like this:
int *a;
a = malloc(10);
for(i = 0; i< 10; i++) a[i] = i;
*(a[5]) = 5;
that is, I'm presuming that the contents at the address "5" can be written
with the value 5, but "5" is not necessarily in the address space allocated
by malloc.
I'm thinking this must not be what the subroutine ATOB does, maybe a call by
reference instead of call by value confusion (to me). However, the example
looks like it was written to show up a compiler dependency and not to stress
test a CPU. In fact, it looks like it was written by a malicious C
programmer :-) but I have an alibi.
Peter
On 5/3/07, James Cuff <james_cuff@harvard.edu> wrote:
>
>
> Hi Orion,
>
> I'm thinking you may have bad memory/hardware on one of those nodes
> here mate...
>
> Compiles and runs fine here in 32 bit ubuntu fiesty:
>
> jcuff@harold:~$ uname -a
> Linux harold 2.6.20-15-386 #2 Sun Apr 15 07:34:00 UTC 2007 i686 GNU/
> Linux
>
> jcuff@harold:~$ cat /proc/cpuinfo | grep "model name"
> model name : Intel(R) Pentium(R) 4 CPU 2.53GHz
>
>
> jcuff@harold:~$ gfortran -O3 -o tt test.f90
> jcuff@harold:~$ time ./tt
> ^C
> real 8m11.766s
> user 8m5.862s
> sys 0m4.280s
>
>
> Also your 64 bit static compiled version runs fine even on a rather
> crappy "64 bit" Celeron I have on FC 5:
>
> [jcuff@gw ~]$ cat /proc/cpuinfo | grep "model name"
> model name : Intel(R) Celeron(R) CPU 2.93GHz
>
> [jcuff@gw ~]$ uname -a
> Linux 2.6.20-1.2312.fc5 #1 SMP Tue Apr 10 15:14:58 EDT 2007 x86_64
> x86_64 x86_64 GNU/Linux
>
>
> [jcuff@gw ~]$ time ./testatob
> ^C
> real 5m5.794s
> user 3m38.785s
> sys 0m9.890s
>
>
> Hope this helps.
>
> Best,
>
> j.
>
> --
> James Cuff, D. Phil.
> Director of Research Computing, Life Sciences Division.
> Bauer Laboratory, 7 Divinity Avenue, Cambridge, MA. 02138
> Tel: 617-384-5065 Direct Dial: 617-384-7647
>
>
> On May 3, 2007, at 8:34 PM, <orion@cora.nwra.com> wrote:
>
> > >
> > > Okay, I have a test case for the problem I reported before
> >
> > Statically compiled binary at http://www.cora.nwra.com/~orion/
> > testatob.bz2
> > for those of you without the PGF compiler to try.
> >
> > --
> > Orion Poplawski
> > Technical Manager 303-415-9701 x222
> > NWRA/CoRA Division FAX: 303-415-9702
> > 3380 Mitchell Lane orion@cora.nwra.com
> > Boulder, CO 80301 http://www.cora.nwra.com
> >
> > _______________________________________________
> > Beowulf mailing list, Beowulf@beowulf.org
> > To change your subscription (digest mode or unsubscribe) visit
> > http://www.beowulf.org/mailman/listinfo/beowulf
> >
>
> _______________________________________________
> Beowulf mailing list, Beowulf@beowulf.org
> To change your subscription (digest mode or unsubscribe) visit
> http://www.beowulf.org/mailman/listinfo/beowulf
>
[Attachment #5 (text/html)]
<div>I don't understand what "allocatable" and "allocate" do. \
It would seem that atob writes an integer (assigned by a(i) = i) to an address which \
had also been specified by the a(i)=i assignment, and was not necessarily allocated \
to a. That would be expected to generate random errors, and since the example has \
hardcoded numbers like 8460901, it could write to a range that **normally** is \
writeable in user space, but which is not guaranteed to be by the allocation. </div>
<div> </div>
<div>If it were C like this:</div>
<div> </div>
<div>int *a;</div>
<div>a = malloc(10);</div>
<div>for(i = 0; i< 10; i++) a[i] = i;</div>
<div>*(a[5]) = 5;</div>
<div> </div>
<div>that is, I'm presuming that the contents at the address "5" can be \
written with the value 5, but "5" is not necessarily in the address space \
allocated by malloc.</div> <div> </div>
<div>I'm thinking this must not be what the subroutine ATOB does, maybe a call by \
reference instead of call by value confusion (to me). However, the example looks like \
it was written to show up a compiler dependency and not to stress test a CPU. In \
fact, it looks like it was written by a malicious C programmer :-) but I have an \
alibi. </div>
<div> </div>
<div>Peter</div>
<div><br><br> </div>
<div><span class="gmail_quote">On 5/3/07, <b class="gmail_sendername">James Cuff</b> \
<<a href="mailto:james_cuff@harvard.edu">james_cuff@harvard.edu</a>> \
wrote:</span> <blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px \
0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br>Hi Orion,<br><br>I'm thinking you \
may have bad memory/hardware on one of those nodes<br>here mate... <br><br>Compiles \
and runs fine here in 32 bit ubuntu fiesty:<br><br>jcuff@harold:~$ uname -a<br>Linux \
harold 2.6.20-15-386 #2 Sun Apr 15 07:34:00 UTC 2007 i686 \
GNU/<br>Linux<br><br>jcuff@harold:~$ cat /proc/cpuinfo | grep "model name" \
<br>model name : Intel(R) Pentium(R) 4 CPU \
2.53GHz<br><br><br>jcuff@harold:~$ gfortran -O3 -o tt test.f90<br>jcuff@harold:~$ \
time ./tt<br>^C<br>real 8m11.766s<br>user 8m5.862s<br>sys \
0m4.280s<br><br><br>Also your 64 bit static compiled version runs fine even on a \
rather <br>crappy "64 bit" Celeron I have on FC 5:<br><br>[jcuff@gw ~]$ cat \
/proc/cpuinfo | grep "model name"<br>model \
name : \
Intel(R) Celeron(R) CPU 2.93GHz<br><br>[jcuff@gw ~]$ uname -a <br>Linux \
2.6.20-1.2312.fc5 #1 SMP Tue Apr 10 15:14:58 EDT 2007 x86_64<br>x86_64 x86_64 \
GNU/Linux<br><br><br>[jcuff@gw ~]$ time \
./testatob<br>^C<br>real 5m5.794s<br>user 3m38.785s<br>sys \
0m9.890s<br><br><br>Hope this helps. <br><br>Best,<br><br>j.<br><br>--<br>James Cuff, \
D. Phil.<br>Director of Research Computing, Life Sciences Division.<br>Bauer \
Laboratory, 7 Divinity Avenue, Cambridge, MA. 02138<br>Tel: 617-384-5065 \
Direct Dial: 617-384-7647 <br><br><br>On May 3, 2007, at 8:34 PM, <<a \
href="mailto:orion@cora.nwra.com">orion@cora.nwra.com</a>> wrote:<br><br>> \
><br>> > Okay, I have a test case for the problem I reported \
before<br>><br>> Statically compiled binary at <a \
href="http://www.cora.nwra.com/~orion/">http://www.cora.nwra.com/~orion/</a><br>> \
testatob.bz2<br>> for those of you without the PGF compiler to \
try.<br>><br>> --<br>> Orion Poplawski<br>> Technical \
Manager \
303-415-9701 x222 <br>> NWRA/CoRA \
Division FAX: \
303-415-9702<br>> 3380 Mitchell \
Lane <a \
href="mailto:orion@cora.nwra.com">orion@cora.nwra.com</a><br>> Boulder, CO \
80301 <a \
href="http://www.cora.nwra.com"> http://www.cora.nwra.com</a><br>><br>> \
_______________________________________________<br>> Beowulf mailing list, <a \
href="mailto:Beowulf@beowulf.org">Beowulf@beowulf.org</a><br>> To change your \
subscription (digest mode or unsubscribe) visit <br>> <a \
href="http://www.beowulf.org/mailman/listinfo/beowulf">http://www.beowulf.org/mailman/ \
listinfo/beowulf</a><br>><br><br>_______________________________________________<br>Beowulf \
mailing list, <a href="mailto:Beowulf@beowulf.org"> Beowulf@beowulf.org</a><br>To \
change your subscription (digest mode or unsubscribe) visit <a \
href="http://www.beowulf.org/mailman/listinfo/beowulf">http://www.beowulf.org/mailman/listinfo/beowulf</a><br></blockquote></div>
<br>
_______________________________________________
Beowulf mailing list, Beowulf@beowulf.org
To change your subscription (digest mode or unsubscribe) visit \
http://www.beowulf.org/mailman/listinfo/beowulf
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic