vitalyd

6 ms·

1.
by vitalyd 7y ago
It seems you’ve already made up your mind and nothing anyone says will change that :). The volatile I mentioned isn’t due to concurrency of userspace threads, but to avoid the optimizer from eliminating read/write operations. If the s
2.
by vitalyd 7y ago
Lest someone gets the wrong idea, Rust makes _mutable_ globals painful to work with; readonly is fine. As for hardware DMA’able memory, it’s true that it adds friction to work with in Rust. But C or C++ would fall into the same boat - one
3.
by vitalyd 8y ago
Sorry, that was my mistake - it has pre-write barriers for SATB but not actual read barriers. However, ZGC will have read barriers and if Shenandoah ever gets integrated into Hotspot, it has them too.
4.
by vitalyd 8y ago
G1 has read barriers for SATB marking. Whether a read barrier is used or not is a function of which GC is used so can’t really say “Hotspot doesn’t use read barriers”.
5.
by vitalyd 8y ago
No, it’s sadly true. EA may scalarize the allocation but this optimization falls apart very easily in Hotspot.
6.
by vitalyd 8y ago
.NET doesn’t have interior pointer. Any `ref` must be on the stack and that’s tracked in the stackmap. You cannot have a ref as a field.
7.
by vitalyd 9y ago
That's all true, but I think we're talking past each other a bit. My point isn't about what mechanics would be used or the type of memory order specified (that's the irrelevant part), but merely to highlight that this c
8.
by vitalyd 9y ago
Note that I didn't mention anything about it being automatic. It's merely a case of being more explicit about what may happen to the value. Sequential consistency is irrelevant to the example I gave of a single valued struct. I
9.
by vitalyd 9y ago
> Concurrency is not special here I beg to differ. Concurrency comes with its own bag of hazards, as I mentioned in my reply to burntsushi. Comparing its invariants with Vec's length invariant/HashMap's RH invariant, and
10.
by vitalyd 9y ago
Only because I've had several people ask me how Rust handles memory ordering after they've learned of Sync. Sync documentation focuses very narrowly on there being no data races against the type that implements it. There's
11.
by vitalyd 9y ago
> I guess I don't see the difference At a high and general level, yeah, it's all "unsafe". But, most conversations about unsafe don't talk about this aspect. So while what you say is true, I'm merely point
12.
by vitalyd 9y ago
I suppose my point was that auto-deriving Sync may not have been such a great idea :). I understand the rationale for it but it does open up traps for people to fall into.
13.
by vitalyd 9y ago
Yeah, I understand and what I expected to be the answer. My point is that when people talk about Sync not allowing data races, there's the asterisk attached to that statement. That footnote is that publishing code, which is completel
14.
by vitalyd 9y ago
I think it's fair to question a type being auto-derived to be Sync if only individual fields are Sync. It may lead to improper sharing of a reference to this value where threadsafety across fields is needed. That would be a bug, yes,
15.
by vitalyd 9y ago
Right, but my question isn't about T itself, but rather how it's published to another thread. The example I gave is of a plain struct with no atomics or any other synchronization types internally. A &T is auto-derived to be
16.
by vitalyd 9y ago
Ok, that's what I figured - thanks. That does bring up the question, though, whether it's correct to say that a Sync type doesn't permit data races. In the example I gave above, publishing a Sync struct incorrectly can exhib
17.
by vitalyd 9y ago
Somewhat tangential, but what ensures memory visibility in Rust? Say I allocate a struct (heap or stack), and then pass an immutable reference to a function that takes T: Sync. Assume the struct itself is Sync (e.g. bunch of integer fields
18.
by vitalyd 9y ago
> I may have misunderstood Ralf's bug. Is it really the case that MutexGuard<T> was seen as Sync if T was Send, rather that Sync? Wouldn't that be a bigger problem than just the case of MutexGuard? So T: Sync if &T: S
19.
by vitalyd 10y ago
Sure, but that space isn't just Java anymore anyway. Also, what's an (non-toy) environment where developer productivity and safety/correctness don't matter? I always find that statement bizarre when talking about product
20.
by vitalyd 10y ago
It all depends on what time scale we're talking about since "very fast" is relative. High performance native systems don't use (in any meaningful manner) naive malloc/free, so that comparison is somewhat moot. I h
21.
by vitalyd 10y ago
You should've made it explicit then that you're referring to slow HFT -- the post I was replying to drew no such distinction apart from saying the "extreme end" uses FPGAs. Obviously if young gen GC pauses aren't a
22.
by vitalyd 10y ago
Yes, Azul has a similar feature (ReadyNow). This is nontrivial because lots of optimizations depend on class load ordering and runtime profile information.
23.
by vitalyd 10y ago
Tiered JITs are meant to allow slower and more aggressive optimizations to be done on truly hot code. However, you're right in that they still cannot spend as much time or resources as an AOT compiler.
24.
by vitalyd 10y ago
Devirtualization is mostly an issue for Java since everything is virtual by default and the language doesn't have support for compile time monomorphization. While C++ code does use virtuals, it's nowhere near the amount as Java -
25.
by vitalyd 10y ago
The fantastic standard library mostly goes away because it allocates. It's possible to write Java code that doesn't allocate in steady state, but the coding style becomes terrible (e.g. overuse of primitives, mutable wrappers, ma
26.
by vitalyd 11y ago
Sometimes the right defaults depend on context unavailable to the low level library author. But irrespective of who provides the higher level API, the bottom line is that there needs to be an API that's most flexible when the flexibil
27.
by vitalyd 11y ago
I think this is a natural consequence of low-level APIs. Anything deemed worthy of being configured by caller is made into an extensible interface, whether that be through flag arguments or types. Unless some lib is very opinionated on ho
28.
by vitalyd 11y ago
Optimizers are mostly about stripping away abstraction costs of the language. If anyone is asking for more, they're disillusioned :).
29.
by vitalyd 11y ago
Yes, this is a side benefit to exceptions (or some other language's way to highlight errors and thus likely cold paths).
30.
by vitalyd 11y ago
I agree - profile and cost model are orthogonal and complementary. Former tells you what to optimize, latter dictates how to optimize it.

More ›