#9946: Parallel build of Singular 3-1-1-4-package fails in other cases
------------------------+---------------------------------------------------
Reporter: mpatel | Owner: tbd
Type: defect | Status: needs_review
Priority: blocker | Milestone: sage-4.6
Component: packages | Keywords:
Author: | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
------------------------+---------------------------------------------------
Comment(by drkirkby):
Replying to [comment:21 leif]:
> Replying to [comment:20 drkirkby]:
> > [...] when I was testing http://atlc.sourceforge.net/ for portability,
I found on a Cray X MP running Unicos that:
> >
> > * sizeof(long)=8
> > * sizeof(int)=8
> > * sizeof(short)=8
> >
> > The latter was a real pain to me.
>
> IIRC the C standard requires
> {{{sizeof(short) <= sizeof(int) <= sizeof(long)}}}
> but also
> {{{sizeof(short) < sizeof(long)}}}
> so Cray would violate the latter.
I was not aware of {{{sizeof(short) < sizeof(long)}}} was part of the C
standard. I don't have a copy of the standard. If anyone does, please
email me one!
I guess the $15,000,000 [http://en.wikipedia.org/wiki/Cray_X-MP Cray X-MP]
introduced in 1982 pre-dated the latest C99 standard by a few years.
If you want to try a Cray, go to http://www.cray-
cyber.org/access/index.php and get an account.
At the time I used the X-MP, (at least I think it was an X-MP, but I see
they only have a Y-MP now), it was '''painfully''' slow to do anything.
You really needed to use the vector processors properly to get the
performance, and I had no intension of doing that. But I reckon my code is
quite portable, as it must be one of the only programs to have been run on
a supercomputer and a Sony Playstation games console! I think Sage would
need a good few patches to ever be that portable.
> > I don't know how this would fit in with Nathann's:
> >
> > ''... though my way of seeing it would really be to avoid spending
hours wondering "how it could fail" when it seems so easy to just test it
and write patches when errors are reported. ''
> >
> >
> > Somehow I doubt it would fit in too well.
> >
> > If I don't get any problems, and there are are problems found by
others, it would make me wonder how else one could try to find such
problems. This was my best stab at an answer, but perhaps it is not ideal.
>
> You mean I should upload a reviewer patch? ;-)
>
> > I think really there should be a delay on the linker too, which I have
not implemented. I've only done this on the compilers gcc, g++ and
gfortran.
>
> The linker isn't often used directly, and {{{libtool}}} calls {{{gcc}}}
for linking:
> {{{
> #!sh
> ld -shared -o p_Procs_FieldIndep.so p_Procs_Lib_FieldIndep.dl_o
> ld -shared -o p_Procs_FieldZp.so p_Procs_Lib_FieldZp.dl_o
> ld -shared -o p_Procs_FieldQ.so p_Procs_Lib_FieldQ.dl_o
> ld -shared -o p_Procs_FieldGeneral.so p_Procs_Lib_FieldGeneral.dl_o
> ld -shared -o dbmsr.so ndbm.dl_o sing_dbm.dl_o -lc_nonshared
> }}}
> (That's all.)
OK. So hopefully random delays on the compiler will work.
Things are looking ok so far. I've built this
* 29 times with a mean delay of 500 ms (maximum 1 second)
* 44 times with a mean delay of 50 ms (maximum 100 ms)
* 46 times with a mean delay of 5 ms (maximum 10 ms)
* 46 times with a mean delay of 500 us (maximum 1 ms)
* 46 times with a mean delay of 50 us. (maximum 100 us)
If by around 0830 GMT tomorrow, this has not failed, I'll give it a
positive review. By that time it should have built nearly 100 times with
the longest delay and certainly 100 times with the shorter delays.
Dave
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9946#comment:22>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
