Originally posted by arQon
View Post
Announcement
Collapse
No announcement yet.
Google Engineers Lift The Lid On Carbon - A Hopeful Successor To C++
Collapse
X
-
Originally posted by Sergey Podobry View PostAt first atomics work as a memory barrier so they stop execution of the current core to flush the store buffer.
Originally posted by Sergey Podobry View PostThen they lock the cache line or the whole CPU bus (depending on the architecture and address alignment)
Originally posted by Sergey Podobry View Postand signal CPUs on other sockets. If any other core tries to access the memory address on which an atomic operation is performed (or any address in case of the CPU bus lock) it will stall its execution.
Originally posted by Sergey Podobry View PostAtomics are 10-300 times slower than non-atomics plus affects other CPU cores.
Originally posted by Sergey Podobry View PostThe trick with allocation-free list insertion is to store list pointers along with the data that will be stored in the list. So you need to allocate the data and then you can insert/remove it from the list without additional allocations.
Comment
-
Originally posted by coder View Postthere's nothing exceptional about asserting exclusive ownership of a cacheline
Originally posted by coder View PostThat's not at all bad, but I'm sure it's also highly-dependent on a lot of factors.
Comment
-
Originally posted by Sergey Podobry View PostOf course there is nothing exceptional. But it requires extra inter-CPU communication (and extra latency).
I think other ISAs have more relaxed memory models which don't make such guarantees, but a well-known performance pitfall that at least applies to x86 and some similar ISAs is called "false sharing", where two different cores fight each other for ownership of a cacheline, by writing variables in adjacent addresses.
Originally posted by Sergey Podobry View PostIt's not good too. Otherwise all memory will be reference counted. Just use std::shared_ptr for everything and forget about memory issues.
std::shared_ptr<> is awesome, but you'd better know its limitations or you'll eventually get burnt. Another reason not to blindly use it everywhere is that an object's lifetime is sometimes a matter of correctness, in which case you'd like to know if it's owned exclusively or if it has shared ownership. If ownership is never shared, then using std::unique_ptr<> (or simply making it a direct member of the parent scope) clearly communicates that it's not.Last edited by coder; 26 July 2022, 05:13 PM.
Comment
-
Originally posted by coder View PostYou edited out the parts about writing to a cacheline. Literally every time a x86 CPU core writes to a new cacheline, it needs to assert exclusive ownership of it. That's exactly how unremarkable it is.
Originally posted by coder View PostUm, no. Ref-counting has a well-known deficiency of leaking cyclic references. Weak references are one way to break such cycles, but it takes a bit of thought & explicit intent to use them properly.
std::shared_ptr<> is awesome, but you'd better know its limitations or you'll eventually get burnt. Another reason not to blindly use it everywhere is that an object's lifetime is sometimes a matter of correctness, in which case you'd like to know if it's owned exclusively or if it has shared ownership. If ownership is never shared, then using std::unique_ptr<> (or simply making it a direct member of the parent scope) clearly communicates that it's not.
Comment
-
-
Originally posted by phoronix View PostPhoronix: Google Engineers Lift The Lid On Carbon - A Hopeful Successor To C++
In addition to Dart, Golang, and being involved with other programming language initiatives over the years, their latest effort that was made public on Tuesday is Carbon. The Carbon programming language hopes to be the gradual successor to C++ and makes for an easy transition path moving forward...
https://www.phoronix.com/scan.php?pa...ccessor-To-CPP
Now I realize my assessment of Google was off-they have become legends in their own mind who would rather reinvent the wheel than contribute resources to develop/tweak Rust further to their needs as well the community's...
I am quite confident there's a perfectly valid reason in some executive at Google's mind for throwing resources at Carbon.... and heck, given Google's size, this may in fact outlast similar efforts by Shuttleworth to sustain Mir...which ironically, is now resting in Mir (peace), after Mark realized FOSS doesn't care about what he thinks.....
So, I hope this is merely a pulse/temp check of the dev community by Google....and that Carbon rather quickly fossilizes into petrified sh..I mean, carbon.. Google is healed from NIH and focuses on making Rust a premier player, a first class citizen at Google, on their ChromeOS, Android and Fuchsia platforms rather than reinvent Rust badly.
Of course, Carbon may very well be the next great thing since sliced bread...so I apologize in advance for my brainfart, if that's the case.
G'day Bruce.Last edited by MartinN; 27 July 2022, 03:45 AM.
Comment
-
Originally posted by Sergey Podobry View PostFor non-atomic operations writing to a cacheline is completely asynchronous. That's why they are fast.
There's something else we're glossing over, which are solutions like Intel's HLE. Granted, they withdrew it for security reasons, but it's a way to implement atomics without blocking the core, in the typical case. ARM also added atomic instructions to ARMv8.1, which can also potentially run without blocking.
I'm not arguing that atomics can't be costly, but it has to be seen it in terms of both how you use them and relative to the cost of memory allocation or garbage collection. If they're used judiciously, their overhead is typically a non-issue. Furthermore, the factors which make atomics more expensive will tend to cause you pain, even if you aren't using them.
Comment
-
Originally posted by coder View PostYou don't like Rust because of Firefox? Explain how its obsolescence or whatever else you don't like about it is the fault of the language.
BTW, I don't like Rust because it's verbose in grammar and concept, which seems to me is 'much pay less gain', making my programing experience crippled which is not acceptable, especially when I use the language not for job but for self innovation.
Comment
Comment