NohatCoder

Decompression is fast if you do it right (using anything from the Oodle pack is a good first step towards doing it right).

Hopefully a game doesn't need to parse a whole lot of things, however stuff needs to appear in memory, it can be stored that way on disk, possibly compressed with aforementioned fast compression libraries.

There is nothing special about loading data onto the graphics card, if you know what you are doing it is just copying data, and no point on the path is slower than disk.

I know there are games that somehow rely on thousands of shaders. Like most games you can just not do that, or you can store the compiled shaders so that the compilation only needs to be done on first run.

Most applications do far more IO than what is necessary for the task.

Anyway with a modern SSD I don't think you are right. My disk can do something like 3 GB/s and 100k random accesses per second. At that rate most desktop programs should have the binary and all dependencies loaded to memory in approximately 0.1s. That seemingly doesn't stop a lot of them from taking several seconds to boot. Likewise games, despite usually consuming less than 10 GB of video and main memory combined, can take much longer than 3.3s to load.

Does anyone have the text of such an email?

It depends on the processor, but yes in some cases using floats would be faster for this reason. Please note that floats don't have "additional" precision, they have a different structure that means they can express a different set of numbers. Integers should in general always be preferred when the data you deal with is of integral nature.

Even if your CPU can do some instructions faster with floats it is generally not the kind of optimization you would want to make. You would end up making things more complicated for little practical benefit.

Funny thing by the way, integer arithmetic units are generally cheaper to make than float units, but most multiply/division heavy code is floating point, so CPU makers prioritise the floating point units.

3) That depends on what games you count and how you define lopsided. I'd say a reasonable quantification of lopsidedness is [winning score]/[games played].

By that metric Carlsen-Nepomniachtchi is fairly lopsided at 68.2%, Capablanca-Lasker is only 64.3%.

The disputed era FIDE world championship final in 2000 had Anand beating Shirov with 3.5 of 4, a whooping 87.5%. But you might no count that as it was not a traditional long 1v1 match.

So if we discount that we have to go all the way back to 1910 Lasker-Janowski, 9.5 of 11, 86.4% to find a more lopsided match.

The only other 1v1 world championship matches that have been more lopsided are:

1896-1897 Lasker-Steinitz 12.5 of 17, 73.5%.

1907 Lasker-Marshall 11.5 of 15, 76,7%.

I found a nice cheese that really helped me: Attack harvesters with a single soldier, run as soon as you get a hit in, the harvester will follow that soldier anywhere in order to try to run him over, right past all your static defenses or neatly lined up tanks for instance.

It is certainly a victory for junk legalese that you can write an illegal contract, have it ruled illegal, and still enforce it.

The logical ruling would be to force Apple to pay reparations to all the app developers that they have illegally forced to pay for the app store.

Last time OpenSSL was in the news for a bug that should generate a warning I took a cursory look at some of the code, it was stuffed with stuff that would generate similar warnings. So at that time I concluded that going through all the warnings would be a pretty big job, and that is likely why nobody did so. On the more speculative front, it might be that some maintainer is against taking whitespace patches, that would probably make anyone who tries give up pretty quickly.

I'm a bit skeptical of the claim "The code quality is excellent", if it was this would be a lone warning emitted by the compiler, and surely it would have been fixed then.

In general, almost all of it. If you haven't laid out your data to make it accessible to SIMD instructions, at best the program will get a modest speedup by using most of the instructions rearranging data to be SIMD-compatible.

By far the simplest way of making the correct data-layout is to use the intrinsics manually, so that you discover any issues that arise.

A step further is to change the program logic to better take advantage of SIMD-instructions, for instance Fabian Giesen has written a great deal on making compression code that splices the jobs in creative ways in order to utilize SIMD-instructions.

Question is, how many cores did we have to sacrifice to get AVX512? Intel moved from shipping 10 core CPUs to 8 core CPUs with AVX512. Clock speed may not go down much, but the price of that is a very high power consumption on AVX512 workloads.

As best I can tell, it would be reasonable to expect around 12 AVX2 cores operating on the same power budget as the current 8 AVX512 cores. Does the average user have enough AVX512 workloads to make that tradeoff worth it?

This may vary by region, but I believe that the original idea of the 24 hour shift is that a physician is present, but only working as necessary depending on patients. A slippery slope if the hospital is generally understaffed.

That is because the 90% is heat efficiency, this is for extracting electricity, which is much harder.

Could you provide a credible source for those 43x and 170-250x numbers?

Trying to find some numbers for CO₂ in paper production, numbers vary a lot depending on source, and I assume that they also vary a great deal between different paper products and manufacturers. In any case, this paper https://www.transitionpathwayinitiative.org/publications/49.... would suggest an average of around 0.7 tons of CO₂ per ton paper produced.

Meanwhile polyethylene might be cheaper and less energy intensive to manufacture (depending on how much of the refinery process you include), but it emits 3.14 tons of CO₂ per ton plastic when decomposed.

A paper grocery bag might need to be a bit heavier than a plastic bag to have equal utility, so in total I guess they are not wildly different.

It is quite ironic that the site is almost 4 MB, mainly because of oversized png-encoded photos. And wtf is that favicon?

So far the empirical evidence is pretty unanimous: None of the methods scale.

Sorting is one of the more favorable tasks for being specified this way, for much code there is no simpler way to verify the output than running the same or equivalent code again.

If your specification language is not Turing complete then there is simply stuff you cannot specify. Of course, just because it isn't Turing complete doesn't mean it isn't perfectly adequate for writing bugs.

"A specification that can be implemented using formal methods". That is just source code. If the specification can completely define arbitrary programs it is necessarily Turing complete on its own, and as such prone to the same type of bugs as any other program.

Nuclear fusion is a reality, it already works in bombs and the stars, and there are real reactors outputting significant energy. Will we ever see a reactor that doesn't tear itself apart in a few hours and doesn't cost at least a thousand times as much as solar panels? Who knows. But the physics foundation is sound, the missing part is "just" engineering.

Quantum computing relies on the universe being based on non-classical computation principles. We still don't know if the universe has such properties or if the quantum mechanics we observe are simply the result of a more complicated classical model, which would inherently limit the theoretical capabilities of quantum computers.

But the theoretical part aside, quantum computing is just not really evolving. When I first heard about 50+ qbit quantum computers I though it was a sign of clear progress, but I think it is just mostly moving the goal post, the requirement that you have to do some sort of computation to call the device a computer just kind of slipped away. Better freezers have of course done their part, but that just isn't going to push us anywhere near useful.

If you know the specifics of your data, maybe. But try to err on the side of simpler models, every detail you add slows your code down, and the difference after compression is often small.

For anyone who wants really good compression of data with a particular characteristic, a very useful approach is to first shrink or reformat the data based on that characteristic, then pass the result through a general purpose compressor.

For this case that might mean convert the data into deltas, then write those deltas in a byte-oriented variable length integer fashion. The general purpose compressor can then pick up most of what you have left on the table by not being super careful with the balancing of the chosen integer format, and it might find some other useful patterns in the data without you having to worry about those.

Theoretically a single compressor crafted purely for the exact characteristics of the data at hand would be able to do a better job. But in practice the skill and time required to beat the hybrid approach tends to be a showstopper.

Am I the only one to suspect that this "order" is mostly a show deal? United Airlines will do anything to seem progressive, and Boom needs some credibility in order to raise more funding.

Why put it on GitHub and a web page if you don't care about other people's use cases?

I have no problem with people writing code for themselves. But if that is what you do, please don't post on Hacker News about it.

But you could just write that generation in plain JavaScript, React is really just a syntax.

Why make a library dependent on a particular framework? Seems to just limit usefulness for no particular gain.

Not good, but at least that limit is better than the 10k DKK limit in Denmark, you basically can't even have a proper rainy day fund or own a car.

I don't see any particular reason why Jai shouldn't be usable for other stuff than games, there are no baked-in assumption about any gamey nature of programs.

Raw trilinear is shit. It only reasonably works because mipmaps sort of do what you rail against, namely taking multiple samples, and averaging them. Actual modern graphics rendering uses anisotropic filtering, using typically 4 to 16 trilinear samples, averaging the lot. The result is both more consistent and much sharper.

What is the point of WASM if JavaScript is just as fast? After reading the article I'm not left with the impression that getting good performance out of WASM is particularly easy either. WASM has most of the performance footguns from C, requires including a lot of details and gunk, like memory layout and an allocator, that the browser compiler would probably be better off doing on its own.

Yeah, that is a way to look at it. My point isn't what we call it exactly, my point is that it is a hack job that is fairly mediocre at doing what it is supposed to do.

The compiler in the browser is going to run its own optimization anyway, preoptimizing the input isn't necessarily going to help.

No, parsing the response is usually way too fast to make a difference. Generating an HTML string is also usually pretty fast. The slowness happens when you ask the browser to parse that HTML string and generate the appropriate DOM, WASM is not going to get you out of that.