Hacker Newsnew | past | comments | ask | show | jobs | submit | imp0cat's commentslogin

This. Most cars nowadays come with the so-called "smart" alternators that vary voltage wildly depending on the current driving conditions.

One minute you might be accelerating and the onboard voltage drops as the battery supplies most of electricity. Then, as you reach the crest of a hill and start engine-braking, the car frantically tries to convert all the available kinetic energy to electricity, raising the onboard voltage to quickly charge the battery.


>This. Most cars nowadays come with the so-called "smart" alternators that vary voltage wildly depending on the current driving conditions.

Which in practice means that they do a very miserly job charging the battery and are a ton more sensitive to a battery being in less than tip top shape so you can expect your battery lifetime to go down.

But it's a "win" because they pushed the serp belt change outside of whatever interval the reviewers who calculate TCO care about and they saved .000003mph in the process.


Yes, the data can help uncover Russian spies. There is a fascinating yt document about it https://www.youtube.com/watch?v=xjo0iLssbI8 ( How I caught an Illegal Russian Spy )

Yeah, this explains a lot!

Crazy times we are living in! First all the conspiracy theories about a huge pedo-ring controlling the world's government come true and then this?!


You’re forgetting adrenochrome

All of this is actually happening, and semi-post-ironically joking about it preemptively just to hedge the "well if its happening I was joking ironically" and " of its not happening look how stupid you look"

Just makes you all look like cowardly cattle, which they also refer to us as.

But yeah, joke about it.


>huge pedo-ring controlling the world's government

Just wait until you realize these pedos are just getting blackmailed into submission and aren't controlling anything but most here probably never will because of the wrong think programming.


Ok I laughed, but god, please no.

2 things: First, you can (and should) replace your `pip install` with `uv pip install` for instant speed boost. This matters even for Docker builds.

Second, you can use uv to build and install to a separate venv in a Docker container and then, thanks to the wonders of multistage Docker builds, copy that venv to a new container and have a fully working minimal image in no time, with almost no effort.


And what did you discover on hn? Let me show you https://www.oldunreal.com/ ;)

I'm glad to have opend that link. Brought back memories.

head-shot: https://www.youtube.com/watch?v=VKgyH9k1CSM


TO me, UT is a modern game -- probably the last FPS I bought (well Elite Force which I think was based on UT)

I was more of a DN3D person. Laptop and a desktop, connected via a serial cable, great fun. Computer gaming was far more social in the 90s.


Yeah, I never got into DN3D, maybe b/c it was Windows only? I might be misremembering, but I played UT on Mac with friends by setting up AppleTalk using rj11 adapters. My now-spouse called it the game before the game and it was perhaps more social than the actual game.

I wanted to agree, but this story is really good.

The funny thing is that the toothbrush would actually come in handy for cleaning stuff other than teeth.

For example, the inner water tank of a robotic vacuum.


You really need to benchmark your workloads, ideally with the "big 3" (jemalloc, tcmalloc, mimalloc). They all have their strengths and weaknesses.

Jemalloc can usually keep the smallest memory footprint, followed by tcmalloc.

Mimalloc can really speed things up sometimes.

As usually, YMMV.


I've benchmarked them every few years, they never seem to differ by more than a few percent, and jemalloc seems to fragment and leak the least for processes running for months.

Mimalloc made the claim that they were the fastest/best when they released and that didn't hold up to real world testing, so I am not inclined to trust it now.


> Mimalloc made the claim that they were the fastest/best when they released and that didn't hold up to real world testing

That’s… ahistorical, at least so far as I remember. It wasn’t marketed as either of those; it was marketed as small/simple/consistent with an opt-in high-severity mode, and then its performance bore out as a result of the first set of target features/design goals. It was mainly pushed as easy to adopt, easy to use, easy to statically link, etc.


> It was mainly pushed as easy to adopt, easy to use, easy to statically link, etc.

That is true of basically every single malloc replacement out there, that is not a uniquely defining feature.


mimalloc definitely made claims that could not be reproduced, or at least not by me. That's why I wrote this doc five years ago. "Irreproducible malloc benchmarks" https://www.dropbox.com/scl/fi/evnn6yoornh9p6l7nq1t9/Irrepro...

Look up the numbers in other comments above. When it comes to performance, the Google's tcmalloc is unconquered.

I tried all three, multiple times, and it depends.

Using the last workload tested as an example, mimalloc just consumed memory like crazy. It was probably leaking, as it was the stock version that comes in Debian, so probably quite old.

Tcmalloc and jemalloc were neck to neck when comparing app metrics (request duration etc... was quite similar), but jemalloc consistently used only about half of RAM as opposed to tcmalloc).

Both custom allocators used way less RAM than the stock allocator though. Something like 10x (!) less. In the end the workload with jemalloc hovers somewhere around 4% of the memory limit. Not bad for one single package and an additional compile option to enable it.


If we're talking about Ubuntu, ZRAM is still a thing.

Of course. I set it up on my Void Linux and Arch Linux.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: