AboutTheWhisles

My experience is that it is much more a matter of architecture.

This is a lock free key value store in a single file - it doesn't have the network protocol, but any threads dealing with the network IO could use it without doing anything differently.

https://github.com/LiveAsynchronousVisualizedArchitecture/si...

You might want to take a look at https://github.com/LiveAsynchronousVisualizedArchitecture/si...

It is a completely lock free key value store, though does not have eviction built in.

Its memory management is done using a free list of blocks, which is part of how it maintains lock free concurrency.

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 was already assuming that concurrency was a big part of that statement. I respect Rust's attempt to solve these issues at the language level, but my experience has led me to think that they need to be solved at the architectural level of a program.

As far as I can tell, concurrency is fundamentally about grouping data by dependencies to find chunks that can be isolated. I think that resources are more about lifetimes and ownership and that resources and data aren't the same thing. This doesn't contradict what Rust is doing, it is more about relying on the language less.

You can see what I'm talking about in this link, though I don't think it has been digestible enough yet without video or examples.

https://github.com/LiveAsynchronousVisualizedArchitecture/la...

https://github.com/LiveAsynchronousVisualizedArchitecture/la...

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.

If you really believe this, does that mean you are studying robotics?

Your post that I replied to said that no governments wanted free energy, now you are shifting the goal post to some sort of further made up hypothetical world where big governments have free energy and small governments don't.

Wouldn't that imply that less powerful governments would want unlimited energy to become less dependent on richer and more powerful governments?

It's not what you know, it's what you can prove.

Exactly - if you could copy and paste a function, having it as a full library dependency is insanity.

SQLite, which is a single 6MB .c file compiles in under a second in any compiler and under 0.01 seconds with tcc.

You can mitigate the reading from disk by memory mapping the file.

I don't think serialization is a problem either. It is possible to make data structures that always exist as a single span of memory, so that they don't have a separate serialized representation. Most data structures are better served like this anyway, since prefetching and linear memory access is a huge speedup over pointer chasing. Building a data structure out of many separate heap allocations will also slow it down.

Here is that exact workflow in modern C++

https://github.com/LiveAsynchronousVisualizedArchitecture/la...

All the IO between nodes is serialized, so an output that is already in shared memory (to be examined or visualized in other programs) can also be written to disk.

It can then be loaded as a 'constant' node and iterations can be done with hot reloading on the baked output.

They key is that you need both live/hot/automatic reloading of execution AND snapshots/replay/rewind/baking.

If you only have one or the other, you can't isolate a part of a program and iterate on it nearly as quickly.

I'm not clear which scenario you are alluding to. It the expectation figuring out only how to sparsely sample the same area or how to quickly sample the larger area so that a detailed scan can be taken after that?

How are they expecting 'faster' MRIs from this? Are they searching for a way to hone in on the important parts to take more detailed scans?

People have been already doing remittance for the last five years with cryptocurrency. It isn't too tricky to understand that someone can set up a small office in both countries, take in one currency, send cryptocurrency they already have, buy more with that currency and have the other office sell some cryptocurrency when they receive it from the first office.

This is something that does not depend on low volatility and can be done on a small scale while bypassing a large expensive service like western union.

I don't know why you suddenly turn to saying engineers don't understand marketing (although that's not the same as public relations).

Just because a project doesn't do something well doesn't mean they don't know how to value it.

You can't profitably mine bitcoin with a graphics card

You might get something out of looking at lava:

https://github.com/LiveAsynchronousVisualizedArchitecture/la...

Concurrency really comes from being able to split up data in isolated chunks that have access to all their dependencies. When you think in terms of data and not tasks, things make a lot more sense.

It really sounds like they should take a look at this:

https://github.com/LiveAsynchronousVisualizedArchitecture/si...

"One appealing aspect of LMDB is its relative ease of use from multiple processes, above and beyond its basic capabilities as yet-another-fast-key-value-store."

simdb is only lock free and thread safe. While LMDB is benchmarked at around 10k writes, this should be able to do millions of mixed reads and writes with 4 modern cores. LMDB seems to use a separate lock file to sync multiple threads/processes. The only catch here is that the keys aren't sorted, which doesn't seem to be a requirement of theirs.