abainbridge

Here's someone who wrote a load library routines in asm and claimed they were faster.

https://old.reddit.com/r/programming/comments/dygsvm/heavyth...

I was skeptical, so I looked into his zlib implementation. It was 18% faster than gzip v1.6. The author said, "all I did was hand-compile the reference implementation, an 18% reduction in user-space time is a big advantage IMO."

I am not skeptical any more! More details of the benchmarking are in the linked thread.

Interesting. I've got a 180nm mask from a previous job. It's obviously a larger scale than the finished chip. Could be 4x. I think it is from TSCM, circa 2003, for mixed signal CMOS.

I don't think anyone else gets to say how much noise the GP saw in their test.

If you used your microscope slide as a mask to do photolithography on silicon, you'd use an optical reducer, right? So the feature size on the silicon could be ~5x smaller?

I'm not sure the terms are well defined, but here's my attempt. The BASIC implementation on a ZX Spectrum (and probably most 8-bit home computers of the 80's) was an interpreter but not a VM because it did not implement any isolation. A BASIC program could access any address on the machine and jump execution to any address. A VM, in contrast, would do bounds checking on pointer accesses and limit which syscalls were allowed. You'd expect that if two instances of a VM were run at the same time, that programs in those VMs would not be able to access each other's memory in general.

The languages are similar enough that the Zig tool-chain can translate C source into Zig source. There's mostly a one-to-one correspondence.

I thought it was cells that had a bi-lipid membrane and that viruses had a capsid instead (made of proteins).

Wikipedia says "Some viruses are enveloped, meaning that the capsid is coated with a lipid membrane" - https://en.wikipedia.org/wiki/Capsid

I find the article confusing:

1. Why does removing the lipid layer destroy the virus if most viruses don't have one in the first place?

2. How can soap be effective against "most viruses" (as the article claims) if only "some viruses" (as wikipedia claims) have a lipid layer?

3. Why doesn't TFA mention the capsid at all? I would have thought it should be on the diagram at least.

Edit: A simpler explanation that doesn't have these problems and agrees with all the facts I know is that soap destroys proteins, which is what viruses are made out of. See https://www.quora.com/How-do-detergents-denature-proteins

I can do better than assume.

"Tasting sweet food elicits insulin release prior to increasing plasma glucose levels, known as cephalic phase insulin release" https://www.jstage.jst.go.jp/article/biomedres/28/2/28_2_79/...

I always assumed that when I taste something sweet, my body starts putting insulin in my blood. Over time it learns how much to put in based on how sweet the food tasted. If that's true, I'd expect too much insulin for food with aspartame, BUT ALSO too little when food has real sugar, because of the long term learning.

I'd expect a type 1 diabetic not to see either effect because the system that aspartame wacks out of tune is turned off for them.

I appreciate that I have no actual knowledge on the subject, except that I know the body must have control loops for this stuff and they must be kept in calibration by some mechanism. Probably my model is too simple.

Yep.

Life of car tyre is ~40e3 km. 5.8g * 40e3km = 232 kg. Or 58 kg per tyre. A new tyre weighs about 8kg. I guess it might loose 3kg. So I think they've over estimated by about 20x.

I already agreed there was adaption. I just can't see how there can have been adaption for an _indoor_ life at northern latitudes. That's doubly hard, compared to a traditional life in northern latitudes, right? Although, to argue against myself, I guess if you go far enough north, people won't be getting any sunlight in the winter even if they are outdoors all the time. People there must have adapted to that. I guess by eating things with lots of vitamin D.

That seems implausible. Obviously there was evolutionary pressure on northern Europeans to tolerate lower levels of sunlight and no doubt adaption happened. However, I expect even Swedes evolved in an environment that included more time outdoors than a modern Swedish office worker gets. So, in the absence of any actual evidence, I'd still expect a problem. On top of that, there is some evidence. Basically all the papers found by this search show some evidence of vitamin D deficiency in Swedish people: https://scholar.google.com/scholar?start=10&q=sweden+vitamin...

I think the article explains that the state they needed to change was stored in flash.

He used to have interesting things to write about - subjects that he'd thought deeply about, had discussed with his peers, and could distill into valuable prose.

OK, another Godbolt link: https://godbolt.org/z/SiRvBR

This one adds functions that call the exception-based and error code based functions in a simple for loop. Both handle the error.

Unless I've screwed up somewhere, I think the result is that in the exception case, the body of the inner loop contains 13 instructions, while the error code case contains 5.

Also, the generated code for the exception case is harder to read and understand. When writing performance critical code I like to eye-ball the disassembly just to make sure the compiler didn't do anything unexpected. This task is hard enough already in non-trivial functions, I certainly don't want it getting any harder.

Nice. Like every other topic, there's more complexity if you keep looking harder.

Ooo, fancy. There is still a long way from just that to actually getting the savings in a real program running on a real operating system. For example, if I have thousands of source files, each with a few hundred bytes of cold exception handlers, do they get coalesced into a single block for the whole program?

> branches are usually superior to conditional moves for predictable conditions as they break dependency chains.

Interesting, not heard that before. Do you know of somewhere I can read about this?

It has been at least a 10% effect in the last two things I profiled, which were a simple software rasteriser and a distributed key value store. The other significant benchmarking gotchas I see are: 1) the CPU being in a sleep mode when the test starts and takes a while to get running at full speed, and 2) other stuff running on the machine causing interference. But these two are easy to work around compared to the alignment-sensitivity problem.

I think the exception code _is_ loaded. It is only a theoretical possibility that loading it could be avoided.

I just built the following code with g++ v7.4 (from MSYS64 on Windows):

    #include <math.h>
    #include <stdexcept>

    void exitWithMessageException() {
        if (random() == 4321)
            throw std::runtime_error("Halt! Who goes there?");
    }

    int main() {
        exitWithMessageException();
        return 1234;
    }

The generated code mixed the exception handlers with the hot-path code. Here are the address ranges of relevant chunks:

    100401080 - Hot path of exitWithMessageException
    100401099

    10040109a - Cold path of exitWithMessageException
    10040113f

    100401140 - Start of main

I didn't mean to disagree with the conclusion. My point was more that it is hard to be confident in the causes of results like this. It'd be great if we had tools that could randomise alignments etc, so we could take lots of samples and get more confidence. As far as I know those tools don't exist and we just have to use experience.

How does he know that the performance improvement wasn't just a side effect of altering the alignment of his code? Here's a guy getting a 48% performance improvement just by randomizing the alignment of his functions: https://youtu.be/Ho3bCIJcMcc?t=351 or slides if you prefer https://github.com/dendibakh/dendibakh.github.io/blob/master...

Check out the godbolt link I posted under desc's thread. The answer isn't that obvious. Both approaches have a conditional. The compiler/linker marks the exception handling code as cold. In theory this could go in a section of the exe that the loader never pages into RAM. (I'm getting out of my depth here).

The problem with benchmarks is that I never see any that estimate the impact of the extra code size on programs the size of, say, Photoshop. It takes annoying long to load such a program. Is code size part of that problem? Probably. Is the bloat added by exceptions significant? I'd like to know.

Here's a godbolt link: https://godbolt.org/z/Z6vYAS

Looking at the disassembly the machine code is ~2x the size for the exception versions, but most of it is on the cold path.

The exception version has a conditional branch to do the "== errorInt" part. The non-exception version manages to avoid the conditional branch by using a conditional move, which would avoid a pipeline stall on a branch mis-prediction.

Edit: I think this disproves desc's point ("If your application is slow <because of execptions> it'll show up on a profiler"). ie there's probably a small cost to exceptions even when they are not taken and it will be spread across your entire program and will not show as a single spike in a profiler.

Yeah, it would be interesting to see the overhead exceptions add when no exception is thrown.

I agree. I'd even say that burying plastic is a form of carbon sequestering and therefore has some positive impact. However, I think the problem with burying plastic is the stuff that leaches out.

See https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5373626 for example.

There's an emerging trend of service providers trying to virtualize their core network. Rakuten in Japan is a leading example.

"They have assembled a small army of suppliers to build a virtualized network built on x86 hardware. ... Rakuten has no dedicated hardware except in its antennas, ensuring the upgrade to 5G will be straightforward. ... Chief Architecture Officer Tareq Amin said the network has "virtualized everything," including radio access, core, transport, IP, billing and operational support systems."

I'm not sure who this army of suppliers is though.

The first page I looked at shows exports of the US https://oec.world/en/visualize/tree_map/hs92/export/usa/all/...

It doesn't include software, so seemingly ignores the economic activity of some of the largest companies in the US. Does anyone know what's going on there? I guess software isn't visible at customs boarder checks, so isn't included.