I am surprised to see those discussions w/o a single mention of roon. As a music lover, roon is a software I've happily paid 100 of $ for.
While not OSS, roon
1) can run on linux
2) supports large local libraries (I have > 2k albums in FLAC, and it supports much more)
3) have roon arc that allows you to listen from phone anywhere
4) has a very good system to link metadata and recommendation within your library.
The metadata support is truly wonderful, you can easily browse your music like wikipedia, can find music per composer, performer, discover related musicians, etc. I strongly recommend people serious about music to try it out.
I've happily replaced spotify with it a few years ago, and will never go back.
Roon seems great but the pricing is really steep in my opinion... Costs practically as much as a streaming service, but you still need to get your own music.
At least they have a lifetime purchase option, though it costs $830!
It is not cheap, but it is clearly made by people who care about music. In those days where "slop" is so common, for people who can afford it, it is a nice refresher.
Another minor inconvenience is that it is memory hungry for large libraries. In my case, for ~1 TB of flac, the docker takes 5-6 GB RAM on my debian NAS. Limiting it at 4 GB definitely crashed w/ OOM, at 8Gb never had issue.
the big O copmlexity makes assumptions that break down in this case. E.g. it "ignores" memory access cost, which seems to be a key factor here.
[edit] I should have said "basic big O complexity" makes assumptions that break down. You can ofc decide to model memory access as part of "big O" which is a mathematical model
I agree ability to use python to "script HPC" was key factor, but by itself would not have been enough. What really made it dominate is numpy/scipy/matplotlib becoming good enough to replace matlab 20 years ago, and enabled an explosion of tools on top of it: pandas, scikit learn, and the DL stuff ofc.
This is what differentiates python from other "morally equivalent" scripting languages.
I agree it is confusing, because starting with notation will confuse you. I personally don't like the partial derivative-first definition of those concepts, as it all sounds a bit arbitrary.
What made sense to me is to start from the definition of derivative (the best linear approximation in some sense), and then everything else is about how to represent this. vectors, matrices, etc. are all vectors in the appropriate vector space, the derivative is always the same form in a functional form, etc.
E.g. you want the derivative of f(M) ? Just write f(M+h) - f(M), and then look for the terms in h / h^2 / etc. Apply chain rules / etc. for more complicated cases. This is IMO a much better way to learn about this.
I was surprised at previous comparison on omarchy website, because apple m* work really well for data science work that don't require GPU.
It may be explained by integer vs float performance, though I am too lazy to investigate. A weak data point, using a matrix product of N=6000 matrix by itself on numpy:
- SER 8 8745, linux: 280 ms -> 1.53 Tflops (single prec)
- my m2 macbook air: it is ~180ms ms -> ~2.4 Tflops (single prec)
This is 2 mins of benchmarking on the computers I have. It is not apple to orange comparison (e.g. I use the numpy default blas on each platform), but not completely irrelevant to what people will do w/o much effort. And floating point is what matters for LLM, not integer computation (which is what the ruby test suite is most likely bottlenecked by)
Apple M chips are slower on the computation that AMD chips, but they have soldered on-package fast ram with a wide memory interface, which is very useful on workloads that handle lots of data.
Strix halo has a 256-bit LPDDR5X interface, twice as wide as the typical desktop chip, roughly equal to the M4 Pro and half of that of the M4 Max.
You're most likely bottlenecked by memory bandwidth for a LLM.
The AMD AI MAX 395+ gives you 256GB/sec. The M4 gives you 120GB/s, and the M4 Pro gives you 273GB/s. The M4 Max: 410GB/s (14‑core CPU/32‑core GPU) or 546GB/s (16‑core CPU/40‑core GPU).
It is very likely: the atomic bomb was initially built to defeat Nazi Germany, and the Manhattan program was started before Pearl Harbour. When you read The Atomic Bomb book, many scientists who worked on the bomb justified their effort by defeating the Nazis, and many had to escape from Europe.
Once it became clear Nazi were about to be defeated, there were discussions from the scientists about sharing the knowledge w/ all countries. But at that point, the scientists had long lost control over the project.
If I understand correctly what is meant by rank polymorphism, it is not just about speed, but about ergonomics.
Taking examples I am familiar w/, it is key that you can add a scalar 1 to a rank 2 array in numpy/matllab without having to explicitly create a rank 2 array of 1s, and numpy somehow generalizes that (broadcasting). I understand other array programming languages have more advanced/generic versions of broadcasting, but I am not super familiar w/ them
Or a good one who cares about their naive reports not to get burn.
Like any advice, it is contextual. Especially when working for large organizations, the OT is the right default. If you're leaving because things are bad, it will be a mix of 1) people know but did not care/could not do anything about it and 2) people did not know about specific issues. Younger me thought it was often 2), but actually it is almost always 1).
SVD/eigendecomposition will often boil down to making many matmul (e.g. when using Krylov-based methods, e.g. Arnoldi, Krylov-schur, etc.), so I would expect TPU to work well there. GMRES, one method to solve Ax = b is also based on Arnoldi decomp.
A/B testing does not have to involve micro optimization. If done well, it can reduce the risk / cost of trying things. For example, you can A/B test something before investing a full prod development, etc. When pushing for some ML-based improvements (e.g. new ranking algo), you also want to use it.
This is why the cover of the reference A/B test book for product dev has a hippo: A/B test is helpful against just following the HIghest Paid Person Opinion. The practice is ofc more complicated, but that's more organizational/politics.
In my own career I've only ever seen it increase the cost of development.
The vast majority of A/B test results I've seen showed no significant win in one direction or the other, in which case why did we just add six weeks of delay and twice the development work to the feature?
Usually it was because the Highest Paid Person insisted on an A/B test because they weren't confident enough to move on without that safety blanket.
There are other, much cheaper things you can do to de-risk a new feature. Build a quick prototype and run a usability test with 2-3 participants - you get more information for a fraction of the time and cost of an A/B test.
There are cases where A/B testing does not make sense (not enough users to measure anything sensible, etc.). But if the A/B test results were inconclusive, assuming they were done correctly, then what was the point of launching the underlying feature ?
As for the HIPPO pushing for an A/B test because of lack of confidence, all I can say is that we had very different experiences, because I've almost always seen the opposite, be it in marketing, search/recommendation, etc.
"not enough users to measure anything sensible" is definitely a big part of it: even for large established companies there are still plenty of less than idler used features that don't have enough activity for that to make sense.
A former employer had developed a strong culture of A/B testing to the point that everyone felt pressure to apply it to every problem.
While not OSS, roon 1) can run on linux 2) supports large local libraries (I have > 2k albums in FLAC, and it supports much more) 3) have roon arc that allows you to listen from phone anywhere 4) has a very good system to link metadata and recommendation within your library.
The metadata support is truly wonderful, you can easily browse your music like wikipedia, can find music per composer, performer, discover related musicians, etc. I strongly recommend people serious about music to try it out.
I've happily replaced spotify with it a few years ago, and will never go back.