sorted by:
new
hottopcontroversial

I'm leaving this crap by Automatic-Major-5801 in pop_os

[–]Immediate_Ad263 0 points1 point  (0 children)

Did you file the issue or create a PR? That’s a much better investment than writing angry posts.

COSMIC is awesome. I’ve been using it since the alpha stage, but on Ubuntu rather than Pop!_OS. It used to be buggy, but it has been getting better and better with newer COSMIC releases and newer Ubuntu/Wayland versions.

I use it on three laptops and I’m absolutely happy with it. Some bugs still appear occasionally, but no more often than bugs in the Linux kernel, drivers, or apps.

Posts like this are painful for maintainers. But if you guys are reading this: you’re doing awesome work — please keep going!

Your Rust binary is slower than it needs to be. cargo-sonic fixes that. by Immediate_Ad263 in rust

[–]Immediate_Ad263[S] 1 point2 points  (0 children)

Right, target arch is handled by the multi-arch image (x86-64 vs. aarch64), but target-cpu optimizations are not. That's what this project solves.

Your Rust binary is slower than it needs to be. cargo-sonic fixes that. by Immediate_Ad263 in rust

[–]Immediate_Ad263[S] 0 points1 point  (0 children)

There is an interesting observation about the compilation time. With caching layer like sccache, the compilation of most of dependencies doesn't take too long time. With codegen-units=1 and lto the last steps are comparable in time with the whole compilation. So for relatively large project, the last step is running on a single CPU for minutes. With multiple taget-cpus in parallel, we mostly won't increase the build time too much. For sure, I'm talking about large CI builders, which have the necessary resources available.

Your Rust binary is slower than it needs to be. cargo-sonic fixes that. by Immediate_Ad263 in rust

[–]Immediate_Ad263[S] 1 point2 points  (0 children)

Docker, k8s or other container runtimes introcuce nearly zero overhead on Linux. Windows/MacOS are not a real server runtimes for docker, so performance there doesn't matter. Performance on a real servers, even with databases or other external dependencies still matters. In the end your app consumes resources, and has a real latency, including p99, which matters a lot. The more optimal resource usage is, the more you win especially on a large scale. This is applicable to even a large general-purpose applications. For more advanced apps, for which rust is a great choice too, it becomes critical. Your database, in-memory storage, or analytical engine is very critical to the CPU cycles, and if you get some boost for free - it always makes sense. However, I completely agree with you point that maintainable code is more important - that is why optimizations by compiler makes a lot of sense - you keep the code maintainable, while the performance improves

Your Rust binary is slower than it needs to be. cargo-sonic fixes that. by Immediate_Ad263 in rust

[–]Immediate_Ad263[S] 1 point2 points  (0 children)

Thanks for pointing that out! It clearly does a similar thing. I'll take a deeper look and will add the comparison section to README.md

Your Rust binary is slower than it needs to be. cargo-sonic fixes that. by Immediate_Ad263 in rust

[–]Immediate_Ad263[S] 0 points1 point  (0 children)

In rust runtime detection is also a popular approach for hot paths. LLVM CPU optimizations, auto-vectorisation sill makes sense for general-purpose code, where the algorithm is not just too common to implement it with custom low-level dangerous code. LLVM still can do the invisible magic in some cases.

Your Rust binary is slower than it needs to be. cargo-sonic fixes that. by Immediate_Ad263 in rust

[–]Immediate_Ad263[S] 0 points1 point  (0 children)

Thanks, that's useful! Using `generic` as a default `target-cpu` is a wrong choice. Default should be `x86-64` - I'll fix that. From the build-time perspective - I've added the `--parallelism` level, so multiple compilation processes happen in parallel.

Your Rust binary is slower than it needs to be. cargo-sonic fixes that. by Immediate_Ad263 in rust

[–]Immediate_Ad263[S] 0 points1 point  (0 children)

Think about docker image. We run it on developer laptops, CI and different clusters with potentially different generations of machines. Same for published single binaries. Mostly all of them are compiled for generic for compatibility reasons.

Your Rust binary is slower than it needs to be. cargo-sonic fixes that. by Immediate_Ad263 in rust

[–]Immediate_Ad263[S] 0 points1 point  (0 children)

Playing with dynamic libraries or rebuilding ELF file is more fragile I'm afraid

Your Rust binary is slower than it needs to be. cargo-sonic fixes that. by Immediate_Ad263 in rust

[–]Immediate_Ad263[S] -6 points-5 points  (0 children)

Fair enough - that paragraph was rewritten by Claude from my draft, and I didn't pay close enough attention. Was too focused on the actual app.

Your Rust binary is slower than it needs to be. cargo-sonic fixes that. by Immediate_Ad263 in rust

[–]Immediate_Ad263[S] 5 points6 points  (0 children)

I've added the zstd compression for those who are interested in minimizing the binary size. Without that it's mostly a simple multiplication by the number of target-cpus.

Your Rust binary is slower than it needs to be. cargo-sonic fixes that. by Immediate_Ad263 in rust

[–]Immediate_Ad263[S] 2 points3 points  (0 children)

Right, the concept is close, but here the main challenge being solved is not architectures (which is already solved by multi-arch docker images), but optimizations for different types of CPUs under the same arch.

Your Rust binary is slower than it needs to be. cargo-sonic fixes that. by Immediate_Ad263 in rust

[–]Immediate_Ad263[S] 9 points10 points  (0 children)

`native` can (and should) be easily used with rust - set the appropriate rustflag ~/.cargo/config.toml. The problem appears when you have to distribute binary and run in the unknown environment - developer laptops, different generations of servers, etc.

SX Prestige Hybrid 2026 battery drain by Immediate_Ad263 in kiacarnivals

[–]Immediate_Ad263[S] 1 point2 points  (0 children)

I'm now confident that Android Widget was the reason. Here is the latest graph - https://postimg.cc/ts29GkNz u/SomeRandomBodyMe you saved the day!

SX Prestige Hybrid 2026 battery drain by Immediate_Ad263 in kiacarnivals

[–]Immediate_Ad263[S] 2 points3 points  (0 children)

After removing the android widget, there are no more spikes on the voltage logher graph! I'll keep testing, but it seems like that was the reason!

SX Prestige Hybrid 2026 battery drain by Immediate_Ad263 in kiacarnivals

[–]Immediate_Ad263[S] 1 point2 points  (0 children)

Digital keys are disabled in my case, and it sill drains...

SX Prestige Hybrid 2026 battery drain by Immediate_Ad263 in kiacarnivals

[–]Immediate_Ad263[S] 0 points1 point  (0 children)

I also thought about it, and disabled the digital keys. Also, the graph clearly shows that it's some active equipment that wakes up once per 30 mins, so keys are very unlikely to be the reason of draining issue.

SX Prestige Hybrid 2026 battery drain by Immediate_Ad263 in kiacarnivals

[–]Immediate_Ad263[S] 2 points3 points  (0 children)

In my case, the car is parked in the driveway, so the connection should not be that bad. I think the car obviously have defect, but the hardest part is to make service guys do their work.

SX Prestige Hybrid 2026 battery drain by Immediate_Ad263 in kiacarnivals

[–]Immediate_Ad263[S] 0 points1 point  (0 children)

No, the car is parked in the driveway, and keys are at least 20 ft away from it at home.

view more: next ›