for context: in rust the "translation unit" is a crate (in C++, each source file is its own translation unit). So you only get parallelism across crates when compiling in rust. When you have a single-crate project, this means that
1. you get parallelism across all your dependencies, but
2. your (final) crate is serial.
Splitting your crate can therefore get you parallelism back in step 2, which can be a (compilation) perf win. You can also get a caching benefit when there aren't changes, but even absent that you can get wins.
It can come at the cost of runtime performance though, as rust won't (by default) do things like inline across translation units iirc. You can get back some of this perf back via various tricks (for example link-time optimization).
Looks like the rust performance book has some writing on these tradeoffs. I haven't read these articles, but the table of contents on the left seems reasonable enough.
Again I haven't read that (so I'm assuming it says the following), but you can get "best of both worlds" by configuring debug builds to not do LTO (= faster compilation speed, slower runtime), and release builds to do LTO (= faster runtime, slower compilation speed). There are also variants of LTO that make various tradeoffs you could look into.
That article also links to the `cargo-wizard` subcommand of cargo
it won't auto-split crates for you (of course), but it does seem to give you some default configurations of `cargo`, one of which configures for faster compilation speed. could be an easy way to mess around with things.
Thanks, that's helpful to keep in mind. Looks like you can fiddle with organizing the project in way where you can balance 1 and 2 in a reasonable way. Right now, it's definitely the second step that's killing me where assembling the crates together takes forever.
you can try doing `cargo build --timings ...`. It will generate a report of how long each crate takes to compile etc. It sounds like you know that your final crate is the culprit, but this would let you confirm it.
If you suspect the issue is assembling all the files together (e.g. linking) you can see some advice on optimizing link speeds here
Note that there could be other causes of slow compilation of the final binary. For example, if you heavily use (especially procedural) macros, it's known to make compilation quite slow.
Grades, records, etc I would assume. Someone else pointed out that they recently acquired https://www.parchment.com/ so they may have also been able to scoop up those records too
I got 2. 1 for me and 1 for my brother. I sat with the page loaded and waiting. It opened a few minutes early and I was able to still order a 2nd about 5 minutes into sale
this sucks. I am going to be graduating soon and hopefully will land a job shortly thereafter. I would have loved to get my hands on one of the cheaper models to toy with but looks like that wont be happening :/
i think this is large part due to the horrific healthcare system we have here in the US. I have personally witnessed family struggle to get help from doctors because they don't interact with a patient's health outside of immediate action items like filling a prescription, writing a summary, charting, writing a referral, etc. They spend 0 time looking into what could actually be wrong with them outside of their immediate knowledge/guess. I would like to think this is due to the shortage of doctors we have here (self inflicted) and the high demands we place on them. It really just sucks to be told to take some med, wait 3 months, and then have to communicate for them between doctors while filling out the same form 3 times.
I don't think they fit in as a layer of abstraction, but instead are outside of it. An abstraction simplifies away the inner workings of what is being abstracted. The LLM exists outside of your code. It is not part of it, thus, it is not abstracting it away. If this were the case, a coworker would be an abstraction to code they own (you could argue this, but I think it erodes the meaning of abstraction). LLMs behave like program synthesizers rather than another layer of abstraction. They take natural language as input, and using fancy math produce a (hopefully) relevant and useful output based on that input. They can produce layers of abstraction, but are not part of a program's abstraction stack.
However, they can abstract away the need to understand implementation, similar to a coworker. They can summarize behavior, be queried for questions, etc, so you don't have to actually understand the inner workings of what is going on. This is a different form of abstraction than the typical abstraction stack of a program.
no because they dont have the same level of responsibility, care, or ability to learn. They do not fulfill the need of a beginner in the field, though they can output code. I'd argue that a junior is more than that
reply