rust_dos VS raphlinus

You do not need segment registers much if you stick to the tiny model. Here is someone compiling Rust to a 16-bit DOS COM executable:

https://github.com/o8vm/rust_dos

Not sure what the approach would be for them to expand that to support segments.

In DJGPP there are macros to allow your protected mode application access physical real-mode addresses (like when you want to write to video RAM). I don't know if IA-16 also does something like that, or if they added far/near keywords to the language like old 16-bit C compilers did (at least the ones I used).

Free Pascal has helper-functions to work with segment+offset pointer pairs, also without having to modify the language itself. I think that would work well enough in C, but I guess the old method of adding non-standard keywords was seen as slightly more convenient.

Demo: https://github.com/o8vm/rust_dos

It is probably possible for almost any old platform with some cross-compilation magic, but not anything that will be officially supported as the compiler-makers focus on modern systems. There is for instance an unofficial 16-bit DOS backend for GCC and at least one or two projects to compile Rust to DOS-executables (that I assume use Clang?) (in addition to 32-bit DJGPP(gcc) for MSDOS that I linked to above). Probably are similar projects to target 68k somewhere?

That's surprising, given the legendary sense of humor of the C++ community.

I have some ideas on how to do boolean ops, some of which is written up in a blog post issue, and for which I have some code locally. In particular, the parabola estimate seems much more efficient than the usual fat line approach. I also have a sketch of quadratic/quadratic intersection in kurbo#230.

I am. It is relevant to the topic, and I cite it in the (now two year old) outline for the blog post I intend to write on the topic[1].

[1]: https://github.com/raphlinus/raphlinus.github.io/issues/40

I rewrote that paragraph, as I realize it comes across too contentious. Thanks all for the feedback!

To do video properly requires integration with the platform compositor. This is a fiendishly difficult problem, and I know of no serious effort to solve it. I have an outline of a blog post on the topic, and hope to publish it before too long.

I am working on this problem too, and have an issue on my blog with an outline of the writeup. Stay tuned!

> PS, is your monoid work online, is it this https://arxiv.org/abs/2205.11659 ? I'm interested in monoids on GPUs.

Yes, the draft is on arXiv, and I have a blog post in the pipeline[1] explaining it to a more general audience.

And thanks for the other advice, I'll consider it!

[1] https://github.com/raphlinus/raphlinus.github.io/issues/66

The new xilem async architecture is designed to integrate much more finely with async. I have an outline of a blog post in the queue but am juggling a lot of things right now. Expect to see some updates, but not super soon.

This is a hard problem and one of the hardest parts is figuring out scope. I have an upcoming blog post which will touch on some of the issues. In any case I'd love to see some progress on larger ecosystem collaboration.

The short answer is no, but the long answer is that this is a very complex tradeoff space. Going forward, we may see more of these types of tasks moving to GPU, but for the moment it is generally not a good choice.

The GPU is incredible at raw throughput, and this particular problem can actually implemented fairly straightforwardly (it's a stream compaction, which in turn can be expressed in terms of prefix sum). However, where the GPU absolutely falls down is when you want to interleave CPU and GPU computations. To give round numbers, the roundtrip latency is on the order of 100µs, and even aside from that, the memcpy back and forth between host and device memory might actually be slower than just solving the problem on the CPU. So you only win when the strings are very large, again using round numbers about a megabyte.

Things change if you are able to pipeline a lot of useful computation on the GPU. This is an area of active research (including my own). Aaron Hsu has been doing groundbreaking work implementing an entire compiler on the GPU, and there's more recent work[1], implemented in Futhark, that suggests that that this approach is promising.

I have a paper in the pipeline that includes an extraordinarily high performance (~12G elements/s) GPU implementation of the parentheses matching problem, which is the heart of parsing. If anyone would like to review a draft and provide comments, please add a comment to the GitHub issue[2] I'm using to track this. It's due very soon and I'm on a tight timeline to get all the measurements done, so actionable suggestions on how to improve the text would be most welcome.

[1]: https://theses.liacs.nl/pdf/2020-2021-VoetterRobin.pdf

[2]: https://github.com/raphlinus/raphlinus.github.io/issues/66#i...