Adrian Jackson's blog
Posted: 5 Sep 2016 | 10:35
06/09/16: As pointed out by my colleague Stephen in the comments after this post, the way to solve most of these issues is to tunnel the key authentication and therefore bypass the need to have private keys anywhere but on my local machine. I'm always learning :)
Password vs key
Having to remember a range of passwords for systems that I don't use regularly is hard.
You can use a password manager, but that only helps if I'm only ever trying to log in from my own laptop. If I have to log in from someone else's machine for any reason then I'd need to know the password.
Posted: 30 Aug 2016 | 12:22
Knights Landing MPI performance
Following on from our recent post on early experiences with KNL performance, we have been looking at MPI performance on Intel's latest many-core processor.
The MPI performance on the first generation of Xeon Phi processor (KNC) was one of the reasons that some of the applications we ported to KNC had poor performance. Figures 1 and 2 show the latency and bandwidth of an MPI ping-pong benchmark running on a single KNC and on a 2x8-core IvyBridge node.
Posted: 29 Jul 2016 | 16:45
Initial experiences on early KNL
Updated 1st August 2016 to add a sentence describing the MPI configurations of the benchmarks run.
Updated 30th August 2016 to add CASTEP performance numbers on Broadwell with some discussion
KNL is a many-core processor, successor to the KNC, that has up to 72 cores, each of which can run 4 threads, and 16 GB of high bandwidth memory stacked directly on to the chip.
Posted: 21 Jun 2016 | 17:13
There's been a lot of discussion about the latest Top500 list, released this week at ISC16. Most of the interest has been in the whopping new Chinese system, Sunway TaihuLight, which has come in at number 1 on the list with a massive 93 PFlop/s rpeak Linpack performance, and 125 PFlop/s rmax theoretical peak performance (3 times bigger than the previous number 1 system).
Whilst this is a very interesting system, and much bigger than is currently planned elsewhere, it's not unknown for very large systems to come in and dominate the list like this. Back in 2002, the Japanese Earth Simulator system became the number 1 machine with an rpeak of ~5x that of the previous number 1 system, and it stayed as the top machine for a number of years.
Posted: 21 Jun 2016 | 07:59
Choice, choice, choice
I'm often asked "What programming language should I learn for scientific computing?". Or I get involved in religious-like discussions about the best programming language for a particular task, or of all time (think Python vs Fortran, Go vs C, etc...). What's my answer?
Just recently I realised that, to me, programming languages are like musical instruments.
Posted: 15 Jun 2016 | 13:35
This week sees our annual collaboration workshop with Tsukuba University, Japan (more details are available here). This is a great chance to get a flavour of the kind of research another HPC centre is undertaking, how they work, and what platforms they are investing in.
The Centre for Computational Sciences (CCS) at Tsukuba is a department very like EPCC, in that it is responsible for high performance and parallel computing at the university, runs and supports large-scale computers for researchers, and undertakes parallel computing research.
Posted: 10 May 2016 | 00:07
Useful software design
Prompted by a recent discussion of a blog post discussing applying commercial development techniques to academic software development, I've been trying to formalise the software design process I'd recommend to academic software developers.
Just the term, software design, puts a lot of people off. It sounds like a long, elaborate process, full of requirements capture and storyboards, but it really doesn't have to be. I think anyone who is writing programs will be doing some form of software design, even if that design is just following the process they've always used, but are just not formalising it. However, formalising your software design could bring important benefits.
Posted: 26 Apr 2016 | 13:07
I had a recent query from some users with a problem with the default version of the Intel Fortran compiler on ARCHER (v220.127.116.11). It was a nice query to get because the users had done all the work already; they'd identified the problem, found a test code that demonstrated it, and told me what the solution would be for them.
Fortunately, the solution was easy, this bug has been fixed in a newer version of the compiler (18.104.22.168), which is installed and available on ARCHER, but just isn't the default (we tend to keep the default version slightly behind the latest release but as new as possible), so they simply have to swap the compiler modules then their code can compile and run correctly.
Posted: 19 Apr 2016 | 23:14
Anyone taking more than a passing interest in HPC hardware recently will have noticed that there are a number of reasonably significant trends coming to fruition in 2016. Of particular interest to me are on-package memory, integrated functionality, and new processor competitors.
On-package memory, memory that is directly attached to the processor, has been promised for a number of years now. The first product of this type I can remember was Micron's Hybrid Memory Cube around 2010/2011, but it's taken a few years for the hardware to become mature enough (or technically feasible and cheap enough) to make it to mass market chips. We now have it in the form of MCDRAM for Intel's upcoming Xeon Phi processor (Knights Landing), and as HBM2 on Nvidia's recently announced P100 GPU.
Posted: 14 Apr 2016 | 21:02
Writing programs assuming that they will be incorrect
I was thinking about development methodologies and software design principles recently and have decided that one of the things I've learned is that it is essential to write programs with the assumption they are going to fail.
I don't think that any of us like to think that the programs we write or maintain will go wrong, or have mistakes/problems in them. However, as I've discussed previously, it is very hard to develop code without making mistakes: coding mistakes, algorithmic errors, mistaken assumptions, etc...