Sometimes you have to optimize other people's code. Also, sometimes code behaves unexpectedly depending on the data, say over a certain size threshold. And sometimes it behaves differently on different hardware. You don't always find these things out until production.
A lot of times the performance is data dependent, like randomized data can result in poor warp utilization where as sorted data can be much more efficient because you have less warps sitting around idle. We have an upcoming blog post on decompression kernels that show this clearly, stay tuned!
I was skimming the paper and came to this:
> This transformation is like an AND gate - it ignores the index qubit and places the flag qubit in the state |1> if and only if either of the original components had the state |1> for the flag qubit.
Shouldn't that be an OR gate? Not only does the description above say "if and only if either of the original components had the state |1>", which is an OR, but the truth table listed above shows the same thing for the flag qubit.
Of course, one could say it's an AND on the |0> states, which is just De Morgan's law, but that's pretty awkward phrasing.
Doh! You are correct. I had been looking at a previous paper (which this new paper references). The previous paper showed that you can use any non-linearity in QM to solve NP-complete problems, and the new one shows that semi-classical gravity + QM has such a non-linearity. The earlier paper: https://arxiv.org/pdf/quant-ph/9801041
Demorgan's theorem says AND and OR are equivalent, and only depend upon the polarity of the bits. So if "state |1>" is a binary zero, AND is the proper logical operator.
Yes, I think that was implied in my original post, that if you define |0> as logical 1 then it works as an AND. It just seems confusing and unnecessary when they could have framed it to be consistent with classical logic.
There are many, many, cases like this, including correctness fixes. One recent example I remember had a shader that computed:
x = a / b * b
The optimizer was allowed, but not obligated, to transform that into:
x = a
However, in this case, b was sometimes 0. And if so, the unoptimized version computed:
x = a / 0 * 0 = Inf * 0 = NaN
So badness ensued if the that particular path didn't get optimized, which could happen under various circumstances. We had to add some code to ensure that transformation always happened on that game.
- deciding to inform the game developer & wait for reply vs not waiting for reply vs just fixing it yourself without informing the developer; and
- if informed: developer actually fixing it vs only saying they would fix it vs no reply whatsoever (not counting automated "thank you for your inquiry" replies, in cases where you don't already have more direct channels to the dev than email)
I've always kind of wondered this because in a way, it's kind of weird that it's fixed for them, at least for new releases / games actively being developed.
(Full disclosure: I'm a game developer myself, with a very high interest in engine plumbing & dev [including graphics], though finding a job for the latter is easier said than done.)
We always try to inform game devs about correctness issues, but generally we can push out a driver fix before the devs can fix things on their side, so that pretty much always happens. Many things can be fixed quickly by app profile (detecting executable name). And we have a pretty good relationship with most game devs and usually get some feedback. Of course, we don't have infinite resources, so bigger game devs get more attention to tiny ones.
I'm not sure what fraction of devs actually fix things on their side, though. Once there's a driver workaround, and we've informed the devs, it's off our plate.
Performance is more of a gray area. We contact devs if there's something we can't work around, of course. And if there's something truly breaking. But for things that aren't exactly bugs, just things that could be improved, and we can improve on our own... well, we'll probably keep that for the competitive advantage.
The article mentions that thin-walled copper tube can be used, but then says a precision lathe is required. But you can easily buy off-the-shelf copper tube with 1.6 or 2.0 mm diameter and 0.5 mm wall thickness. Is that not thin enough? If not, could one chemically thin the walls (acid, electrolysis) until it is enough?
Numerous times now, using Tesla FSD, I've found the car seemingly drifting from the center of the lane, only to have motorcycles buzz by at high speed on the opposite side. It's very polite toward motorcyclists.
Boron always seemed like an under-studied element to me. Starting from the bottom, hydrogen of course is very well understood, helium not useful for much, lithium used for many things, and beryllium interesting but unfortunately toxic. Next is boron. Low toxicity, light weight, interesting electron configuration. Compounds like boron nitride and boron carbide have remarkable properties, but seem to get less attention than carbon. Not sure why.
For many properties, boron has an intermediate behavior between carbon and silicon. For a few properties, boron resembles more phosphorus than silicon or carbon (mainly because of a closer ionic size, which makes borates somewhat intermediate between phosphates and silicates).
But both carbon and silicon are extremely cheap and abundant, many orders of magnitude more abundant than boron. Even phosphorus is several orders of magnitude more abundant than boron.
So in many cases there are carbon and/or silicon compounds (or sometimes phosphorus compounds) with properties not very different from some boron compounds. For instance in some applications where boron nitride or boron carbide would be desirable one of diamond, graphite, silicon nitride or silicon carbide may also be acceptable.
Therefore the boron compounds are typically used only when their specific benefits are so great that they overcome any cost difference over possible carbon-based or silicon-based or phosphorus-based substitutes.
In living beings (e.g. in plants), the role of boron is similar to that of phosphorus, both are used in their oxidized form, i.e. as phosphates or borates, which both have an affinity for binding to carbohydrates (like phosphate in nucleic acids) or sometimes to other alcohols (like in cellular membranes).
Some have noticed. My top example. "solidstate protein synthesis". Interest should asymptotically approach that in orgo since boron makes any cooking more fun,just like butter (garam bleng for the vegans, sorry)
Maybe not for a chemist, but as a physicist it’s certainly useful. Liquid He cooling, Bose-Einstein condensation, superfluidity, p-wave triplet pairing in He-3, etc. while being basically chemically inert!
There are a number of ways of looking at this, which others have answered, but here's another:
The kinetic and potential energy of a 1 kg mass in orbit is around 33 MJ. The chemical energy of 1 kg of methane+oxygen propellant is only about 11 MJ.
Alternately, perfectly combusted methane-oxygen propellant has an exit velocity of around 3500 m/s. But you need about 7800 m/s to get into orbit.
Chemical energy is just very weak compared to the energy of things in orbit. It's really shocking that we can do it at all.
The result of this is that your vehicle is going to be almost entirely propellant. You simply can't just build a big, beefy rocket that's, say, only half propellant, with lots of extra safety margin for things that go wrong. Cars and bridges and things have immense margins. Airplanes, a bit less so, but still more than rockets. Rockets live right on the edge of what's possible, and as long as we use chemical thrust it'll always be that way.
Which isn't to say that rockets won't get more reliable. The Falcon 9 has had hundreds of flights since the last failure, and it isn't as optimized as it could be. But there will be a lot more failures before we get there.
That's already how civilization works. There's no one person that knows everything about (say) modern food production, from top to bottom. If it ever stopped working (because too much knowledge was lost somehow), most people would die. And yet the system seems fairly resilient. Mostly, only local knowledge ever seems to be necessary to keep the whole thing running. Super-intelligence (or even just super-normal-intelligence) might expand the scope of what constitutes local knowledge but it will still run into limits somewhere.
> There's no one person that knows everything about (say) modern food production
True, but it is possible to assemble a team of people that does, with backup for each person. There's also teachers and written knowledge to educate new team members. That's what makes it resilient.
I think that's a very different situation from what's decribed.
Agreed, the food production analogy doesn't really work because the issue is the scale of the problem. On the one end there's the realm where you need a few specialists and a small group could potentially figure the entire thing out from scratch given a bit of time and effort. And then at the opposite extreme there's the realm where everything is built on a giant pyramid of artifacts that currently work, just keeping each individual piece running day to day requires a dedicated expert, and the combined stack took hundreds or thousands of lifetime equivalents to develop.
The idea being that once a toolchain becomes sufficiently complex if you ever have to bootstrap it again for whatever reason you won't be able to speedrun the process the way you might naively expect. I think modern chip production likely already reached this point several decades ago. As evidence I'll point out that China only recently achieved EUV and remains several nodes behind despite directing an obscene amount of resources towards the initiative.
Speaking of pyramid (shapes), this reminds me of an idea in Robert Silverberg's Majipoor series - there's a 30-mile high mountain with populated cities all the way up to the top whose weather and temperature is controlled by 8,000-year-old-tech established by the original colonizers. My memory is that nobody at the time of the series' events knows how to operate the tech - it just works.
People lump them together because of an anti-technology reputation, but I don't think most Amish would have trucked with Luddites. Amish tend to avoid actively participating in popular social movements, and oppose violence and property destruction.
However, you can assemble a team of humans who knows the whole pipeline. This trajectory lands us squarely in "The Machine Stops" of "Pump Six" territory, where assembling such a team or going back to a simpler system is impossible
Sorta. Take a look at a brick in a house. You'd need everyone from geologists to miners to kiln specialists to construction workers and engineers -- not to mention all the people required to make the tools required to make the tools. The team would likely involve well over 1000 people. So, "just assemble a team" is not quite as simple as you make it sound.
I don't think that's true in the sense meant. Sure, to reproduce a near replica of a specific brick from first principles. But not to produce something broadly functionally equivalent. You can (rather inefficiently) manufacture approximately equivalent bricks in your backyard on your own, possibly even from locally harvested material depending on where you live.
Well. Sure. If we move the goal post to “something passable and good enough” you only need a small number of people. In that sense, we are lucky that “black smithing” (as a proper trade) only ended in the last hundred years and many people continue it as a hobby. In that case, “small team of hobbyists” can likely reproduce a few bricks. But bootstrapping mass production of bricks? Unlikely.
Doesn't matter. At the end of the day, the knowledge is embodied by humans, or can be learnt again. Let it be 100, 1000 or 10000 people. At the end of the day, they are made of meat.
When you let the machines do it, and don't care about moving it towards human domain (i.e. meatspace), you're done.
The ship computers in the old game Privateer (and probably Wing Commander) had a pretty nice pixel font. Most of the characters were 3x4, but with a few niceties: descenders (j, p, q) could go below the normal outline, and wide glyphs like m/n/w were more than 3 pixels wide. Overall, pretty readable for uppercase/lowercase/numerics, and included a few "futuristic" touches.
Early versions of Unreal Engine had these animated procedural textures that would produce sparks, fire effects, etc. The odd part is that when you paused the game, the animated textures would still animate. Presumably, the game would pause its physics engine or set the timestep to 0, but the texture updater didn't pause. I suspect it was part of the core render loop and each new iteration of the texture was some sort of filtered version of the previous frame's texture. Arguably a very early version of GPU physics.
Modern games can have the same issue. Even taking a capture of the exact graphics commands and repeating them, you'll sometimes see animated physics effects like smoke and raindrops. They're doing the work on the GPU where it's not necessarily tied to any traditional physics timestep.
