oneofthose

> AMD’s software experience is riddled with bugs [...] AMD’s weaker-than-expected software Quality Assurance (QA) culture and its challenging out of the box experience.

This has anecdotally been true since forever. Back in the day, OpenCL implementations were passing conformance test but performance was poor. They could not turn hardware capabilities into performance for compute users. Drivers were buggy. Documentation was poor compared to NVidia's docs and forum. Offerings were inconsistent (look up Sycl from Codeplay) and ownership of what it is like to develop for AMD was unclear. The notion that it might not have improved or is only now improving is puzzling. It can't be for the lack of recognizing the problem. Intuitively it does not seem so difficult. I'm curious what the reasons are.

Chromatic | Embedded/Firmware Engineer | New York City (NYC) | Full Time | https://www.gochromatic.com/

We are a small team and are building something new and exciting in the medical device space.

Skills we are looking for: ARM, RISC-V architectures, embedded C, Rust, freeRTOS, BLE, I2C, SPI, UART, I2S, PCB bringup and debugging; familiarity with Python and Bazel is a plus.

Please email me directly: seb+hn [AT] gochromatic [DOT] com

Yes I think for git users there are a number of great gui and tui and cli tools to simplify workflows. Here is a good list: https://github.com/dictcp/awesome-git?tab=readme-ov-file#cli...

I think fossil is not exactly post-git but runs in parallel with git. But definitely a good fit for small teams. For true post-git if you feel adventurous I would try jj or pijul.

I would consider CVS and RCS worth studying for historical reasons, since they have no releases for over a decade (according to Wikipedia). I was considering incorporating the history of version control, but there is already a great one here: https://blog.plasticscm.com/2010/11/version-control-timeline... -- it has a great comment section as well. Maybe it would be interesting to create an updated version of the article.

As for "$Id$", in bazel you would use https://bazel.build/docs/user-manual#workspace-status which works very well and can differentiate between stable and volatile.

That is indeed somewhat ironic. It does not seem particularly active, with the last and the last release more than 1 year ago.

Is there a design doc one could study? At a high level I understand how the fact that patches are commutative is elegant, but it seems to me there are performance impacts when, to get to a repository state, we have to apply many patches. Would love to read how pijul thinks about that.

Microchip Fabricarion has its flaws but gives a good high level overview includinh bringing, test and packaging: https://www.goodreads.com/book/show/1203098.Microchip_Fabric...

Thanks for sharing - that is too bad. Is there nothing in the way-back machine? Or maybe somebody has a local copy?

Super-cool. I love this one: https://source.puri.sm/Librem5/linux-next/-/issues/44#note_1...

That sounds so cool. Maybe collect the in a directory (like I did) and ask for permission to publish them after some time when the content might not be relevant any longer?

DBT (data build tool) [0] embraces this idea - it's like make for data transformation. Just like make its syntax is sub-optimal. But that's the only draw-back. There is an open source version, it generates documentation automatically, you can materialize tables on a schedule, it allows you to write unit tests for your data ("this select must return 0 rows" kind of tests). I'm not affiliated with them, just happy user.

[0] https://www.getdbt.com/

Would be fantastic if this could be contributed to numpy.

Edit: source code is GPL licensed https://github.com/springer13/hptt

And online: http://cdecl.org/

It would not have to be like that if Nvidia opened up the source-code for cuFFT/cuDNN/cuBLAS. My guess is they are not doing that because it is fairly trivial to port code from CUDA to OpenCL. It can even be automated.

Interesting idea. It should be only a few lines in PyOpenCL to build something like this.

But if you're already in PyOpenCL I guess would also prefer to generate the bin files there (maybe using numpy) ans evaluate the output (matplotlib possibly). For optimization you could run the kernel in a loop, time the runtime and vary the number or global and local work groups.

There is another library authored by me and some colleagues. It is called Aura: https://github.com/sschaetz/aura

I blogged about these kinds of libraries here (overview): http://www.soa-world.de/echelon/2014/04/c-accelerator-librar...

A new addition is welcome as we still have not found the perfect API for accelerator programming. EasyOpenCL seems very simple and easy to use but I feel like it is very restricted.

For getting started with OpenCL development these days I would recommend PyOpenCL. Since everything is in Python, data can be generated easily, results can be plotted using well known Python tools which simplified debugging. Kernels developed in PyOpenCL can directly be copied to other APIs (raw OpenCL C API or some of the other C/C++ wrappers) and reused in production code.

I use awesomewm - it heavily relies on the Lua scripting language. It is great and I use it on all my computers - I feel so unproductive if I don't have awesomewm.