> without doing anything hugely inefficient, such as initializing the full buffer
Is this so inefficient? If your code is very sensitive to IO throughput, then it seems preferable to re-use buffers and pay the initialization once at startup.
Some years ago, I needed a buffer like this and one didn't exist, so I wrote one: https://crates.io/crates/fixed-buffer . I like that it's a plain struct with no type parameters.
It can be. If you have large buffers (tuned for throughput) that end up fulfilling lots of small requests for whatever reason, for example. And there's always the occasional article when someone rediscovers that replacing malloc + memset with calloc can have massive performance savings thanks to zeroing by the OS only occuring on first page fault (if it ever occurs), instead of an O(N) operation on the whole buffer up front.
Which, if in the wrong loop, can quickly balloon from O(N) to O(scary).
If I'm reading that log-log plot right, that looks like a significantly worse than 100x slowdown on 1GB data sets. Avoiding init isn't the only solution, of course, but it was a solution.
> then it seems preferable to re-use buffers
Buffer reuse may be an option, but in code with complicated buffer ownership (e.g. transfering between threads, with the thread of origination not necessarily sticking around, etc.), one of the sanest methods of re-use may be to return said buffer to the allocator, or even OS.
> and pay the initialization once at startup.
Possibly a great option for long lived processes, possibly a terrible one for something you spawn via xargs.
The microwave in my apartment also has bad firmware. It beeps four times when the timer runs down and it turns off. Unfortunately, the beeping continues unnecessarily after opening the door. I believe Frigidaire (the brand) contracted a manufacturer to build the model, but they have their own people install the official firmware. Then the manufacturer produces extras, installs their own firmware, and sells them, cutting out the brand. And that's how I end up with a "Frigidaire" microwave that beeps when it shouldn't and says "GOOD" instead of "DONE". At least that's my theory.
Firmware is an important part of the appliance. An appliance with Frigidaire hardware and third-party firmware is counterfeit.
Maybe the same thing happened with your Miele appliances?
I don't believe Miele would go for selling the rebranded production extras as their own. But that beeping-after-open is common in many models and super annoying.
I love this idea and I hope I get to work on it someday. I've wanted this ever since I was a starry-eyed teenager on IRC listening to Darius Bacon explain his capability-based OS idea, aptly called "Vapor".
> I can't rewrite the world, an async runtime and web server are just too difficult and take to long for me to justify writing for a project like this (although I should eventually just for a better understanding).
I use safina+servlin and 1,000 lines of Rust to run https://www.applin.dev, on a cheap VM. It serves some static files, a simple form, receives Stripe webooks, and talks to Postgres and Postmark. It depends on some heavy crate trees: async-fs, async-net, chrono, diesel, rand (libc), serde_json, ureq, and url.
2,088,283 lines of Rust are downloaded by `cargo vendor` run in the project dir.
986,513 lines using https://github.com/coreos/cargo-vendor-filterer to try to download only Linux deps with `cargo vendor-filterer --platform=x86_64-unknown-linux-gnu`. This still downloads the `winapi` crate and other Windows crates, but they contain only 22k lines.
976,338 lines omitting development dependencies with `cargo vendor-filterer --platform=x86_64-unknown-linux-gnu --keep-dep-kinds=normal`.
754,368 lines excluding tests with `cargo vendor-filterer --platform=aarch64-apple-darwin --exclude-crate-path='*#tests' deps.filtered`.
750k lines is a lot to support a 1k-line project. I guess I could remove the heavy deps with another 200 hours of work, and might end up with some lean crates. I've been waiting for someone to write a good threaded Rust Postgres client.
I've come to accept that i wasn't really developing in "rust", but in "tokio-rust", and stopped worrying about async everywhere (it's not fundamentally different from what happens with other lang having async).
Why the need for going back to threaded development ?
1. Async Rust is extra stuff for engineers to learn and maintain in their heads.
2. Async Rust has a lot of papercuts.
3. Very little code actually needs async. For example, in an API server, every request handler will need a database connection so the concurrency is limited by the database.
I wrote the Servlin HTTP server in async rust, to handle slow clients, but it calls threaded request handlers.
In my experience, vipassana meditation also stimulates the vagus nerve and includes a kind of exposure therapy when practiced properly. It seems much safer than surgery. Also, the meditation skill can be useful later in life, helping one to be more resilient against adversity.
Learning requires making mistakes. Kids need to learn social skills in low-stakes environments. School is the best environment for this. When a person misses this part of their childhood education, they may struggle to learn these skills later in life.
It sounds like you may be speaking from experience, and if so, I respect that.
My kids have done both public schooling and now homeschooling. For a variety of personal reasons, public schooling was not going to be an option for a couple of them, so we're trying this out now and it has been successful. We are tightly integrated into a very active church group, and they have lots of social interactions on a regular basis there, as well as opportunities with other homeschooled kids around town.
It's definitely a balance, and there's no one silver bullet on either side of the fence, but the best any of us can do is actively strive for giving each child the best and most appropriate experiences for them.
The ability to recognize sociopaths and manipulation is an important life skill which may not be obtainable at your church activities or with trusted families. People without these skills may be manipulated in the workplace and suffer avoidable career setbacks, stress, and attending health problems.
The linked paper has some tables that explain why this matters: How not to Lie with Statistics: The Correct Way to Summarize Benchmark Results https://dl.acm.org/doi/pdf/10.1145/5666.5673
> Today, the Commission also found that Meta's online intermediation service Facebook Marketplace should no longer be designated under the DMA. The decision follows a request submitted by Meta on 5 March 2024 to reconsider the designation of Marketplace. Following a careful assessment of Meta's arguments and as a result of Meta's additional enforcement and continued monitoring measures to counteract the business-to-consumer use of Marketplace, the Commission found that Marketplace had less than 10,000 business users in 2024. Meta therefore no longer meets the relevant threshold giving rise to a presumption that Marketplace is an important gateway for business users to reach end users.
> We want to stress from the start that the ultimate failure of the company lies with us.
This statement discounts how much random chance contributes to success & failure. Could the world's best founding team find and build a successful business in that field? Maybe. And even if they could, is it failure to be less good than the best? Not at all.
> Stay lean until you have proven revenue.
They raised a pre-seed round and used it to search for business opportunities. This seems like the normal way of doing a startup.
> TIME AND MONEY SPENT ON NON-ESSENTIALS - These included an office, website and branding, a trip to America, contractors, and unnecessary employees.
Having an office can boost energy and productivity. Taking a trip to US to connect with new advisors, investors, and other founders seems like a pretty normal thing to do.
I think these founders are being too hard on themselves. They got an amazing education in entrepreneurship. They don't need to feel bad about it.
Is this so inefficient? If your code is very sensitive to IO throughput, then it seems preferable to re-use buffers and pay the initialization once at startup.
Some years ago, I needed a buffer like this and one didn't exist, so I wrote one: https://crates.io/crates/fixed-buffer . I like that it's a plain struct with no type parameters.
reply