Notice to uses of t2.math
Dr. David Kirkby
/scratch. The old contents of /scratch and now just on a bigger drive.
Filesystem size used avail capacity Mounted on
scratch2 134G 15G 119G 12% /scratch
I've currently enabled compression on the ZFS file system. It needs further
testing to see if this is a good idea or not. Clearly it saves disk space, but
does uses CPU time to perform the compression.
I was chatting to a Oracle (former Sun) employee about the disk compression last
night. He said in some cases it can actaully be faster with compression on, as
you are writing less data to the disk, so there's less disk I/O.
Apparently the earlier versions of the ZFS file system did not support
multi-threaded compression, whereas the newer versions do. I don't know yet
whether t2 will use multiple threads for the compression or not. Anyway,
compression can be turned on/off very quickly.
There is a shortage of physical memory in t2 now, which is starting to show as
people build packages in parallel. But as you all know, using t2 without
building things in parallel takes forever! I'll try asking William to put in
another 32 GB.
Messages like
Aug 14 23:45:55 t2 tmpfs: [ID 518458 kern.warning] WARNING: /tmp: File system
full, swap space limit exceeded
Aug 15 13:10:10 t2 tmpfs: [ID 518458 kern.warning] WARNING: /tmp: File system
full, swap space limit exceeded
basically mean t2 is out of RAM.
Dave
John H Palmieri
wrote:
> /scratch. The old contents of /scratch and now just on a bigger drive.
>
> Filesystem size used avail capacity Mounted on
> scratch2 134G 15G 119G 12% /scratch
doctest failure from #9760. Does this mean that the motd can be
changed?
--
John
Dr. David Kirkby
I very much doubt it affect ATLAS. I doubt that was a lack of disk space that
caused that. It could however be a lack of memory.
There is a lack of memory on 't2'. It is 32 GB - one quarter of that on
sage.math or boxen.math.
There's currently no swap space at all on t2 - that was because there was
just insufficient disk space to "waste" any on swap. That is no longer
the case, but there's not really much swap that can be added - really we
need another 32 GB of RAM.
I've changed the motd, so feel free to use the extra scratch space.
I'm not 100% sure, but I believe all the numerical noise issues have patches and
have positive review. In which case, that leaves only SYMPOW in the way of Sage
passing all doctests on both OpenSolaris and Solaris 86.
I can't quite make my mind what to do about the SYMPOW issue. There are two
possible approaches.
1) Try to fix what I believe is very bad code, and hope for the best. It seems a
bit of a waste of time given the code is rarely used and William wants to get a
student to write something more suitable.
In any case, the code is so difficult to read, even a mathematician would be
hard pressed to know what it's supposed to be doing. I've got little hope myself.
2) We ignore SYMPOW. That means there's will be no "complete" 32-bit Solaris x86
or OpenSolaris port in the near future. Instead the time saved can be devoted to
a 64-bit port, which is probably a lot more useful.
I'd be interested in the views of any others - especially anyone who feels they
might be able to debug the code!
Dave
But I should double-check those numerical noise problems are all covered. I
think they are, but I'm not 100% sure.
Dave
John H Palmieri
> On 08/19/10 07:04 PM, John H Palmieri wrote:
>
> > On Aug 19, 8:39 am, "Dr. David Kirkby"<david.kir...@onetel.net>
> > wrote:
> >> A new 147 GB disk was recently purchased for t2, which I've installed as
> >> /scratch. The old contents of /scratch and now just on a bigger drive.
>
> >> Filesystem size used avail capacity Mounted on
> >> scratch2 134G 15G 119G 12% /scratch
>
> > Great! I wonder if building ATLAS on it will affect the matrix2.pyx
> > doctest failure from #9760. Does this mean that the motd can be
> > changed?
>
> > --
> > John
>
> I very much doubt it affect ATLAS. I doubt that was a lack of disk space that
> caused that. It could however be a lack of memory.
disk (/home). Would that have no effect on ATLAS? I guess not...
> I can't quite make my mind what to do about the SYMPOW issue. There are two
> possible approaches.
>
> 1) Try to fix what I believe is very bad code, and hope for the best. It seems a
> bit of a waste of time given the code is rarely used and William wants to get a
> student to write something more suitable.
people view its computations as being very useful, and would miss its
inclusion in Sage. I also thought that someone in the thread on sage-
devel volunteered to contact the author. I don't know if anything
will come of it, but it wouldn't hurt to try.
> In any case, the code is so difficult to read, even a mathematician would be
> hard pressed to know what it's supposed to be doing. I've got little hope myself.
>
> 2) We ignore SYMPOW. That means there's will be no "complete" 32-bit Solaris x86
> or OpenSolaris port in the near future. Instead the time saved can be devoted to
> a 64-bit port, which is probably a lot more useful.
with option 2 being the standby situation: we just won't have a
completely functioning port to those platforms. If the Sympow
problems also impede the Windows version, we might see more activity.
If Mike Hansen could be persuaded to look at it, he might be able to
deal with it all by himself :)
By the way, I've never really used OpenSolaris, but I recently saw an
article on the web predicting its demise, in the wake of Oracle's
takeover of Sun. If this is accurate, I'm not sure how much work
should be put into OpenSolaris. (I said "I'm not sure how much work",
not "we clearly shouldn't spend any effort on it" -- I don't know the
answer at all.)
> I'd be interested in the views of any others - especially anyone who feels they
> might be able to debug the code!
>
> Dave
>
> But I should double-check those numerical noise problems are all covered. I
> think they are, but I'm not 100% sure.
easily.
--
John
Dr. David Kirkby
> I wasn't suggesting lack of disk space, but rather building on a slow
> disk (/home). Would that have no effect on ATLAS? I guess not...
I would not of thought so, but it is not impossible that slow disk acess would
be the cause. There's also the very real possibility of data corruption - not
just slow.
>> I can't quite make my mind what to do about the SYMPOW issue. There are two
>> possible approaches.
>>
>> 1) Try to fix what I believe is very bad code, and hope for the best. It seems a
>> bit of a waste of time given the code is rarely used and William wants to get a
>> student to write something more suitable.
>
> I don't know about "rarely used". At least, it seems as though some
> people view its computations as being very useful, and would miss its
> inclusion in Sage.
Yes, John and William.
> I also thought that someone in the thread on sage-
> devel volunteered to contact the author. I don't know if anything
> will come of it, but it wouldn't hurt to try.
Yes, it was Bill Hart I think.
>> In any case, the code is so difficult to read, even a mathematician would be
>> hard pressed to know what it's supposed to be doing. I've got little hope myself.
>>
>> 2) We ignore SYMPOW. That means there's will be no "complete" 32-bit Solaris x86
>> or OpenSolaris port in the near future. Instead the time saved can be devoted to
>> a 64-bit port, which is probably a lot more useful.
>
> I think that option 1, with a low priority, is the most likely event,
> with option 2 being the standby situation: we just won't have a
> completely functioning port to those platforms. If the Sympow
> problems also impede the Windows version, we might see more activity.
That was what I was hoping.
> If Mike Hansen could be persuaded to look at it, he might be able to
> deal with it all by himself :)
The Cygwin port seems to have stagnated somewhat.
http://groups.google.co.uk/group/sage-support/msg/2e61688a9643baeb
I do not actually know if there is anyone currently working on it. I've sensed a
bit of frustration from William on this matter. William set a target date of
31st August for Sage 5.0, which will have Cywgin support
http://groups.google.com/group/sage-devel/msg/d26e41f66ba6a8bd?hl=en
but that seems extremely unlikely to be met.
There is now some activity on sage-windows by people who think a native Windows
port is the answer - not Cygwin. Personally I think they grossly underestimate
the amount of work for a true native port. But there's far more discussion on
that, then anything related to Cygwin.
> By the way, I've never really used OpenSolaris, but I recently saw an
> article on the web predicting its demise, in the wake of Oracle's
> takeover of Sun. If this is accurate, I'm not sure how much work
> should be put into OpenSolaris. (I said "I'm not sure how much work",
> not "we clearly shouldn't spend any effort on it" -- I don't know the
> answer at all.)
There's been no official information on this. There's a widely leaked "internal
memo" which suggests OpenSolaris will not be updated, but instead called Solaris
11 Express. The exact conditions of the release of the source code are not
entirely clear at this minute.
But Oracle are still funding the OpenSolaris user groups - I was at one in
London last night.
I think every time a problem has been noticed on OpenSolaris, its seen on
Solaris 10 and visa versa. So I think there's going to be no real porting effort
there.
Basically OpenSolaris / Solaris 11 Express are aimed to put more leading edge
technology into circulation, before it appears in the very stable Solaris
release. In other words, things get very well tested before they get into Solaris.
It's fairly obvious that things are not going to be radically different between
these different Solaris releases. So I personally don't see any big problem
there. If its replaced by Solaris 11 Express, then let's support that instead.
>> I'd be interested in the views of any others - especially anyone who feels they
>> might be able to debug the code!
>>
>> Dave
>>
>> But I should double-check those numerical noise problems are all covered. I
>> think they are, but I'm not 100% sure.
>
> I think so too. If they get merged into 4.5.3, we can test very
> easily.
Yes, all accept the asinh(1.0) -> asinh(2.0) will be merged I think.
Merging that change (#9693) could *not* cause a build of Sage to fail on any
platform, but it could cause a doctest failure, as numerical noise might show up
on one platform or another.
dave