AboutTheWhisles

This is completely untrue to the point of being the polar opposite of reality. Look up the attributes of ideal money.

Gold and silver are the original currencies. They are trustless because they can be verified easily and transferred physically.

The more trust a currency requires, the less valuable it becomes due to decreased fungibility and liquidity.

Those were influential and have a had a very positive effect on modern C++ without a doubt. Now that they are part of the standard though there are fewer reasons to use anything from boost, largely because it is a double edged sword of compile times and dependencies.

I'm sure there are good parts to boost. I have no idea what they are, but just by sheer quantity, something must be worth using.

Prefetching is another technique. If memory is accessed linearly, the CPU can prefetch ahead of what is currently being accessed, and that will include the TLB lookups.

I'm not sure an anecdote about about a software project failing twice and succeeding on a third try can be used as evidence the the language of the third try enabled something to be pragmatically possible. I'm sure rust helped, but I'm also very confident that I could architect even a large scale project in C++ well enough that it would remain modular and progress could remain steady.

I don't think there is anything that Rust can do technically that wasn't possible before. I think it's benefits are more about implicit organization.

Requiring trust is not a positive aspect of currencies. Gold and silver succeeded in large part because they can be verified.

The same extrapolations happen with population density. People in LA and New York think the world is overpopulated and everyone is on top of each other. They don't realize that 45 minutes north east of San Francisco there are no houses, no street lights and no cell phone reception.

No it isn't, flash was the best way to do many things for the years it was popular. Video, vector animation, simple interactivity.

Electron is only the best way to do something when someone knows only javascript and web dev but doesn't want to learn a new language. Maybe a case could be made for severe misconceptions also helping electron like 'a custom native app has to be made for each platform', even though C++ and Qt and many other combinations can be written once with 99% of the source being the same for every platform.

Not only that, but it isn't clear how many kids are in private schools, or even what the demographics are of both groups.

> True, there's always another way. But you can say same about almost any subject.

This thread was started because the article focuses on lock free programming with garbage collection when garbage collection is not any sort of fundamental factor in lock free programming.

> In my experience about lock-free (and wait-free) programming, safe and high performance deallocation of the objects is often a problem.

Concurrency bottlenecks are fundamentally about synchronization. The solution is frequently to synchronize less and that means doing more in between synchronizing. This implies allocating and deallocating more at one time.

> No. In this case it allows cheap, (mostly) unsynchronized deallocation.

There isn't anything about garbage collection that enables something that couldn't be done before. If a lock free data structure is holding other non-trivial data structures that have no notion of concurrency, you are already in a position where you have to take what you can get.

> synchronization consumes a lot of CPU cycles. Ask any C++ programmer.

I've done a large amount of lock free programming in C++ and the best scenario is lock free data structure that takes responsibility for all the data stored in it and isn't just a container of pointers is the best approach to control the amount and types of synchronization. Atomic reference counting with the last reading thread responsible for deletion is just fine as an approach.

Ultimately, having granular but heap allocated data structures in a 'lock free' container needs to come with proper expectations, since it is a poor way to scale concurrency. Granular synchronization can be fine if typical usage isn't going to see much overlap or if the whole thing won't see much use in the first place, but for concurrency to scale, larger chunks of data separated out by their dependencies needs to be used.