@kornel@mastodon.social
@kornel@mastodon.social avatar

kornel

@kornel@mastodon.social

This profile is from a federated server and may be incomplete. Browse more on the original instance.

kornel, to random
@kornel@mastodon.social avatar

I'm writing a fluid simulator as an excuse to learn more #shader coding.

I get now why people keep reinventing fluid simulators — there's some very clever math in the fundamentals, but also the problem has no right solution, so there's also lot that can be fudged and tweaked for different results.

kornel,
@kornel@mastodon.social avatar

@LeoniePhiline Pages and pages of texture binding boilerplate.

kornel,
@kornel@mastodon.social avatar

My #gpu fluid sim is working!

Debugging of these things is hard, because every step of the sim has a circular dependency on every other step, so a bug in one of them breaks them all.

Now I'm trying to make it a proper #Bevy plugin and hook up to lights.

ad-hoc visualization of eulerian fluid sim - density, divergence, velocity, pressure

kornel,
@kornel@mastodon.social avatar
litchipi, to rust
@litchipi@fosstodon.org avatar

I just had a 23% speed increase on my project by disabling "panic = abort" in the release profile...

And I can consistently slow it back down when adding it again

Is there something there I'm missing ? Seams really odd

kornel,
@kornel@mastodon.social avatar

@litchipi Panics prevent optimizations, because code cannot be moved around then, and panicking code paths can't be merged (because every one of them is a side effect, and displays its original code location).

If you have code like for i in _ { vec[i] }, it can be bogged down a lot by panics. Use non-panicking alternatives whenever possible, like iterators or vec.get(i)?.

kornel, (edited )
@kornel@mastodon.social avatar

@litchipi the other way around - panic=unwind is slowest, because it needs to preserve state for unwinding. panic=abort is less bad, because panic won't return, and panic=immediate_abort (unstable) is fastest, because it doesn't need any state preserved, and using return instead of panic is ideal because then llvm knows what they are and can move and coalesce returns.

Soblow, to rust
@Soblow@eldritch.cafe avatar

Is there a way in Rust to use standard lib traits (Ord, Eq, Into/From...) with async functions?
Perhaps a crate or something?
Or must it be a separate function implemented for the structs?

kornel,
@kornel@mastodon.social avatar

@Soblow It's not possible. These traits require returning result immediately, and this is their guarantee that cannot be changed. You need to create your own methods for this, or preload data ahead of time.

kornel, to random
@kornel@mastodon.social avatar

I love this GIF. I feel like I've been there:

https://mastodon.art/@6VCR/111308560707196637

jarkko, to rust
@jarkko@social.kernel.org avatar

I think there would be still space for systems programming language with a constraint from day zero that it would 1:1 compatible with plain C”s binary layout and memory model:

  1. Roughly just .text, .bss, .rodata and ,data.
  2. No symbol mangling at all.

All the memory safety etc. fancy features would be then designed within exactly those constraints.

is essentially a derivative of C++ when compiled to binary, which does not really make it a strong competitor for plain #C. It can substitute C in many cases for sure, just like C++ did, but there’s always need for minimal systems programming language, which also looks elegant in binary, not just in source code.

A compiled C program can be quite easily understood with a binary with no debug symbols at all if you understand the CPU architecture well enough. That is, and will be a strong asset for C.

kornel,
@kornel@mastodon.social avatar

@jarkko Safety is like a thread you start to pull, and pulls more and more stuff. You need collections for bound checks and robust realloc, but void* casts complicate verification, so you need generics for collections. To reduce bounds checks, you need iterators. Safe unions require sum types. Unsafe free() can be replaced with destructors, which need owned+borrowed pointers. You need thread safety too, etc.
There isn't much that can be removed from Rust without creating holes in the safety.

kornel, to random
@kornel@mastodon.social avatar

TIL: when running software in chroot, there is no /dev, so /dev/null can end up being a regular file, and then reading from /dev/null is a surprise.

triskelion, to rust
@triskelion@floss.social avatar

Hey RIIR enthusiasts, sorry to disappoint you, but LLVM and glibc are not written in . Feel free to express your frustrations xD

kornel,
@kornel@mastodon.social avatar
kornel, to llm
@kornel@mastodon.social avatar

There's an economic curse on Large Language Models — the crappiest ones will be the most widely used ones.

The highest-quality models are exponentially more expensive to run, and currently are too slow for instant answers or processing large amounts of data.

Only the older/smaller/cut-down models are cheap enough to run at scale, so the biggest deployments are also the sloppiest ones.

markstos, to rust
@markstos@urbanists.social avatar

I don't understand this #Rust #RustLang error message:

 Updating crates.io index  
error: failed to select a version for the requirement `bindgen = "=0.69.4"`  
candidate versions found which didn't match: 0.65.1, 0.64.0, 0.63.0, ...  

If I run crate search bindgen, it shows that v0.69.4 clearly exists.

Cargo.toml contains:

[build-dependencies]
bindgen = "0.69.4"

kornel,
@kornel@mastodon.social avatar

@markstos your compiler is too old, and doesn't know how to downloaded packages for Rust v1.60+.

Run rustup update. If you've installed from a distro package, get rid of it and use https://rustup.rs instead.

kornel,
@kornel@mastodon.social avatar

@markstos you may still have a non-rustup version of rust/cargo installed. v1.75 would work fine. The dependency problem affects only 1.59 and older, and edition=2021 breaks 1.55 and older.

shafik, to random
@shafik@hachyderm.io avatar

"Our analysis shows that
52% of ChatGPT answers contain incorrect information and 77%
are verbose.": https://dl.acm.org/doi/pdf/10.1145/3613904.3642596

If you have to basically verify everything then what is the point? I can see how it may point you in the right direction and that could be helpful but it could easily do the opposite as well.

It is essentially a coin flip.

kornel,
@kornel@mastodon.social avatar

@dalias @shafik

  1. This data is based on GPT 3.5. Their small test of GPT 4 suggests it'd have ~66% accuracy.
  2. These are not binary yes/no answers. The random baseline is 0, not 1/2.
  3. The biggest error category in this test was misunderstanding the question. The chat interface allows adding clarifications, the test did not. Factual errors were less common.
kornel, to random
@kornel@mastodon.social avatar

I've been using https://DuckDuckGo.com as my default search for years now. It's fine.

DDG supports a special !g keyword that redirects the search to Google, so I can easily get a second opinion when DDG isn't finding what I want.

kornel,
@kornel@mastodon.social avatar

@lapcatsoftware I know, but using Bing's index is not the same as using bing dot com with Microsoft's ads.

kornel,
@kornel@mastodon.social avatar

@lapcatsoftware Eh. At least not Microsoft's tracking then?

became_fish, to rust
@became_fish@jorts.horse avatar

people say "C++ isn't any closer to the metal than #rust is" but what is the memory footprint of returning a Result? in C++ i can pass an out parameter by reference to avoid allocating anything on the stack - how do i do that in rust? is it with a &mut ptr? is it done automatically by the compiler when returning?

kornel,
@kornel@mastodon.social avatar

@became_fish Yes, the ABI automatically switches to returning by reference when the Result is too large to spread across registers.
There's also niche optimization, e.g. Result<Box<T>, UnitErr> is just a pointer. More efficient than ABIs of unique_ptr/variant/expected.

kornel,
@kornel@mastodon.social avatar

@became_fish &str is conceptually identical to string_view.
Box<str> is the same ptr+len, but heap allocated.
Vec<char> is UTF-32, and generally avoided.
Rust has no copy constructors. You can't copy heap types by mistake. It's like RVO guaranteed everywhere all the time.

kornel,
@kornel@mastodon.social avatar
kornel,
@kornel@mastodon.social avatar

@became_fish Yes, because String is heap allocated by definition. It's {ptr, capacity, len}.

&str is ambivalent about the data source, and guarantees to never run any destructor or free() on the pointer.

Cow<str> holds a bool that tracks whether to free or not.

thephd, to random
@thephd@pony.social avatar

It's time.

RAII in C, and why nobody's getting it right with the increasingly "simple" juggling that keeps getting tossed to me like table scraps for a dog.

The Pasture | Why Not Just Do Simple C++ RAII in C? | https://thephd.dev/just-put-raii-in-c-bro-please-bro-just-one-more-destructor-bro-cmon-im-good-for-it

kornel,
@kornel@mastodon.social avatar

@PeterSommerlad Rust's Box takes advantage of the moved-from not existing:

  • its pointer has a noalias and non-null guarantees for the optimizer.
  • 0 is never valid for it, which allows 0 to be used as a tag in tagged unions. Option<Box> has the same ABI as a pointer, not {bool, nullable ptr}.
  • redundant destructors are not emitted at all in many cases. Quicker codegen, noalias, easier TCO.
  • use of moved-from variable is always caught by the compiler, and this extends to user-defined types.
kornel,
@kornel@mastodon.social avatar

@PeterSommerlad for types like String or Vec this has user-friendly semantics, because it's like a guaranteed RVO everywhere — no accidental deep copies on forgotten move.

kornel,
@kornel@mastodon.social avatar

@PeterSommerlad Also the moved-from state prevents proving uniqueness at compile time. Without it, it could have been possible to simulate the borrow checker in C++:

https://docs.google.com/document/d/e/2PACX-1vSt2VB1zQAJ6JDMaIA9PlmEgBxz2K5Tx6w2JqJNeYCy0gU4aoubdTxlENSKNSrQ2TXqPWcuwtXe6PlO/pub

  • All
  • Subscribed
  • Moderated
  • Favorites
  • JUstTest
  • ngwrru68w68
  • everett
  • InstantRegret
  • magazineikmin
  • thenastyranch
  • rosin
  • GTA5RPClips
  • Durango
  • Youngstown
  • slotface
  • khanakhh
  • kavyap
  • DreamBathrooms
  • provamag3
  • ethstaker
  • osvaldo12
  • tester
  • cubers
  • cisconetworking
  • mdbf
  • tacticalgear
  • modclub
  • Leos
  • anitta
  • normalnudes
  • megavids
  • lostlight
  • All magazines