[sage-devel] Re: Should already built static ATLAS libraries get discarded?

Sorry, I was replying to the other sentence: I'm saying that if you compile ATLAS using most sandy / ivy bridge core i7 then the build system will use pre-tuned values that eliminate the need for most of the search, resulting in about 10 mins of build time. -- You received this message becaus

[sage-devel] Re: Should already built static ATLAS libraries get discarded?

Volker Braun wrote: On Saturday, June 8, 2013 6:31:40 PM UTC+1, leif wrote: ... which isn't tuned for the specific machine. au contraire, full tuned. Of course using some pre-tuned values, for which you need a recent enough Core i7. So you're saying they're shipping ATLAS libraries which

Re: [sage-devel] Re: [Debian] Docbuilding gets stuck

Le 08/06/2013 20:16, Jean-Pierre Flori a écrit : On Saturday, June 8, 2013 7:59:35 PM UTC+2, Snark wrote: Le 08/06/2013 19:26, Jean-Pierre Flori a ďż˝crit : > So you're saying that http://bugs.python.org/issue9400 does not change > anything

Re: [sage-devel] Re: [Debian] Docbuilding gets stuck

On Saturday, June 8, 2013 7:59:35 PM UTC+2, Snark wrote: > > Le 08/06/2013 19:26, Jean-Pierre Flori a �crit : > > So you're saying that http://bugs.python.org/issue9400 does not change > > anything (in fact I'm not even sure its related anymore). > > I'm saying I have no clue what the proble

Re: [sage-devel] Re: [Debian] Docbuilding gets stuck

Le 08/06/2013 19:26, Jean-Pierre Flori a écrit : So you're saying that http://bugs.python.org/issue9400 does not change anything (in fact I'm not even sure its related anymore). I'm saying I have no clue what the problem is, and that I'm not sure it's related to that python issue... I'm like

[sage-devel] Re: Should already built static ATLAS libraries get discarded?

On Saturday, June 8, 2013 6:31:40 PM UTC+1, leif wrote: > ... which isn't tuned for the specific machine. > au contraire, full tuned. Of course using some pre-tuned values, for which you need a recent enough Core i7. XD Incidentally, upstream's tools / scripts to compare different > implemen

[sage-devel] Re: Should already built static ATLAS libraries get discarded?

Volker Braun wrote: Ok, maybe if you have an old computer that doesn't recompile ATLAS in 10 mins... But honestly, if you can't wait then just use your distribution's ATLAS. ... which isn't tuned for the specific machine. And tuning doesn't only take ages on some old, but also some newer CPUs.

[sage-devel] Re: [Debian] Docbuilding gets stuck

So you're saying that http://bugs.python.org/issue9400 does not change anything (in fact I'm not even sure its related anymore). On Thursday, June 6, 2013 8:24:09 PM UTC+2, Snark wrote: > > Hi, > > I have a little more data on the issue, which was obtained by adding > print statements here and

[sage-devel] Re: Should already built static ATLAS libraries get discarded?

Ok, maybe if you have an old computer that doesn't recompile ATLAS in 10 mins... But honestly, if you can't wait then just use your distribution's ATLAS. Being able to save / reuse shared libraries would be really nice to benchmark and compare different implementations. And there we have to mak

[sage-devel] Re: Should already built static ATLAS libraries get discarded?

Volker Braun wrote: On Saturday, June 8, 2013 5:23:57 PM UTC+1, leif wrote: Btw., there's still not even a script to save the once built [shared] ATLAS libraries for use by another Sage installation. And such a script would be totally pointless if there were static libraries floating a

[sage-devel] Re: Static libraries considered harmful

On Saturday, June 8, 2013 6:35:49 PM UTC+2, Volker Braun wrote: > > On Saturday, June 8, 2013 5:14:30 PM UTC+1, Jean-Pierre Flori wrote: > >> The way we use libtool to produce shared libraries of ATLAS is not >> portable. >> > > I agree that this is ugly as sin. At one point we will have to swit

[sage-devel] Re: Static libraries considered harmful

On Saturday, June 8, 2013 5:23:57 PM UTC+1, leif wrote: > Btw., there's still not even a script to save the once built [shared] > ATLAS libraries for use by another Sage installation. > And such a script would be totally pointless if there were static libraries floating about. -- You receive

[sage-devel] Re: Static libraries considered harmful

On Saturday, June 8, 2013 5:14:30 PM UTC+1, Jean-Pierre Flori wrote: > The way we use libtool to produce shared libraries of ATLAS is not > portable. > I agree that this is ugly as sin. At one point we will have to switch Sage to the new-style shared libraries that upstream introduced, which pa

[sage-devel] Re: Static libraries considered harmful

Volker Braun wrote: It was suggested on http://trac.sagemath.org/14699 that we rehash the old arguments why static libraries have no place in a modular software system. So here we go: * No easy way to tell which static library (much less its version) is used by a binary * Space (both disk a

[sage-devel] Re: Static libraries considered harmful

On Saturday, June 8, 2013 5:33:43 PM UTC+2, Volker Braun wrote: > > There is a speed penalty for calling position-independent code (PIC). For > a function that does nothing, it is in the 15% range. In real-world > applications it is more in the < 3% range since library functions tend to > perf

[sage-devel] Re: Static libraries considered harmful

On Saturday, June 8, 2013 5:14:03 PM UTC+2, Volker Braun wrote: > > It was suggested on http://trac.sagemath.org/14699 that we rehash the old > arguments why static libraries have no place in a modular software system. > So here we go: > * No easy way to tell which static library (much less i

[sage-devel] Re: Static libraries considered harmful

There is a speed penalty for calling position-independent code (PIC). For a function that does nothing, it is in the 15% range. In real-world applications it is more in the < 3% range since library functions tend to perform some computational task. If you really need that, you have to compile t

[sage-devel] Re: Static libraries considered harmful

On Saturday, June 8, 2013 5:14:03 PM UTC+2, Volker Braun wrote: > > It was suggested on http://trac.sagemath.org/14699 that we rehash the old > arguments why static libraries have no place in a modular software system. > So here we go: > * No easy way to tell which static library (much less i

[sage-devel] Static libraries considered harmful

It was suggested on http://trac.sagemath.org/14699 that we rehash the old arguments why static libraries have no place in a modular software system. So here we go: * No easy way to tell which static library (much less its version) is used by a binary * Space (both disk and memory) bloat, cod

[sage-devel] A debugging tool

I have writen a small pyqt program to help me debug during sage development (and work). It is meant to be used together with the kate editor and its embedded konsole (although it can be probably be adapted to other developping environments that support a dbus interface). What it does is to parse t

[sage-devel] Re: Using ssh for port-forwarding

mmarco wrote: I tried to do that, and it gives some problems. I don't know why, but it seems that if you launch maple through ssh, you don't get the prompt > in the same way that you get it when you do it locally: it shows only after you press intro. Probably some issue with the TERM setting.

Re: [sage-devel] Re: New Trac Server

On Sat, Jun 8, 2013 at 8:47 AM, R. Andrew Ohana wrote: > Other than that, I think the trac instance is ready. what about the integration with the sagemath wiki? how have you solved this? (but we should move that discussion to sagemath-admin …) H -- You received this message because you are sub

[sage-devel] Re: Using ssh for port-forwarding

I tried to do that, and it gives some problems. I don't know why, but it seems that if you launch maple through ssh, you don't get the prompt > in the same way that you get it when you do it locally: it shows only after you press intro. This makes the pexpect interface fail. On 7 jun, 16:41, leif

[sage-devel] Re: A file-based Cc in Trac

Nathann Cohen wrote: Hellooo !!! > Well, with git, if you kept a local mirror of trac's repo, you could run > > git log --all ^master -- path/to/file > > to get a list of all commits on trac (not necessarily on a ticket, maybe > in the combinat queue or something) that

Re: [sage-devel] Re: A file-based Cc in Trac

Hellooo !!! > Well, with git, if you kept a local mirror of trac's repo, you could run > > git log --all ^master -- path/to/file > > to get a list of all commits on trac (not necessarily on a ticket, maybe > in the combinat queue or something) that touch the file but haven't ye