Without knowing more, I would expect it is a dataloader issue: your CPUs are bottlenecked trying to get enough data to your GPUs.
You can add more workers to your dataloader in order to paralyze it, though this can lead to weird parallelization bugs sometimes, so if things start acting weird, that might be a reason.
Just an fyi, llama is float 16 under the hood I believe. Stable diffusion is float32. Basically no machine learning model I’ve ever heard of is float64 based.. the only people using float64 on gpus is physicists/applied math people on doe supercomputers.
(Weirdly enough, commodity hardware is now on the opposite end: they used to struggle with float64 when people were trying to put physics models on commodity hardware, now they struggle with float16/float8 support when people are trying to put language models on commodity hardware.)
Hanging out in bed browsing Thangs on mobile.
I can get STLs, my slicer settings are pretty set and forget, I should be able to just upload an STL or a few, say “fill the plate” and go, without pulling out mg laptop.
It might be pretty lazy, but it isn’t crazy.
Do you have anything specific you want to know.
I’m working on rewriting it with all the multi-processor code removed so you can better understand the algorithm, but I’d love to know what you are trying to better understand.
Acetone is fine.
This is actually one of my pet peeves. Acetone is far from the “universal plastic solvent” that it has as a reputation…
Ultem, aka pei actually does great with acetone: https://www.astisensor.com/ultem.pdf.
I use acetone pretty regularly on my sheets and I haven’t noticed any bad effects. Usually it is best to use soap and water, acetone and isopropyl alcohol. If things won’t stick, do all three (in that order).
All ‘next’ does is call ‘next’, which is part of the spec for ‘iterator’s.
Iterables return iterators when ‘iter’ is called on them. So they don’t need to support ‘next’ natively, their corresponding iterator does that.
The value of cargo and go tools doesn’t come from the all-in-one nature of them, it comes from the official nature of them.
If something doesn’t work with cargo, it is a bug. Period. There isn’t any “it works with pip” back and forth arguing over whose fault it actually is (package? Or poetry/pipenv/pip-tools/conda/etc? This happened with pytorch a while ago, and I’m not sure if poetry and pytorch get along even now)
There also isn’t any debate over project files or configuration stuff — Pyproject.toml vs setup.cfg vs random dot files in the project directory — if you are a currently developed project you support whatever cargo supports and you move to support the latest format rather than dragging your feet for years (pyproject.toml has been the “next thing” for python since 2016! And is only finally getting widespread support now… 7 years later).
A Voron 0.1 with a 0.2 gantry and a Voron 2.4 with a 2.4r2 gantry (currently being upgraded to canbus and stealthburner).
They are different though, and the article doesn’t go into why they are different, which I think is a major omission (though a common one in articles about this subject).
The difference is that lambda functions are late binding, while partial functions are bound when they are created. This can lead to all sorts of hard to find bugs when using lambdas that are avoided by using partials.
I think part of the problem isn’t just bad hierarchies, it is that they are so hard to fix.
Bad OOP code gets its fingers everywhere, and tearing out a bad hierarchy can be downright impossible.
If this is a one off, you could try manually removing the lines of gcode for those traces. Though this would get tiresome if you wanted to do this a lot.
This isn’t an argument against the standard way of doing things, it is an argument to follow the xdg standard, and use xdg environment variables, rather than creating a new unconfigurable directory in $HOME.