You can hear the engineer in that second question. They hear a wild statistic pulled out of someone's ass and ask what is that sticking to the side?
HN user
wscott
CPU engineer at Intel Previous BitKeeper developer
That is normal on his blog. He is a brand that he has developed over many years, and he is constantly promoting that brand.
Yes, he has done a lot of good work in the past, but he has put as much effort into self-promotion and landed a series of interesting and well-paying gigs.
I can't blame him for that. It just makes me tired to watch.
The funny part is that the Tesla doesn't have a basic dumb cruise control. It only has "traffic-aware" cruise control which uses the cameras and doesn't use the new FSD code so it has lots of glitches and phantom braking and decides for itself what speed to use. My wife just wants to set the speed and have the car go that speed.
This kind of work is really valuable and much needed. There is also often a surprising amount of friction to making contributions to open source projects. This article did a good job and highlighting some of those difficulties and friction. But improvements to the official documentation is so much better than standalone blog posts to explain confusing concepts.
So, thank you Julia & Marie for persevering and making a solid contribution.
Indeed. When I entered "grandma's cookies" into the shared family instance is 'mealie' I was sure to include a copy of the "original" index card. (surely a copy) https://imgur.com/KMSuUhz
That card was has several fun comments and lots of history to my siblings who added to the crustiness of this card.
The original card I remember said to use lard or you can use margarine if you "haven't slaughtered a hog recently".
The recipe in mealie was modernized and tested more.
For reference here is the cppreference page the OP is trying to improve: https://cppreference.com/w/cpp/compiler_support.html
Personally I am not not sure the live search on this new page saves me time, but perhaps if you added the ability to only show missing features it could be useful. For example if I could pick that I am interested in c++23 and earlier and that I use gcc-14 and clang-16 it should list the features that won't work for me. That would be useful compared to trying to scan the full list.
Dataview can generate all of the data from Bases (and a whole lot more), but Bases is a lot easier to use as you can build queries in the GUI and the data comes out in nicely formatted table where you can edit the fields directly in the table rather than needing to load each data item one by one to make changes.
And still after using and making changes in the GUI the query is stored in a nicely formatted and editable YAML file.
Very small town in the midwest. The US is a big place and this is just one possible look.
The important thing to understand about why AVX512 is a big deal is not the width. AVX512 adds new instructions and new instruction encodings. They doubled the number of registers (16->32), and added mask registers that allow you to remove special cases at the end of loops when the array is not a multiple of the vector width. And there is piles for new permutation operations and integer operations that allow it to be useful in more cases.
The part Intel struggles with is that in many places if they had the 256-bit max width but all the new operations then they could build a machine that is faster than the 512-bit version. (assuming the same code was written for both vector widths) The reason is the ALUs could be faster and you could have more of them.
I was pleased to read such positive contagious excitement and someone who can still see the wonder of the American west. And excitement of trying new experiences.
On the website itself, "OS" "Included" and "Not Included" is strange. I don't see that I need "Not Included", unchecking "Included" should show you everything but instead it shows you nothing. I don't see the value of "no os included" verses a copy of Windows that I will overwrite.
So I would just have an "OS Included?" checkbox.
So, can we now write a plugin for Obsidian that syncs changes to Google Drive?
Reading the rest of the pricing page gives me the clear impression that it wasn't free initially and then changed it to free recently and the rest of the text on that page wasn't updated. If I am making donations why do I need to be reassured that I can have a refund if I don't like it?
https://www.globalenergyinstitute.org/average-electricity-re... us average: $0.18 Wyoming: < $0.09
yeah, cheap. But cold so a heat pump would still totally pay for itself.
I was immediately reminded of this Cosby standup: https://www.youtube.com/watch?v=qH_mHMgjcFY
Yeah, I know, I am not allowed to like anything Cosby anymore...
SPA?
That article gave an example of a "typical European floorplan". It did have multiple stairs they were just not normally accessible from all apartments. If you had some emergency-only provision to enter your neighbor's apartment and then bust their wall to access the apartment behind it, more than one egress would be possible. Some emergency doors where an alarm would sound perhaps? I come up with all kinds of problems with this, but that was my thoughts looking at that floorplan.
Design flaw. In IPFS every piece of data (even every chuck of large files) is globally indexable on the same namespace. You need namespaces and/or a path to restrict yourself to just the subset of peers that might actually have the data.
It would be possible to add a layer on top of IPFS to include some context with every hash lookup so the search can be more focused, but the original design just assumed it was ok to do a log2 search for every chunk.
I was confused by the comments here. Surely someone is going to post the Technology Connections video on the toaster. I see you did it indirectly. That video is great.
15min? try 50.
I always think I will watch just 10-15 and end up watching the whole thing and then wonder why learning about a crappy refrigerator was so interesting.
read cppreference.com
But the sort answer is all the other operators are automatically generated from that one if it is defined. So it makes the code simpler. And for many types <=> isn't much more complicated than the others
I was surprised to see `fmt/format.h` on that list, but I do have to admit that the objections seem reasonable. Perhaps because he(?) mentioned wanting to use -O0. Template code is almost useless without optimization. If -O0 is needed then I am surprised that all of the STL doesn't get pitched.
Ok, I was also surprised to see co-routines on the nice list, but I don't have direct experience there. I normally see complaints about them. I would like them to be good because some code is easier to express that way.
BitKeeper was able to merge that successfully by looking at the revision history and seeing that the changes involved just those lines. If one of them added a line between the two being changed then it would still be a conflict.
I spent a year looking at interesting merges (and commits fixing bad merges) in the Linux kernel and making a catalog of interesting cases before writing 'smerge' for BitKeeper.
It is impossible to make a perfect merge tool, but we can do a lot better than diff3.
The "diff3" style looks like this:
<<<<<<< HEAD
sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, s->proj);
assert(HASGRAPH(sc));
sccs_sdelta(sc, sccs_ino(sc), file);
||||||| merged common ancestors
sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, s->proj);
assert(sc->tree);
sccs_sdelta(sc, sc->tree, file);
=======
sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, p);
assert(sc->tree);
sccs_sdelta(sc, sc->tree, file);
>>>>>>> c4892343......
That contains the same information, but you have to parse it yourself and it is not nearly as fast to see what changed.However, it is faster to edit since you don't need to remove the diff markers.
The piece of BitKeeper I wish people would steal is the smerge gca conflict format. See https://www.bitkeeper.org/man/smerge.html Example:
<<<<<<< local slib.c 1.642.1.6 vs 1.645
sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, s->proj);
- assert(sc->tree);
- sccs_sdelta(sc, sc->tree, file);
+ assert(HASGRAPH(sc));
+ sccs_sdelta(sc, sccs_ino(sc), file);
<<<<<<< remote slib.c 1.642.1.6 vs 1.642.2.1
- sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, s->proj);
+ sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, p);
assert(sc->tree);
sccs_sdelta(sc, sc->tree, file);
>>>>>>>
Here we have a code conflict and rather than showing you what the file looks like on the two sides it shows you what was changed on both sides relative to the GCA. So we get two unified diffs. The local side made this edit, while on the remote side we had that edit. Then it is obvious how to resolve the conflict without losing a change.This works for the cris-cross case because that GCA is really a set of common revisions merged together.
The beauty of Starlink is while they use a cgnat for ipv4 they assign you fully routable ipv6 addresses. So Tailscale has no problem making that bridge, it just uses ipv6.
I use linuxbrew at work which uses relatively old SLES 12 machines with some odd configs. I find the nix portable solutions don't work because the kernel is too old to support the needed sandbox features. I do have a coworker who got NIX working in his account, but it was non-trivial, and still had issues.
Still, several homebrew packages need some tweaking, but that is straightforward.
There are so many complaints here about how simplistic this is and how it is nowhere near what a "good" malloc does. That's kind of the point. Let's implement the most brain-dead version of this code. This is code you can quickly understand and reason about. It gives you a baseline to understand all the improvements that are included in a "real" malloc.
It would have been nice to include a list of the types of changes that a modern malloc would make to this basic structure to make it faster or fix bugs.
[ time to re-share my Dr. Nicely story ]
Dr. Nicely caused quite a bit of excitement at Intel. I was on the p6 architecture team when he discovered the FDIV bug. Our FPU was formally verified and didn't have the same bug. To be nice to Dr Nicely we sent him a pre-release p6 development system to test with his program to demonstrate that his bug was fixed. He was working on a prime number sieve program and came back reporting that the p6 ran at 1/2 the speed of a Pentium for his code. Wow, another blackeye/firestorm caused by Dr. Nicely. He had too much of an audience for him to report to the world this new processor was slower.
So I got to spend a lot of time learning how to sieve works and what is happening. For the most part, it allocates a huge array in memory with each byte representing a number. You walk the array with a stride of known primes setting bytes and whatever is left must be prime. ie. every 3 is not prime, every 5 is not prime, every 7...
So in the steady state, you are writing a single byte to a cache line without reading anything. And every write hits a different cache line.
Now p6 had a write-allocate cache, but the Pentium would only allocate on read, so on the Pentium a write that misses the cache would become a write to memory. On the p6 that write would need to load the cache line from memory into the cache and then the line in the cache was modified. And since every line in the cache was also modified we had to flush some other cache line first to make room. So every 1-byte write would become a 32-byte write to memory followed by a 32-byte read from memory.
Normally write-allocate is a good thing, but in this case, it was a killer. We were stumped.
Then the magic observation: 99% of these writes were marking a space that was already marked. When you get up to walking by large strides most of those were already covered by one of the smaller factors.
So if you change the code from:
array[N] = 1
to: if (!array[N]) array[N] = 1
Now suddenly we are doing a read first, and after that read we skip the write so the data in the cache doesn't become modified and can be discarded in the future.
Also, the p6 was a super-scalar machine that ran multiple iterations of this loop in parallel and could have multiple reads going to memory at the same time. With that small tweak, the program got 4X faster and we went from being 1/2X the speed of a Pentium to being twice the speed. And this was at the same clock frequency. The test hardware ran 100Mhz, we released at 200Mhz and went up from there.