costrouc

I use this extension all the time and for the most part it is identical to Magit. It is a little frustrating at times that Edamagit loses focus (unsure why). This extension along with `tuttieee.emacs-mcx` are what allowed me to transition to VSCode and have nearly the same productivity.

There is a very good reason. Nix strives to be reproducible. Thus all hardcoded paths in builds have to point somewhere. /nix was chosen.

There is a quite mature configuration language nix that is behind nixpkgs, nixos, and many other projects. Worth checking out for others here that are interested in abstractable configuration langauges. It is a functional lazily evaluated language.

Word on the street is that Nvidia insisted that they pay the full price for the GPUs this time and were giving them at a discounted rate prior.

in my opinion several build systems / package managers have already solved this issue. The answer is that it doesn't matter mono repo vs polyrepo. Look at nixpkgs/nixos/nixpkgs if you are interested

I really like this. I think it is a great compromise between the limitations of docker and everything packaged in one file while taking advantage of nix. I'm curious about one other optimization that could be made.

You could instead look at the dependency graph of several nix docker builds and increase the cache reuse even more from that.

I didn't see in the paper why these methods are not used in practice. There are parallel implementations of strassens algorithm out there (I have written one). Yes they are faster but they do not guarantee stability. Also they are significantly harder to parallelize than block cyclic MM.

I am a fan of LyX but using version control with the resulting tex document is near impossible and does not work well with others editing in a regular text editor. Wonder if anyone else had this experience?

Will web assembly have any effect on a future web based python interpreter? Is there one in the works?

Python does not make these assumptions. There are Python tools that exist to solve these problems that are equally as powerful as other language's solutions. The two that I believe right now address these problems best are dask and mpi4py. Mpi4py can achieve very low latencies but given that it's based on MPI it can be complex to use. dask is the most user friendly and as a Python user is clearly easier to use than spark. Paired with numba you can get equivalent performance to distributed C programs.

Matrix multiplication involves moving across one matrix in column order and the other matrix in row order. So it turns out that both row or column ordering make no difference. I think that matrix multiplication is one of the best examples of a deceptivly simple problem. It shows how far ALL code is from peak performance. We can only strive to be within an order or two from peak performance.

For those wondering the lapack guys are working on a new version of lapack to run on heterogeneous architecture including gpus. See their work at http://www.icl.utk.edu/research

I have worked with these guys and all I can say is good luck outperforming the highly optimized routines they have written. My bet is that the the guy writing this blog used a non optimized version of lapack.