<ivmarkov[m]>
I'll bit: this is just a wrapper around mimalloc (for linux) and embedded-alloc (for MCUs). I don't see the point of this excercise
<ivmarkov[m]>
* I'll bite: this is just a wrapper around mimalloc (for linux) and embedded-alloc (for MCUs). I don't see the point of this excercise
i509vcb[m] has joined #rust-embedded
<i509vcb[m]>
> 16KB for ARM Cortex-M (conservative estimate, M0+ typically has this capacity)
<i509vcb[m]>
I have seen M0 parts with practically no RAM (mspm0c110x) and M0 parts with loads of RAM (RP2040)
<ivmarkov[m]>
* I'll bite: this is just a wrapper around mimalloc (for linux) and embedded-alloc (for MCUs). I don't see the point of this exercise
<i509vcb[m]>
Also having to do init() is kind of asking for problems to happen
<i509vcb[m]>
What if you do something cursed like winit where you manually add code to C runtime initialization to figure out which thread is the main thread.
<i509vcb[m]>
Hope that doesn't allocate at some point or else it will explode
<i509vcb[m]>
<ivmarkov[m]> "I'll bit: this is just a wrapper..." <- The description did initially make be go "this sounds too good to be true, what on earth is inside this"
<i509vcb[m]>
s/be/me/
<ivmarkov[m]>
That's why I did bite. Sounds like an empty advertisement. "Hey, we invented a new allocator"
<i509vcb[m]>
Also if you are having to benchmark millions of allocations per second, your application may have some bigger problems than the allocator
<i509vcb[m]>
`Arc<Mutex<T>>` everywhere is almost a meme for that reason
<ivmarkov[m]>
Is it? I thought I invented "arc<mutex> the world" :D
<ivmarkov[m]>
link?
<i509vcb[m]>
I have worked on projects where `Arc<Mutex<T>>` was a religion
<i509vcb[m]>
It gets even worse when the thing being implemented can result in a tree data structure
<i509vcb[m]>
super easy to get Arc cycles
<ivmarkov[m]>
That's like using Java or any other garbage-collected runtime, except in Rust, which does not have any opts in the allocator area
<i509vcb[m]>
Oh wait until you try to reentrantly lock that mutex
<i509vcb[m]>
fun times
<i509vcb[m]>
ivmarkov[m]: The people who work on Rust emulators to avoid the `Arc<Mutex<T>>` or `Rc<RefCell<T>>>` spam have invented another funny name for a pattern. The "god" struct
<ivmarkov[m]>
Well people (guilty as charge here as well, given my last invariant lifetimes fiasco) just don't grok lifetimes, and avoid those
<i509vcb[m]>
A single struct with all the data so that every lifetime is the same
<ivmarkov[m]>
s/charge/charged/
<i509vcb[m]>
the problem there of course is that you cannot individually test something
<ivmarkov[m]>
well, my observation is that the "putting everything in a static context" pattern, which is used quite a bit in embassy, for (good) reasons also does not encourage learning lifetimes properly
<i509vcb[m]>
Unfortunately we have this big ball of mutable state called hardware
<ivmarkov[m]>
that's not the only or even the reason imo. embassy-executor just wants static futures, and then everything gets mk_static-ized, necessary or not
<i509vcb[m]>
the workaround for that unfortunately is an allocator from what I can tell
<ivmarkov[m]>
... which is fine as long as the code / APIs are done in such a way where they don't require 'static
<i509vcb[m]>
Ah yes hidden 'static bounds
<ivmarkov[m]>
Yes. every executor except embassy-executor and - hm - block_on? needs alloc
<i509vcb[m]>
smol uses alloc for sure
<i509vcb[m]>
smol does work on no_std targets but alloc can be an issue if you want static purity
<ivmarkov[m]>
i509vcb[m]: It doesn't, actually :) The only target where `smol` works is the ESP-IDF. For `smol` to work on a baremetal target, you need to implement a `block_on` primitive for that target, and I never did it
<ivmarkov[m]>
I mean, [this guy](https://github.com/ivmarkov/edge-executor) is cross-platform, but the way `smol` is designed, you need an external `block_on` for your target
<ivmarkov[m]>
* The only (embedded, but not Rust-baremetal) target where
<ivmarkov[m]>
* The only (embedded, but not Rust-baremetal) target where, * did it for anything but the ESP-IDF
<ivmarkov[m]>
* The only (embedded, but not Rust-baremetal) target where, * did it for anything but the ESP-IDF (= FreeRTOS)
<LeandroMarceddu[>
<ivmarkov[m]> "I'll bit: this is just a wrapper..." <- Thanks! TIL
sroemer has joined #rust-embedded
rainingmessages has quit [Quit: bye]
rainingmessages has joined #rust-embedded
haobogu[m] has joined #rust-embedded
<haobogu[m]>
<brightbloom[m]> "It’s been completely seamless..." <- I'm using mac and stm32/nRF52/rp2040, great dev experience.
limpkin has quit [Ping timeout: 244 seconds]
limpkin has joined #rust-embedded
limpkin has quit [Ping timeout: 260 seconds]
limpkin has joined #rust-embedded
limpkin has quit [Ping timeout: 244 seconds]
limpkin has joined #rust-embedded
Foxyloxy has quit [Read error: Connection reset by peer]
<JamesMunns[m]>
<ivmarkov[m]> "Yes. every executor except ..." <- yeah, that's not far from "block on" honestly, but I know folks are still using it :)
<ivmarkov[m]>
<JamesMunns[m]> "yeah, that's not far from "block..." <- Isn't it essentially an equivalent to `embassy_futures::block_on`? If yes, that's quite far from a real block_on. I.e. no sleep
<JamesMunns[m]>
<ivmarkov[m]> "Yes. every executor except ..." <- I'm not sure if I follow, the biggest difference is you can "single step" polling, vs block on which busy loops
<ivmarkov[m]>
Your step 3 is a busy loop as well. So unless single stepping helps debugging I don't see any difference
<JamesMunns[m]>
none really. you could sleep/delay if you wanted between steps, but yes, you could also just busy loop
<JamesMunns[m]>
(I'm not claiming it's a good one, it's definitely in the category of block-ons)
<ivmarkov[m]>
But the trick is "sleep until awoken by a waker" which makes all the difference between a proper block_on and cassette/ embassy_futures which do ignore wakers completely
<JamesMunns[m]>
I was trying to remember if you can use `maitake` no-alloc, and I think technically the answer is yes, in that you don't need the `alloc` crate, but you still need to have some way of storing tasks, and it doesn't have anything like embassy's task macro. I have used it with non-`alloc`/GlobalAlloc allocators tho.
<ivmarkov[m]>
JamesMunns[m]: But I'm saying there is nothing wrong with "proper" block_ons (that do proper sleep and are awoken by sleeps) even if they only poll one future. Because the whole point of smol executors is that their executor resolves to a single future. Where the tasks of the executor are efficiently polled with a queue.
<ivmarkov[m]>
So you need a proper block_on anyway if you want to use smol
<JamesMunns[m]>
I was not aware that any of the various block_ons actually tried to act intelligently wrt not-busy-polling.
<JamesMunns[m]>
and I guess you can, but it uses std to do thread parking?
<ivmarkov[m]>
All **except** casette/embassy_futures do.
<ivmarkov[m]>
JamesMunns[m]: Yes. Or a condvar plus mutex. Or freertos task notifications (more lightweight) for esp-idf
<JamesMunns[m]>
so, all of the std ones do? That makes sense, because you need some kind of intelligence (and an OS) to not do that.
<ivmarkov[m]>
The trick is to implement an efficie t block_on for no_std. Basically ripping out the hidden block_on so to say I side embassy-executor. But then... the world uses embassy-executor with no_std in the meantime and it is bo-alloc, etc.
<ivmarkov[m]>
JamesMunns[m]: Well, that's futures_lite, and then likely the futures one (there was one there as well right?). Not sure for tokio
<JamesMunns[m]>
I'm not sure the point we're arguing now :D
<JamesMunns[m]>
yes, you could make an efficient block on for embedded: it would require defining custom "wake"/"how you wait for wake" operations. At that point, you're not super far from embassy, honestly, and it probably wouldn't compose very well.
<JamesMunns[m]>
all the existing ones that ARE efficient are not no-std, because they use the OS to impl that ability.
<ivmarkov[m]>
1) we are not arguing we are just exchanging thoughts 2) your point that ripping off embassy-executor internals to implement a block_on is essentially the same as what I'm saying - bo point in doing that as the embedded world is just using embassy-executor with its tradeoffs, and offering alloc-based alternatives based on block_on is too little too late
<ivmarkov[m]>
s/bo/no/
<JamesMunns[m]>
I mean you probably could do an efficient block on with a simple wfe/sev, it wouldn't get you timers, and it wouldn't compose well
<JamesMunns[m]>
like, just take cassette, and instead of doing a null waker, every wake calls SEV, then in the idle loop, instead of spinning do a wfe
<JamesMunns[m]>
assuming that whatever unblocks your waiting tasks either calls wakers (some other thread sending a message or something?) or is also an interrupt that can call wakers (or just interrupts occuring wakes the wfe)
<ivmarkov[m]>
Also - if you scroll above, the whole discussion started because a poster said that smol is no_std, and then I corrected him that yeah, that might be (partially) true, but without an efficient, arch-specific block_on baremetal implementation smol is useless on baremetal. Putting the alloc concerns aside. That's all.
<JamesMunns[m]>
ah, sorry, I ran out of context window
<JamesMunns[m]>
I'm open to prompt injection now I guess
<ivmarkov[m]>
JamesMunns[m]: Why it wouldn't compose well? See above. You compose with the executor of smol. But. It. Needs. Efficient. block_on
<Lumpio->
Oh no they have been replaced by an LLM
<JamesMunns[m]>
on cortex-m, you could impl an efficient block on doing what I explain: that's exactly what embassy's executor does on cortex-m. the "compose well" note was that you could only do that if that was the only "main" function running, which like you said, is fine if you are using smol for an executor.
<JamesMunns[m]>
not trying to be difficult, I'll just leave it there. You're right nobody has a good efficient no-std block on: anyone that does basically has the whole executor done at that point anyway.
<ivmarkov[m]>
JamesMunns[m]: Exactly. Maybe my English is weird? That's what I'm saying. By now embassy-executor is the thing. "smol" does not have a chance on baremetal. The world had moved. :D See? We are not arguing, we are saying the same.
<ivmarkov[m]>
* The trick is to implement an efficient block_on for no_std. Basically ripping out the hidden block_on so to say inside embassy-executor. But then... the world uses embassy-executor with no_std in the meantime and it is no-alloc, etc.
<dirbaio[m]>
🍿
<ivmarkov[m]>
Hey it is Friday afternoon, I think this is normal then?
<dirbaio[m]>
Ah right okay
<dirbaio[m]>
Spicy Friday
<dirbaio[m]>
We should deprecate embedded-hal in favor of embedded-hal-async
<dirbaio[m]>
And update the api guidelines to ban typestates
<dirbaio[m]>
And ban from this room anyone who doesn't comply
<dirbaio[m]>
All methods in cortex-m should be async, including register access. What if you want to run cortex-m code on the host with register access proxied over usb??
<dirbaio[m]>
Oh and in Pacs too
<JamesMunns[m]>
man, the heat must really be getting to you this week
<dirbaio[m]>
Adopt embassy in the wg as the one and only true Hal
<dirbaio[m]>
🤣😱🤪
<dirbaio[m]>
(all of the above is /s just in case it isn't obvious)
<JamesMunns[m]>
🍻
<ivmarkov[m]>
Speaking of heat, going to Greece tmr and staying there. Keep this in mind maybe when hearing from me in the next days and wondering "what the f*". I mean... if you are not wondering already!
<thejpster[m]>
<haobogu[m]> "I'm using mac and stm32/nRF52/rp..." <- Mac for embedded rust is fine. Used it for work daily for nearly four years.
ouilemur has quit [Quit: WeeChat 4.6.3]
rom4ik has joined #rust-embedded
ouilemur has joined #rust-embedded
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
GuineaWheek[m] has joined #rust-embedded
<GuineaWheek[m]>
<thejpster[m]> "Mac for embedded rust is fine..." <- hit or miss on whether or not probe-rs will like your probe and flash your device ime
<GuineaWheek[m]>
GuineaWheek[m]: i have to put mine thru a usb hub first