Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In-Memory C++ Leap in Blockchain Analysis

caudena.com

Post reply on HN
Print view View original

21–30 of 72 posts

Re: In-Memory C++ Leap in Blockchain Analysis

#21

Post by IshKebab »

germandiago wrote: post #18
joshstrange wrote: post #6

Do you see crypto as anything more than scams/crime/speculation? Most people involved in crypto pretend it's the future and their business models depend on pumping up crypto. That might be the same for you all but I figure of anyone in the space, a group dedicated to tracking down where coins are moving for government agencies (I assume for scams/crime reasons) might not have the wool so pulled over their eyes.

Who says that crypto is exclusively scams? There is that of course, but not only that. I do not find Bitcoin to be a scam.

Apart from Bitcoin is there anything successful that isn't a scam? I never heard of any.

Re: In-Memory C++ Leap in Blockchain Analysis

#22

Post by dboreham »

layer8 wrote: post #12

> barebone servers You mean bare-metal servers?

barebone server is a thing fwiw: A product that comprises a motherboard installed in a case with PSU. Customer adds CPU, memory and storage devices to make a complete usable server. We typically buy servers in this way because figuring out what motherboard fits in which case is a pita, conversely buying complete servers is more expensive and potentially runs into inventory issues at the vendor. So possibly they are running bare metal servers that were also barebone.

Re: In-Memory C++ Leap in Blockchain Analysis

#24

Post by wat10000 »

kanbankaren wrote: post #20
generalenvelope wrote: post #15

Curious why you chose C++? Were there aspects of other languages/ecosystems like Rust that were lacking? Would choosing Rust be advantageous for blockchains that natively support it (like Solana)? To be clear: I don't mean to imply you should have done it any other way. I'm interested mainly in gaps in existing ecosystems and whether popular suggestions to "deprecate C++ for memory safe languages" (like one made by A…

What is wrong with C++? With POSIX semaphores, mutexes, and shared pointers, it is very rare to hit upon a memory issue in modern C++. Source: Writing code in C/C++ for 30 years.

What a terrifying statement.

Edit: to be less glib, this is like saying “our shred-o-matic is perfectly safe due to its robust and thoroughly tested off switch.” An off switch is essential but not nearly enough. It only provides acceptable safety if the operator is perfect, and people are not. You need guards and safety interlocks that ensure, for example, that the machine can’t be turned on while Bob is inside lubricating the bearings.

Mutexes and smart pointers are important constructs but they don’t provide safety. Safety isn’t the presence of safe constructs, but the absence of unsafe ones. Smart pointers don’t save you when you manage to escape a reference beyond the lifetime of the object because C++ encourages passing parameters by reference all over the place. Mutexes and semaphores don’t save you from failing to realize that some shared state can be mutated on two threads simultaneously. And none of this saves you from indexing off the end of a vector.

You can probably pick a subset of C++ that lets you write reasonably safe code. But the presence of semaphores, mutexes, and shared pointers isn’t what does it.

Source: also writing C and C++ for 30 years.

Re: In-Memory C++ Leap in Blockchain Analysis

#25

Post by caudena »

plq wrote: post #7

When implementing the lock-free stuff, was portability (across processors) a goal? If yes, did you have to deal with anything specific? Do you notice any difference in behavior of correct implementations when ran on different processors? How do you test for correctness of lock-free stuff? EDIT: Oh and did you implement from scratch? Why not use eg. the RCU implementation from folly?

We never targeted weakly-ordered architectures like ARM, only x86. We never used a wide variety of different processors. We are not developing the Linux kernel and are not into control dependencies, just relying on the fences and the memory model. There may be some CPU-dependent performance differences, like discrepancy because of NUMA or false sharing being noticeable on one processor, but not on another. RCU and hazard pointers are nothing new. For the disjoint sets we don't need them. For the forest patches and the tries we do. We are using TBB and OpenMP whenever possible and trying to keep things simple.

Re: In-Memory C++ Leap in Blockchain Analysis

#26

Post by nesarkvechnep »

kanbankaren wrote: post #20
generalenvelope wrote: post #15

Curious why you chose C++? Were there aspects of other languages/ecosystems like Rust that were lacking? Would choosing Rust be advantageous for blockchains that natively support it (like Solana)? To be clear: I don't mean to imply you should have done it any other way. I'm interested mainly in gaps in existing ecosystems and whether popular suggestions to "deprecate C++ for memory safe languages" (like one made by A…

What is wrong with C++? With POSIX semaphores, mutexes, and shared pointers, it is very rare to hit upon a memory issue in modern C++. Source: Writing code in C/C++ for 30 years.

The worst code is usually written by someone who’s doing it for 30 years and can’t find a problem with their technology of choice.

Especially with shared pointers you can encounter pretty terrible memory issues.

Re: In-Memory C++ Leap in Blockchain Analysis

#27

Post by npalli »

generalenvelope wrote: post #15

Curious why you chose C++? Were there aspects of other languages/ecosystems like Rust that were lacking? Would choosing Rust be advantageous for blockchains that natively support it (like Solana)? To be clear: I don't mean to imply you should have done it any other way. I'm interested mainly in gaps in existing ecosystems and whether popular suggestions to "deprecate C++ for memory safe languages" (like one made by A…

Rust is the future of systems programming and will always be for the foreseeable future. The memory issue will mostly be addressed as needed, see from John Carmack yesterday[1], the C++ ecosystem advantage (a broad sense of how problems whether DS, Storage, OS, Networking, etc. have been solved) will be very hard to overcome for newer programming languages. I think it is ironic how modern C++ folks just keep chugging along releasing products while Rust folks are generally haranguing everyone about "memory safety" and generally leaving half finished projects (turns out writing Rust code is more fun than reading someone else, who would have guessed).

[1] https://x.com/ID_AA_Carmack/status/1935353905149341968

Re: In-Memory C++ Leap in Blockchain Analysis

#29

Post by CharlesW »

kanbankaren wrote: post #20
generalenvelope wrote: post #15

Curious why you chose C++? Were there aspects of other languages/ecosystems like Rust that were lacking? Would choosing Rust be advantageous for blockchains that natively support it (like Solana)? To be clear: I don't mean to imply you should have done it any other way. I'm interested mainly in gaps in existing ecosystems and whether popular suggestions to "deprecate C++ for memory safe languages" (like one made by A…

What is wrong with C++? With POSIX semaphores, mutexes, and shared pointers, it is very rare to hit upon a memory issue in modern C++. Source: Writing code in C/C++ for 30 years.

> With POSIX semaphores, mutexes, and shared pointers, it is very rare to hit upon a memory issue in modern C++.

There is a mountain of evidence (two examples follow) that this is not true. Roughly two-thirds of serious security bugs in large C++ products are still memory-safety violations.

(1) https://msrc.microsoft.com/blog/2019/07/we-need-a-safer-syst... (2) https://www.chromium.org/Home/chromium-security/memory-safet...

Re: In-Memory C++ Leap in Blockchain Analysis

#30

Post by kanbankaren »

nesarkvechnep wrote: post #26
kanbankaren wrote: post #20

Earlier quoted context omitted.

What is wrong with C++? With POSIX semaphores, mutexes, and shared pointers, it is very rare to hit upon a memory issue in modern C++. Source: Writing code in C/C++ for 30 years.

The worst code is usually written by someone who’s doing it for 30 years and can’t find a problem with their technology of choice. Especially with shared pointers you can encounter pretty terrible memory issues.

Dude, provide examples of "terrible" memory issues. Otherwise, you are just repeating the folklore which is outdated.
Post reply on HN