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.

Goettingen, Germany - BiomedNMR - Research Engineer Computer Science – Real-Time MRI

The Biomedizinische NMR Forschungs GmbH (non-profit) at the Max-Planck-Institut für biophysikalische Chemie in Göttingen, Germany is looking for a Research Engineer in the area of Computer Science.

BiomedNMR is a research laboratory devoted to the development of magnetic resonance imaging (MRI) and its application for studies of living systems. A current main research focus is on the development of real-time MRI acquisition and reconstruction techniques (“MRI movies”) that allow for unprecedented possibilities for biomedical research and clinical applications. BiomedNMR is seeking support in the further development and technical translation of the real-time MRI technology to clinical centers in Germany and worldwide.

Your Profile

  * Master degree in Computer Science or Mathematics or Physics 
    or equivalent job experience
  * Excellent knowledge of C++
  * Excellent knowledge of Linux
  * Experience in either Matlab or Python or Julia
  * Knowledge in numerical analysis
  * Good knowledge of English (oral and written)
  * Experience in concurrent and parallel programming and GPUs is advantageous

We expect excellent team and communication skills and the ability to work independently and solve problems in a self-dependent manner.

Your Responsibilities

  * Development, maintenance and monitoring of an image reconstruction system 
    for human MRI in a scientific and a clinical setting 
  * Implementation and support of software for research-specific requirements
  * Implementation and support of software for partner sites

Our Offer

As a member of an interdisciplinary team of experienced physicists, biologists and medical doctors you work at the forefront of redefining the diagnostic capabilities of MRI. Within this setting, there exists the possibility of independent research projects. Employment, compensation and benefits follow the civil service labor agreement (TVöD).

Contact

Please send your application in electronic form to

  Frau Sylke Wallbrecht
  Biomedizinische NMR Forschungs GmbH
  am MPI für biophysikalische Chemie
  37070 Göttingen
  Tel.: 0551 – 201 – 1720
  E-Mail: swallbr@gwdg.de
  Web: http://www.biomednmr.mpg.de/

This article reads like an excerpt from a Vernor Vinge novel, in particular `Rainbows End`. Amazing.

There is an excellent slide deck by Kayvon Fatahalian [0] that I consider to be the best high-level introduction into the topic (especially if you have a deeper understanding of how a CPU works). But I agree, more detailed insights would be great.

[0] http://s08.idav.ucdavis.edu/fatahalian-gpu-architecture.pdf

Great article the gist I get from it is: running an experiment in computer science is easy (just ./bench), running an experiment in computer science in a correct way is hard. I agree with this assessment.

This plotty tool [0] seems interesting and valuable - but I'm not sure how it relates to the problem the author talks about.

[0] https://github.com/jamesbornholt/plotty

Their next generation should include a SoC with a GPU. GPUs make these little processors even more interesting.

Food production has become cheap and efficient. So efficient in fact, that it has apparently no significant economic impact if "as much as 40 percent of America's food supply ends up in a dumpster". Otherwise, the market would improve efficiency with regards to wasting all that food.

I find particularly appalling that the production of animal products has become so economical that it does not matter that so much is thrown away. Efficient meat production means of course factory farming and questionable treatment of animals. This is a problem. The other problem is with the consumers of such cheap animal products. They are not aware anymore, have no respect for the fact that the thing they just gobbled up (and threw away) was once a living breathing being. It is sad.

A few days ago I stumbled on Axios, an "Open Source Modular Ergonomic Keyboard". They are preparing a crowd-funding campaign here [0].

[0] https://www.crowdsupply.com/multiplxd/axios-keyboard

Is it just me or is this a 180 degree turn around for Deutsche Telekom? After the NSA scandal they planned to create an "All-German Internet" [0] (a strange plan to begin with) but now they seem to be saying: we don't care, let us let our users store their data in "in data centers across the United States" [1]. As if nothing ever happened.

[0] http://www.spiegel.de/international/germany/deutsche-telekom... [1] https://www.dropbox.com/help/7/en

I think this proofs Scott Meyers point about the most important feature we have in C++: the destructor.

Templates are an essential tool to write type-independent algorithms. They enable meta-programming, an invaluable tool to provide flexible yet efficient active libraries to users. They allow automated kernel-space exploration. So templates are exactly what you want.

I understand the need for a standard that supports various different architectures, even architectures that might not exist yet. I guess I just dislike the way the did it. Compared to other standards (that also leave various things to the implementer), I think they did a poor job. They should have defined the semantics and the types better. The entire buffer mapping for example is a huge mess. Nvidia went ahead and fitted pinned memory in there somewhere. Others didn't, with the result that the meaning of the code changes completely depending on which library you link against.

I'm not arguing against OpenCL here, I'm saying they could do even better. It should not be too much effort too. And if companies like Apple and Google would have chimed in, we would have pretty awesome OpenCL standard and implementations today.

As for your argument about hand-optimization: C++ library implementers [0,1] (and compiler vendors probably too) found abstractions, tricks and tools that give performance portability today. They are of course domain-specific but it is possible.

[0] https://github.com/MetaScale/nt2 [1] http://eigen.tuxfamily.org/

I guess "language support" was referring to the restrictions within the kernel language. And CUDA is better there - they support templates, you can typecheck a CUDA kernel call. With OpenCL you have to jump through hoops to get that. While some projects have managed to do it, it could be better still.

What bugs me about OpenCL is the intentional vagueness of the specification that gives every implementer the freedom to do whatever they want with the result that performance portability is often difficult to achieve.

I disagree. "The Metal framework supports GPU-accelerated advanced 3D graphics rendering and data-parallel computation workloads".