gnufx

132 ms·

1441.
by gnufx 11y ago
[I assume, but don't know, that GEC 4000 was influenced by Brinch Hansen's RC 4000, but all I remember about the then-ancient RC 4000 at the Niels Bohr Institute was that it seemed pretty primitive and the systems language was Alg
1442.
by gnufx 11y ago
I recall that the AT&T/BSD lawsuit was relevant then, especially for Linux as an alternative at the right time. A microkernel design seemed sane from experience in the UK. I don't know if it was technically a microkernel, but
1443.
by gnufx 11y ago
darcs.reviewed$ darcs log --match 'author florent\.becker' --count 200 See also their FAQ.
1444.
by gnufx 11y ago
It's been practical enough for me for a repo of this size for several years: $ darcs get http://arc.liv.ac.uk/repos/darcs/sge &>/dev/null $ cd sge $ darcs log --count 4851 $ darcs s
1445.
by gnufx 11y ago
> For those not familiar with the DEC Alpha, it always ran what was basically a hypervisor/microkernel in firmware (called PAL code). Gosh, I never realized, as a former Keeper of Alphas for scientific work, previously dependent on
1446.
by gnufx 11y ago
Threadspotter (paratools.com) and maqao.org might be of interest, at least for x86_64 GNU/Linux but I wouldn't know about C++ specifics. [TAU is doubtless a good bet, but for what it's worth for general interest, the other co
1447.
by gnufx 11y ago
The Fortran (not FORTRAN) standard current when Dijkstra wrote that allowed arbitrary lower bounds in array declarations, and an array could be equivalenced to one with different bounds. The language doesn't impose the choice.
1448.
by gnufx 12y ago
I thought it was regression which was at issue here. I'm not convinced cache is so different from all the other aspects of performance we have to deal with in HPC systems (insofar as they're isolated), but no matter. At least the
1449.
by gnufx 12y ago
> You do something that blows away your cache, it'll show up as slowdowns elsewhere in the program. Presumably that will show up as additional cache misses at those points in the profile, as suggested, assuming the profiler can coun
1450.
by gnufx 12y ago
> I love the gauntlet-throwing fire in this statement, and I only wish that it was practical to arrange for a showdown on this to actually happen. Yes, but it's already available in a simpler case, as eluded to above and in discussi
1451.
by gnufx 12y ago
"Considered" maybe, but not measured in practice. Of course you need equivalent optimizations to generate similar code -- Intel even defaults to incorrect optimizations. GCC is also substantially more reliable in my experience w
1452.
by gnufx 12y ago
Which compiler is this which can, for instance, take Netlib LAPACK and run serial Linpack as fast as OpenBLAS on recent x86_64? (Other common hotspots are available.) Enquiring HPC minds want to know.
1453.
by gnufx 12y ago
I'm not sure what "full fat" means, but compared with current gfortran in my experience, ifort is incorrect by default, surprisingly unreliable, and typically generates similar speed code at the 10% level. My all-free softwa
1454.
by gnufx 12y ago
Yes to the basic point, but note that (specifically) if you use BLAS in Fortran, you're typically losing a factor of several in speed, I'm sorry to say. Competitive serial numerical kernels typically still end up needing assemble
1455.
by gnufx 12y ago
A distressing number of runs on our HPC system simply aren't reproducible twice in a row anyway. They get repeated until, or in the hope that, they don't deadlock or segv, not that users typically believe in deadlock. They aren&#
1456.
by gnufx 12y ago
Apart from the general system management advantages of dynamic libraries, they provide an important extensibility/customization mechanism (e.g. https://www.gnu.org/software/emacs/emacs-paper.html for an early
1457.
by gnufx 12y ago
It still seems a good first guess for Fortran code, at least, e.g. worth ~10% compiling reference BLAS and the double precision linpack benchmark with gfortran on Sandybridge.
1458.
by gnufx 12y ago
http://dl.acm.org/citation.cfm?doid=365230.365257 and gratis copies elsewhere; required reading since 1966. Of course "off-side" is a football term, somewhat significant in England later that year. However, Pytho
1459.
by gnufx 12y ago
"Dynamically loading libraries is a big deal, and it's closer than ever." Sigh. Dynamically loaded C extensions were working long ago < https://lists.gnu.org/archive/html/gnu-emacs-sources