Announcement

Collapse
No announcement yet.

Google Engineers Lift The Lid On Carbon - A Hopeful Successor To C++

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • coder
    replied
    Originally posted by neoe View Post
    I also not like rust lang. (Firefox itself is becoming 'outdated' compared to Vivaldi)
    You 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.

    Leave a comment:


  • Sergey Podobry
    replied
    Originally posted by coder View Post
    You 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.
    For non-atomic operations writing to a cacheline is completely asynchronous. That's why they are fast.

    Originally posted by coder View Post
    Um, 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.
    That's true. But it's still a valid option for garbage collected languages as they can deal with cycles. However all modern GCs don't use atomic reference counters.

    Leave a comment:


  • neoe
    replied
    Of course I will not use any lang from Google.
    I also not like rust lang. (Firefox itself is becoming 'outdated' compared to Vivaldi)
    However I have my own language, Textfrog in name, and I'm quit happy with it.

    Leave a comment:


  • coder
    replied
    Originally posted by Sergey Podobry View Post
    Of course there is nothing exceptional. But it requires extra inter-CPU communication (and extra latency).
    You 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.

    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 Post
    It's not good too. Otherwise all memory will be reference counted. Just use std::shared_ptr for everything and forget about memory issues.
    Um, 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.
    Last edited by coder; 26 July 2022, 05:13 PM.

    Leave a comment:


  • Sergey Podobry
    replied
    Originally posted by coder View Post
    there's nothing exceptional about asserting exclusive ownership of a cacheline
    Of course there is nothing exceptional. But it requires extra inter-CPU communication (and extra latency). And if other CPUs don't have the atomic variable in their caches I'm not sure what they do. Probably they load it into the cache and then lock the cache line.

    Originally posted by coder View Post
    That's not at all bad, but I'm sure it's also highly-dependent on a lot of factors.
    It's not good too. Otherwise all memory will be reference counted. Just use std::shared_ptr for everything and forget about memory issues.

    Leave a comment:


  • coder
    replied
    Originally posted by Sergey Podobry View Post
    At first atomics work as a memory barrier so they stop execution of the current core to flush the store buffer.
    Whether it actually stops the core is an interesting question, but I'd bet it's not true for most modern microarchitectures.

    Originally posted by Sergey Podobry View Post
    Then they lock the cache line or the whole CPU bus (depending on the architecture and address alignment)
    That's quite a bit of wiggle-room you left there. As I said, the only case where it should lock the CPU bus is for split locks, which most ISAs don't allow (except x86, unfortunately). But, those are so bad they're typically considered a bug, and wouldn't be generated by modern compilers. So, it's really a far corner case where what you originally said is true.

    Originally posted by Sergey Podobry View Post
    and 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.
    If you know anything about cache coherency protocols for copy-back caches, there's nothing exceptional about asserting exclusive ownership of a cacheline. Indeed, every time a core simply writes to a cacheline, it must assert exclusivity!

    Originally posted by Sergey Podobry View Post
    Atomics are 10-300 times slower than non-atomics plus affects other CPU cores.
    That's not at all bad, but I'm sure it's also highly-dependent on a lot of factors. If you have multiple cores contending for the same atomic counters, it's just another form of lock contention -- which is a performance pitfall in whatever form it takes. Otherwise, it should be towards the lower end of that scale.

    Originally posted by Sergey Podobry View Post
    The 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.
    Okay, so you're just redefining the operation so that allocation is considered a prerequisite rather than part of the actual insertion.

    Leave a comment:


  • Sergey Podobry
    replied
    Originally posted by arQon View Post

    Propositioning the market will likely get you either called in to HR or arrested.

    Can you maybe try a different word? Or describe the meaning you're going for it not.
    Oh, it seems the correct term is "supply and demand".

    Leave a comment:


  • Sergey Podobry
    replied
    Originally posted by coder View Post
    No, they don't. Hardware atomics only need to ensure exclusivity in the cache hierarchy of the core that's using them. Perhaps you're confusing atomics' typical case with that of split locks?



    Those perform so badly that many consider them to be a software bug, if they occur.


    I don't see how this can always hold. Or, do you mean that it's merely possible to sometimes do an allocation-free insertion? More information needed.
    At first atomics work as a memory barrier so they stop execution of the current core to flush the store buffer. Then they lock the cache line or the whole CPU bus (depending on the architecture and address alignment) and 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. Atomics are 10-300 times slower than non-atomics plus affects other CPU cores.

    The 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.

    Leave a comment:


  • arQon
    replied
    Originally posted by Sergey Podobry View Post
    Wrong. Salary depends on demand and proposition in the market.
    Propositioning the market will likely get you either called in to HR or arrested.

    Can you maybe try a different word? Or describe the meaning you're going for it not.

    Leave a comment:


  • arQon
    replied
    Originally posted by cynic View Post
    what? you can set and satisfy a time constraints regardless of the system you're running on.
    That comment is so hopelessly wrong that it took me several minutes to even understand what (I *think*) you were actually trying to say, but even if so it's still wrong, just in a more normal way.
    It doesn't help that you changed the context from what I was actually replying to, so maybe reading the post would have helped.

    > Of course there might be extreme load situation where it is not sufficient, but your question is wrong anyway.

    Two quick points: first, you mean you don't have the experience to understand the question; and second, it was rather obviously rhetorical.

    Yes, "load" - not "extreme load" or other attempts to hedge - is one of the reasons why "10ms" obviously isn't, and can't be, guaranteed, or even close to it.

    Anyway: I'm going to interpret your statement as attempting to say that what you think is that "When Go runs GC, it tries to do so in slices of not more than 10ms", right? If so, there may be some point in continuing with this. If that wasn't it then lets get out of here before wasting any more time on this.

    Leave a comment:

Working...
X