Which language are you thinking of? Ideally, how would you identify split points in this language?
I suppose we've only tested this with languages that do have delimiters - Hindi, English, Spanish, and French
There are two ways to control the splitting point. First is through delimiters, and the second is by setting chunk size. If you're parsing a language where chunks can't be described by either of those params, then I suppose memchunk wouldn't work. I'd be curious to see what does work though!
There are certainly cases of Greek/Latin without any punctuation at all, typically in a historical context. Chinese & Japanese historically did not have any punctuation whatsoever.
Yes! I'm in the same boat! My guess is that there's something in the backend (image cache/storage size) that presents as a cost/logistical problem instead of as a technical one.
Is there a linux equivalent of this setup? I see some mention of RDNA support for linux distros, but it's unclear to me if this is hardware-specific (requires ConnectX or in this case Apple Thunderbolt) or is there something interesting that can be done with "vanilla 10G NIC" hardware?
Still doesn't exactly say what it is? I get that it's glyphs for printable characters, but honestly it could be a PDF, video, collection of PNGs or SVG files, an Adobe Illustrator file, a linux distribution, a web browser, or pretty much any other piece of software or data format. I presume it's a TTF or OTF font file?
Waymo's usually something like 50% more expensive than Lyft in SF, in my experience. But the drivers don't tailgate, have colds, listen to your conversation (AFAIK)...I'll generally opt for Waymo now if I have a choice. The biggest problem I have is that it's usually a longer wait due to the smaller fleet size, but if I'm planning ahead, I'll just book one for a given time, and that takes care of it.
Lyft from MV to SF is like $100 I think? It's definitely not enjoyable but for Bay Area prices it's not ruinously expensive.
You /should/ be able to save by using shared rides, but in practice when I tried the driver was so mad they just dumped me on the side of the road and I had to call and get a refund.
The new Caltrain schedule isn't half bad though, if it came twice as often on the weekends we'd be cooking.
Basalt is stronger than glass fibers (made from silica / quartz / sand), but not as strong as carbon fiber. Also, its more expensive than glass, but less expensive than carbon. Generally considered eco friendly.
Interestingly where carbon fiber's failure mode is instant, failing catastrophically (like say chalk), basalt will be more gradual (like say wood), in some use cases that's an advantage.
Overall though its still not mass produced, uncertain if it will ever reach scale.
If interested in fibers and composites, the YouTube channel Easy Composites is really interesting / educational. For example you can use flax fiber.
It also has one very interesting property that carbon fiber doesn't: it's not conductive. This means, for example, that you can put it in an MRI machine and get signal back. You can't do that with carbon fiber, which shields the return RF signals and gives you a dark image, but doesn't damage anything. Basalt weave composites are basically completely transparent on an MRI.
(For the same reasons, it also can be microwaved successfully. Carbon fiber can not be microwaved. Do not microwave real carbon fiber or carbon fiber composites.)
> Interestingly where carbon fiber's failure mode is instant, failing catastrophically (like say chalk), basalt will be more gradual (like say wood), in some use cases that's an advantage.
So, should we use it to make a submarine to visit the Titanic?
Price performance. If the failure mode is slow, then my sport (rowing) could love this for cheaper boat construction which is stronger than fibreglass but cheaper than carbon fibre. I imagine surfboards and kayaks could work too.
Exactly this. I make kayaks and basalt would be the perfect middle ground between FG and carbon where the boat will get dinged up in rivers. Unfortunately its nearly impossible to obtain in small quantities for a hobbyist.
In addition to what sibling posts say, basalt is certainly abundant. Per Wikipedia, 90% of volcanic rock on earth is basalt. We're not going to run out of it.
I can imagine (I have no clue about this, I just watch manufacturing videos) that this is easier to mass produce. A less refined version of this is used to make Rockwool, an insulation material similar to fiber glass. Melt the stuff, extrude it, ????, profit. https://www.youtube.com/watch?v=t6FWPTZjwLo
See uses here: https://en.wikipedia.org/wiki/Basalt_fiber
I am no material scientist, so cannot comment on actual facts why it might be better in specific cases than Kevlar, Dyneema or Carbon. But from experience there's a lot I don't know and especially in engineering there's a lot to consider when putting materials under stressful conditions that might put this in in a specific spot superior to those mentioned above.
Each material has its own issues. Kevlar is very difficult to work with (need special scissors to cut and you can't sand the finished product), Dyneema is sensitive to UV degradation. Carbon is $$$. Basalt sounds like the sweet spot for some of my applications but afaict it can't be purchased by the yard like most materials so is essentially unobtainium to a hobbyist who can't afford a $1k or so roll of material.
"I don't see why" has never been the bar for scientific advancement, fortunately. "Someone is curious" is sufficient, and "Someone involved sees potential" provides funding.
Seriously, how much else of the world's technology would you summarily do away with, because you simply don't see the point?
The ultimate "out of sight out of mind" solution to a problem?
I'm surprised that Google has drunken the "Datacenters IN SPACE!!!1!!" kool-aid. Honestly I expected more.
It's so easy to poke a hole in these systems that it's comical. Answer just one question: How/why is this better than an enormous solar-powered datacenter in someplace like the middle of the Mojave Desert?
From the post they claim 8 times more solar energy and no need for batteries because they are continuously in the sun. Presumably at some scale and some cost/kg to orbit this starts to pencil out?
If it can be all mostly solid-state, then it's low-maintenace. Also design it to burn up before MTTF, like all cool space kids do these days. Not gonna be worse at Starlink unless this gets massively scaled up, which it's meant to be (ecological footprint left as an exercise to the reader).
> Fundamentally, it is, just in the form of a swarm. With added challenges!
Right, in the same sense that existing Starlink constellation is a Death Star.
This paper does not describe a giant space station. It describes a couple dozen of satellites in a formation, using gravity and optics to get extra bandwidth for inter-satellite links. The example they gave uses 81 satellites, which is a number made trivial by Starlink (it's also in the blog release itself, so no "not clicking through to the paper" excuses here!).
(In a gist, the paper seems to be describing a small constellation as useful compute unit that can be scaled, indefinitely - basically replicating the scaling design used in terrestrial ML data centers.)
> Right, in the same sense that existing Starlink constellation is a Death Star.
"The cluster radius is R=1 km, with the distance between next-nearest-neighbor satellites oscillating between ~100–200m, under the influence of Earth’s gravity."
This does not describe anything like Starlink. (Nor does Starlink do heavy onboard computation.)
> The example they gave uses 81 satellites…
Which is great if your whole datacenter fits in a few dozen racks, but that's not what Google's talking about here.
> This does not describe anything like Starlink. (Nor does Starlink do heavy onboard computation.)
Irrelevant for spacecraft dynamics or for heat management. The problem of keeping satellites from colliding or shedding the watts the craft gets from the Sun are independent of the compute that's done by the payload. It's like, the basic tenet of digital computing.
> Which is great if your whole datacenter fits in a few dozen racks, but that's not what Google's talking about here.
Data center is made of multiplies of some compute units. This paper is describing a single compute unit that makes sense for machine learning work.
> The problem of keeping satellites from colliding or shedding the watts the craft gets from the Sun are independent of the compute that's done by the payload.
The more compute you do, the more heat you generate.
> Data center is made of multiplies of some compute units.
And, thus, we wind up at the "how do we cool and maintain a giant space station?" again. With the added bonus of needing to do a spacewalk if you need to work on more than one rack.
> The more compute you do, the more heat you generate.
Yes, and yet I still fail to see the point you're making here.
Max power in space is either "we have x kWt of RTG, therefore our radiators are y m^2" or "we have x m^2 of nearly-black PV, therefore our radiators are y m^2".
Even for cases where the thermal equilibrium has to be human-liveable like the ISS, this isn't hard to achieve. Computer systems can run hotter, and therefore have smaller radiators for the same power draw, making them easier.
> And, thus, we wind up at the "how do we cool and maintain a giant space station?" again. With the added bonus of needing to do a spacewalk if you need to work on more than one rack.
What you're doing here is like saying "cars don't work for a city because a city needs to move a million people each day, and a million-seat car will break the roads": i.e. scaling up the wrong thing.
The (potential, if it even works) scale-up here is "we went from n=1 cluster containing m=81 satellites, to n=10,000 clusters each containing m=[perhaps still 81] satellites".
I am still somewhat skeptical that this moon-shot will be cost-effective, but thermal management isn't why, Musk (or anyone else) actually getting launch costs down to a few hundred USD per kg in that timescale is the main limitation.
Think to any near-future spacecraft, or idea for spaceships cruising between Earth and the Moon or Mars, that aren't single use. What are (will be) such spacecraft? Basically data centers with some rockets glued to the floor.
It's probably not why they're interested in it, but I'd like to imagine someone with a vision for the next couple decades realized that their company already has data centers and powering them as their core competency, and all they're missing is some space experience...
I think the atmosphere absorbs something like 25% of energy. If that's correct, you get a free 33% increase in compute by putting more compute behind a solar power in LEO
And you can pretty much choose how long you want your day to be (within limits). The ISS has a sunrise every 90 minutes. A ~45 minute night is obviously much easier to bridge with batteries than the ~12 hours of night in the surface. And if you spend a bunch more fuel on getting into a better orbit you even get perpetual sunlight, again more than doubling your energy output (and thermal challenges)
I have my doubts that it's worth it with current or near future launch costs. But at least it's more realistic than putting solar arrays in orbit and beaming the power down
> How/why is this better than an enormous solar-powered datacenter in someplace like the middle of the Mojave Desert?
Night.
I mean, how good an idea this actually is depends on what energy storage costs, how much faster PV degrades in space than on the ground, launch costs, how much stuff can be up there before a Kessler cascade, if ground-based lasers get good enough to shoot down things in whatever orbit this is, etc., but "no night unless we want it" is the big potential advantage of putting PV in space.
They do mention it in the linked announcement, although not really highlighted, just as a quick mention:
> As a result, we’re very excited to share that in Ubuntu 25.10, some packages are available, on an opt-in basis, in their optimized form for the more modern x86-64-v3 architecture level
> Previous benchmarks we have run (where we rebuilt the entire archive for x86-64-v3 57) show that most packages show a slight (around 1%) performance improvement and some packages, mostly those that are somewhat numerical in nature, improve more than that.
ARM/RISC-V extensions may be another reason. If a wide-spread variant configuration exists, why not build for it? See:
- RISC-V's official extensions[1]
- ARM's JS-specific float-to-fixed[2]
