If you were to take 500 computers with older 1080 GPUs, you might have enough compute/ram equivalent to an H200 GPU for training such a model. Maybe take 10000.
But if those machines are spread over 10000 homes, wired with residential internet service, training a large model will not get anywhere.
You go from "data in the same HBM memory chip" at 4.8TB/s or "data in adjacent GPU" with NVlink at 1.2 TB/s down to 25 MBit/s upload speed. Accessing the next piece of data is going to be about a Million times slower.
At the same time you will heat a thousand times more, for a Million times longer.
You need to train independently and merge rarely. The problem is the merge step. Weights are too entangled, you are not going to get an improvement commensurate to the effort. Otherwise, everyone would do it. It is an open research problem.
You can switch a motor without permanent magnets to "idle mode".
I understand in Tesla dual motor configurations, the front motor is without magnets. The excitation field will be turned on when you need extra power, but at crusing speed it does not cause extra "drag".
From one teardown I've seen, they even went so far to use cheaper and less efficient IGBTs for the front drive, and more efficient SiC Mosfets for the rear motor (in the same vehicle!). If you need extra acceleration briefly, lower efficiency can be accepted.
Well.. The automatic part comes from the camera directing the settings mostly.
The lens would be motorized focus/aperture.
For motion picture cinematography, I've seen remote controlled focus anyway. I don't see why you could not have a good motor built I to the lens and remote control it. If the external motor focus is quick and precise enough, then the internal motors should be as well.
Good writeup and solid presentation of wifi timing experiments.
With his typical product-ready development and polished descriptions, I'm glad there are also some unfinished ideas in his drawer. (my imposter syndrome)
I'm already annoyed by the marketing to call it fullspectrum - this seems to promise more than demonstrated. Maybe call it "CMYK printing"? I was hoping to see them printing a photograph (either on a horizontal or on a vertical surface, unlikely to work well on a ball). I was also missing a continuous gradient - so far, only colored patches?
I'm hoping for the next innovation with mixed extrusion to reduce print times. We are lacking an automatic extrusion amount and nozzle size mixing within a "layer". Not just fine layers everywhere with mixed colors on the inside.
Goal: print the infill and inner perimeter from a larger nozzle and thick layer height. Use the fine nozzle and fancy layer-mixing only on the outside where needed. It is not going to be strict layers any more - I understand, this makes it difficult certainly. Then the Prusa printers could shine that exchange fully loaded and pre heated print heads quickly.
Until then, I'll happily wait for 2 days to get a spool of orange filament delivered.. Instead of waiting for a 20hour print job
> I'm hoping for the next innovation with mixed extrusion to reduce print times. We are lacking an automatic extrusion amount and nozzle size mixing within a "layer". Not just fine layers everywhere with mixed colors on the inside.
The INDX has extremely low waste when you switch from one tool head to another. Just a little tiny nugget.
It also supports different sized nozzles in the different heads, like the Prusa XL.
So I suspect having far more people with access to that will help push better uses for that. PrusaSlicer 3 is coming soon with lots of improvements (according to them) but we don’t know what yet. I’m hoping that’s one of em.
Calling it "marketing" is a bit over the top.
I understand what you're saying and your disappointment, but I think the issue is really a matter of unrealistic expectations.
The article is by Prusa Research and it's about a recent, novel 3D printing technique.
This is very much an area of active research and also development (not to be confused with R&D).
The "FullSpectrum" thing is the name given to the project in which the developer, ratdoux, who is presumably an individual, demonstrated the technique.
There's no Orcas in it, either.
I'm impressed by the coding skill to achieve a seamless integration and "usability".
But other than a demo "because we can" I'm confused on what this could ever be useful for. AR/VR prototyping? Virtual showroom?
Or maybe for an online presentation? Stream a video of playing Minecraft and get fancy slide transitions?
"let's go to the next slide" and "now we enter dangerous territory".. "over here I can show you how this program looks like in real life"
I would expect that this leads to cases where the game is handed over to a shell company that goes bankrupt. The shell does not have the rights to all parts of the code and can thus release only part of it in a state that is useless. Some parts might have a weird license attached and so on.
Escrow or demonstration upfront will raise the bar before releasing new games in California.
If the law requires the shell company to release the source code then they have to release it. The parent can then go and sue the shell company all they want for releasing things without license but that no longer involves the public.
The paper shows a through analysis of write amplification and slowdown/wear with large databases (800GB) on a single machine. Databases are MySQL and postgres.
As already commended, this can lead to an optimized storage table format for greater performance. Nice!
I would expect that a similar analysis can be done for sqlite, maybe with a different dataset, single write thread..
Thanks! I have not tested SQLite myself, but it would definitely be worthwhile to evaluate as well. SQLite would likely suffer from write amplification in a similar way as MySQL or PostgreSQL, since it is also a page-based DBMS with in-place updates, regardless of the single-writer design.
The degree of the resulting write amplification depends on several factors, including the fill factor, write skewness, and the write rate relative to the SSD characteristics. We discuss this in more detail in Section 10.2, “When should the DBMS care about WAF?” in the extended arXiv version.
Summary: dry contact with nearly any laboratory glove will lead to sample contamination and over estimation of microplastics.
They found one type of clean room gloves that contaminate less.
Is there any indication on how bad this really is?
Around 2000 to over 7000 false positives per mm^2 based on the type of glove. Essentially, regular lab gloves shed enough particles to swamp microplastic measurements to warrant switching to clean room gloves for this type of analysis.
It's difficult to avoid contamination, since everything (samples, containers, equipements, etc) will have been in contact with glove at least once, and good decontamination is very hard.
Let's say you want to determine the amount of microplastics in ocean water samples.
You'd create a control by creating saline solution with distilled water and sodium chloride. Then you treat both the control and your sample(s) the same way in the analysis.
Surely something should tick you off when the microplastic levels aren't much lower in your control compared to your actual sample?
They are handling both the control and the sample with gloves. Which is the same way. They are contaminating both. It's useless to argue about how contamination could have theoretically been avoided in an alternate past in hindisght. You don't realize there's a potential contaminant until you do and then you mitigate it. I'm sure they are smart enough now that they realize they are systematically introducing contaminants, they will be able to figure out how to control for it.
>They are handling both the control and the sample with gloves. Which is the same way. They are contaminating both.
That's the point. If the control also gets contaminated then they should get >0 results in the control (when basically zero was expected) and that should have raised awareness of this problem pretty much immediately.
This would have been nice if code was included, but I did not see it. It is just the statistics of the specific Kodim dataset, that was once published on a Photodisc.
Use cases for this? Maybe to validate you own statistics computation?
The Kodim dataset is pretty useless nowadays. If you build an algorithm that runs on this dataset (or the Lena image) it will be pretty bad on other images. Think of data dependent things like compression, segmentation, inpainting or such. The specific characteristics of these "small" images are unlike a cellphone Jpeg or DSLR raw.
Code is now in the repo — ‘’’pip install numpy Pillow’’’ where you can duplicate the values.
Kodim might seem outdated, but it’s still the primary benchmark cited in learned image compression research (CLIC, neural codec papers) and is referenced across hundreds of published works.
The question isn’t whether newer capture pipelines produce different data — they do — but whether the research community understands the statistical structure of the benchmark it’s been using for thirty years.
Think of data dependent things like - compression?
If you were to take 500 computers with older 1080 GPUs, you might have enough compute/ram equivalent to an H200 GPU for training such a model. Maybe take 10000.
But if those machines are spread over 10000 homes, wired with residential internet service, training a large model will not get anywhere.
You go from "data in the same HBM memory chip" at 4.8TB/s or "data in adjacent GPU" with NVlink at 1.2 TB/s down to 25 MBit/s upload speed. Accessing the next piece of data is going to be about a Million times slower. At the same time you will heat a thousand times more, for a Million times longer.
reply