I might be misremembering but I recall that Nvidia's BlueField DPUs use virtio when communicating with the host machine. From what I gather searching around it's virtio-net in specific
145 karma · joined March 27, 2021
One issue I’ve heard from F# devs was the lack of ability to comfortably call C# asynchrony methods
Does this change anything w.r.t your response?
IIRC it’s used in the desktop client and some community libraries (specifically JDA) have support for it.
There were some quirks regarding ETF usage with Discord’s Gateway but I can’t recall at the moment.
RAID56 under Btrfs has some caveats but I'm not aware of any annecdata (or perhaps I'm just not searching hard enough) within the past few weeks or months about data loss when those caveats are taken under consideration.
As an aside, and as someone who's currently going through materials such as Crafting Interpreters (and who knows what else based on suggestions from r/compilers), is there a, I guess, guide for people who want to implement a compiler that targets the CLR/CLI?
I have a copy of CLR via C# 4th edition, but other than that not sure what else I can reference targeting anything newer than .NET Framework 4
On a tangent and I also don't know how others would view this, but I personally think that trivial desktop applications have or will have moved on to solutions like (but not exactly server-sided) Phoenix Liveview or Blazor Server. No real need to bother with multi-platform solutions when there's already one the end user uses daily and is battle tested. The case of applications needing the usage of a GPU likes games aside that is.
> p.s.: I'm daily driving Ghidra currently which is built with Java Swing and it looks like straight out of 90s in a bad way haha
I don't know, I have a fondness of that old ass style of GUI lol
I ask cause the Project Galahad page on openjdk.org is a bit sparse on details.
On the note of quay.io, is there a function on the website to see the Containerfile that created the artifact? I recall digging around in the past but couldn't really find a link to the source Containerfile.
For example I saw that in your blog [1] you used the base on line 1 `FROM ghcr.io/cgwalters/fedora-silverblue:37`.
I was wondering where I could find the Containerfile for that, my Google-fu and searching through the Fedora pages are failing me
[1] https://www.ypsidanger.com/building-your-own-fedora-silverbl...
We probably should've established this way earlier, sorry if I came across as pretentious or off putting.
I'll answer in a bit of reverse order.
> I just want to explain why I believe that function coloring (or however you call it) can never be conceptionally be removed from a language if sync/async is to be supported.
To respond in more of a roundabout way, why doesn't C have colouring issues if it too supports asynchronicity (I'm pretty sure I've made up a word but hope the point gets accross fine) via pthreads?
The colouring issue is, at least under my understanding of C#'s async/await system is to accommodate for the fact that Rosyln transforms the C# source into .NET IL with a state machine. It's, to me at least, just a consequence from what layer of the stack we talk at. Erlang doesn't need to worry about since the runtime was designed to run with this specific model of concurrency in mind; but if we look at C#, .NET only supports using OS threads (though David Fowler is investigating green threads in the, iirc, labs repository on the DotNet Github) the async/await is, for lack of a more better word, bolted on. It's to my understanding that IronPython (or maybe it was PythonNet) has difficulties calling into C# async for that reason; though if I'm wrong please correct me.
> is the sole purpose of the existance of those primitives to change performance characteristics? If not, what is the purpose of its existence then?
Fault tolerance, latency, scalability, perhaps minor throughput increases (yeah this is a bit of a contradiction to what I said earlier, but I've revised my opinion that you wouldn't see massive performance gains unless resorting to NIFs).
The Phoenix Framework's 2 million websocket connection challenge I think is a best demonstrator for the use case of BEAM processes. A specific websocket connection dies? No problem, the Supervisor respawns it. Two million connections receiving a Wikipedia length article on a topic without the entire system coming to a crawl? No problem. There isn't a need to worry about kqueue, poll/epoll, or IOCP here, just fire off a task for the purpose and let it do it's thing.
But overall you wouldn't spawn a BEAM process just so you could compute the matrices behind RAID6/RAIDZ2, you'd delegate those to NIFs. The biggest gains in overall performance came from BeamAsm instead.
> Okay, let me follow up on this one. So could we take arbitrary Erlang/Elixir programs and automatically/mechanically rewrite them to push previously inlined calculations to be run on a different process (using spawn) or the otherway around - and that without causing any observable difference in behaviour in any situation except for difference in performance?
Yes. Using the case of the 2 million websocket connection challenge earlier, it doesn't really matter if each of those connections spawned another process as part of its routines, the other processes don't know and don't care. Taking a more generic case of Elixir's GenServers (or gen_server in Erlang), when I perform a call (as in the GenServer behaviour) it doesn't matter to the calling process what happens behind the scenes, it just blocks and waits for a response. The GenServer could fire off any number of processes it wants but the calling process doesn't care about that.
> Moreover, there is a context switch and it's more likely the code will run on a different core if you run it async than if you run it in the same process (which is very likely but not guaranteed) to run on the same core.
Yes I agree, but the question as presented by valenterry asks us whether or not there is some existing semantic difference and not under the confines of performance (both gains or losses). Regardless what you have stated are all true.
But as an aside, and not directed towards you, Task.async/3 doesn't do anything that the developer cannot already do. Even in the tutorial for the learning Elixir, the fledgling developer is exposed to the different mechanisms that power Task.async/3, the source code [1] reflects this, although supervisors are covered much later down the line. The documentation for
> The way in which they are equivalent, is that the code that you write is identical, and the bytecode that gets run, and the existence of implicit yields is identical between the async and "sync" code.
And just to add on for those not familiar with the BIFs, receive, which is what Task.await/2 and Task.yield/2 use under the hood, yields execution. NIFs are another one.
[1] https://github.com/elixir-lang/elixir/blob/fb729784e5504f499...
In a vacuum (i.e. via spawn/1 or spawn/3) there is no observable change in behaviour throughout the whole system.
If they're linked via spawn_link then a child process crashing means the parent process dies with it unless handled in some way.
So ultimately, no there isn't observable changes. My logging process doesn't care or even know that my WebSocket process crashed.
> Or in other words: is the sole purpose of the existance of `Thread.async` (or spawn, pick whichever you want) to change performance characteristics? If not, what is the purpose of its existence then?
As stated before Task.async/3 is just a convenience wrapper around low-level BEAM primitives, there isn't anything special about Task.async/3 that you couldn't do via spawn.
The reason being that the BEAM VM schedulers prioritizes overall latency of the system over throughput by enforcing reduction calls (parlance for a function call, but specifically for tracking looping in the BEAM) at around 4000 calls, then it moves the current process back into the queue; repeat ad infinitum.
So you don't get massive speedups just spawning a new BEAM process but your independent units of execution still enjoy the same overall latency as before. If you want performance increases in the BEAM you would need to jump to dirty schedulers and NIFs which carry their own dangers.
An Elixir, Erlang, or any other developer using the BEAM VM (or at the very least myself since I don't want to generalize) doesn't make a semantic distinction between spawn and Task.async/3 because there is none. The significant differentiation is whether or not the caller is expecting a returned value, if not then Task.start_link can be used instead.
I don't need to worry about function colouring because there is none. I also don't need to worry about async vs Task.run like in C# because in Elixir there is none. To be asynchronous in Elixir/Erlang/etc... is to be synchronous. To equate it to modern backends, we basically have a microservice but every service can directly call each other.
I think I also might have been talking around you a bit, the BEAM VM sets itself apart from C#'s async/await or the TPL due to its implementation of the actor model. This video by Sasa Juric can explain better than I can the general overview of the BEAM: [1].
But a rough tl;dw, a BEAM process is to the BEAM, what an OS process is to the OS. We don't define a main function as the process supervisor in BEAM spawns processes we define instead and those are our "entrypoints."
Task.async/3 and Task.await/2 are, from the thousand foot view, the equivalent of:
parent = self()
spawn(fn -> send(parent, do_something()) end)
receive do
result -> IO.puts result
end
Put more generally, the mentality of concurrency in Elixir/Erlang is the equivalent as that of traditional pthreads in C.