rpep

* Universities are teaching Python more than ever. When I started my undergrad in Physics everyone took C++, by the time I graduated it was all Python.

* Academia as a career track is not stable so people want to write code in something that they might have a hope of getting a job in afterwards. C/C++ are much more applicable in the wider world so anyone with one eye on the exit is likely to prefer one of those…

* Fortran itself is fine and even improving with fpm and the ecosystem changes happening, but the big Fortran scientific code bases are not much fun to work on.

* There’s no performance benefit to sticking with Fortran. You can make code fast in any language. The main argument that Fortran is faster than C/C++ is to do with aliasing which anyone writing performance critical code will know how to deal with anyway. Performance portability codes like Kokkos that let you run on OpenMP/MPI/CUDA but write code once are pretty much all C++ too.

* A few years ago, CUDA could only be used in Fortran with the PGI compiler which was commercial. This made it less attractive vs C/C++. This has improved now but it was a major factor for a few years. Even now I think they’re not at feature parity although it’s been a long time since I looked.

They definitely do, but I’d usually suggest that if you find this an issue then perhaps the function you’re exposing from the compiled language should be higher level, with more work done in the compiled code to avoid the overhead of returning control back to the interpreted language.

If you’ve got a large project that’s been going for a while, squashing migrations helps too. It can be a bit tricky to do this though.

When compiling C/C++, with some compilers you are able to specify multiple architectures and provide a fat binary. It's been a few years now since I've worked on this sort of thing, but the Intel compiler for e.g. used to allow you to do something like this at the compilation stage

-march=avx,avx2,avx512

And at runtime, your processor would use the most recent instruction set. In practice, you don't always want to do this, since you produce fat binaries - i.e. every function call that's got vector instructions will have multiple versions, and the file size goes up, library is slower to load, etc... I can't remember if there was an overhead too to each function call. So instead of doing this, what is also common is to compile N versions of the library (one per instruction set), and then load the appropriate version at runtime. This you can do with any compiler, and is indeed what Intel do themselves with the MKL library - if you look into the package for it, you can see that you end up with multiple shared libraries, each with a suffix saying which instruction set it supports (e.g. libmkl_avx.so, libmkl_avx2.so, libmkl_avx512.so). I'm not familiar with simdjson so not sure which approach it takes.

Interestingly, if you use ARM processors, the SVE instruction set is designed so that you don't need to re-compile if a new processor family comes along with longer vector processing units.

I’ve been following a number of open tickets and certain things I consider pretty basic features aren’t possible at the moment. You can’t block merges that aren’t up to date with the target branch, and merge trains are “too clever” a way of doing that. You can’t block people from being able to reveal secrets in the CI system.

Now do I think CMake is perfect? No, certainly not. But syntax is the least of the issues with it. And it’s an enormous improvement on autotools in allowing you to improve portability of your build to Windows for e.g. - and worth saying that this was true before VS added CMake support.

I would be interested to see how profitable these startups are in the face of competition in this direction, because it looks like here there’ll be a liberalisation of the rules at some point. For e.g. I know a couple of people who commute on them, but it would seem to me to make sense for them to just buy one and charge it at home/work if it was legal.

http://data.atoc.org/routeing-guide

The “pink book” is the one to look at to identify which “group” your station is part of. Then with the “yellow book”, you can use it to work out valid routes for a particular ticket, because it lists valid maps you need to join together. For e.g. if I want to travel from Nottingham to Southampton the yellow book says I can use maps:

London

BG + BW

BG + RB

DG + BW

DG + RB

Then, looking across those maps, there is a set of arcane rules determining whether a particular route is valid for a ticket which includes some calculations about ticket prices and not being able to double back on yourself through the same station. On top of that, your ticket might have specific rules on it for e.g. it’s not uncommon to get tickets that say “via London” and when that is the case you have to travel by that route.

These rules are detailed in the intro document which is actually a pretty good read (if you’re interested in trains!) and is available here: http://iblocks-rg-publication.s3-website-eu-west-1.amazonaws...

In theory the ticket selling platforms should just implement this routing guide. In practice it’s not straightforward to implement! I also have a feeling of you tried to do some of the more obscure routings that train guards or station staff might not be too happy even though in theory it is permitted.

Until two weeks ago I used to listen to Absolute Radio in my car over MW but they shut it down.

* virtualenv (external library)

* venv (fork of virtualenv included in standard library from 3.3 onwards)

* conda

* poetry

* pipenv

For e.g. compare rocFFT to cuFFT. They're worlds apart still.

Country, Sales tax, Adjusted Price, Actual Price

France, 20%, €2220, €2399

Germany, 19%, €2201, €2399

Spain, 21% , €2238, €2449

UK, 20%, £1944, £2,149

Ireland, 23%, €2275, €2499

The problem is that compiled extensions are not a minor use case for Python, they’re hugely widely used for packages even if users don’t use them that much. Building a package with no dependencies is still not that hard. But there is no good way to distribute the compiled packages you depend on as their own thing - Intel release MKL as a “Python” package for e.g. but it is just the C library [1]. But of course, if you’re a package maintainer, the chance that the package maintainer of your dependency has both uploaded it to a package manager in a language they don’t use and that also being the version you need is pretty slim. So the issue becomes “how do I bundle every single possible dependency I might need inside a Wheel”, because source installs are not something most Python users understand. Conda and Spack try and fix this issue by being general package managers that can distribute packages in any language, allowing you to depend on FFTW or Eigen or SUNDIALS or whatever you need in your C extensions, and in all of the discussion I don’t think any proposal really tackles this gap.

[1] https://pypi.org/project/mkl/

Just started it really, trying to start writing as I miss it a bit from working in academia.

I used Hugo to generate it and host it on GitHub Pages with a custom domain. I need to make some tweaks to the template I used but not really had time!

Where the DSLs fall down is when you need to do something that’s difficult to express, but for the most part if that’s necessary you can always write a script in whatever language you like and call it, which is a worthwhile approach anyway since it’s good to be able to debug your pipelines locally.