Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
dbaupp
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
68 ms
·
631.
▲
by
dbaupp
10y ago
It isn't a form of blocking, and it doesn't imply that, in the conventional/widespread definitions of these terms: "Lock-freedom allows individual threads to starve but guarantees system-wide throughput" https:
632.
▲
by
dbaupp
10y ago
One thread possibly being starved is very different to all threads being starved, as can happen with blocking algorithms (the classic example being the thread holding a lock is descheduled: no-one needing it can make any progress). Atomic
633.
▲
by
dbaupp
10y ago
Obstruction-free is the weakest requirement, so your use of "even stronger" confuses me. In any case, in practice wait-free has this property a bit: getting the guarantee of all threads making progress in finite time generally req
634.
▲
by
dbaupp
10y ago
(It's worth noting that those are the standard terms for each of those concepts: https://en.wikipedia.org/wiki/Non-blocking_algorithm )
635.
▲
by
dbaupp
10y ago
> CAS is "lock free" only in the sense that it doesn't require the processor to stop the world in order to flip the mutex boolean. It's still a mutex, and it still gates access to a critical section, and you still ne
636.
▲
by
dbaupp
10y ago
Do you have examples of how this works in other languages? I would assume they have specialized data structures for this purpose.
637.
▲
by
dbaupp
10y ago
Just having custom allocators won't automatically fix the pointer issue: remapping the file later will leave the previously "allocated" pointers pointing into old memory, which may not be where the file was remapped. The allo
638.
▲
by
dbaupp
10y ago
I'd expect this to behave quite differently to cuFFT: the transforms are likely to be small (either length 8 1D FFTs, or 8x8 2D FFTs) and thus synchronisation overhead is likely to dominate if one was to try to parallelise within a tra
639.
▲
by
dbaupp
10y ago
The theory is that the "not rocket science" rule is a major reason why this is possible: http://graydon2.dreamwidth.org/1597.html .
640.
▲
by
dbaupp
10y ago
FWIW, Rust used to use split stacks, as implemented by LLVM, but they had problems like unpredictable performance (if one happened happened to be unlucky and end up repeatedly calling functions across the split boundary, each of those calls
641.
▲
by
dbaupp
10y ago
That might have been true originally, but I don't think anyone uses LLVM like a JVM/CLR-esque VM any more. As the parent states, the original Low-Level Virtual Machine initialism was even retracted, meaning the project's name
642.
▲
by
dbaupp
10y ago
> However these systems have still lots of dynamic allocations, often one or more for each point where a suspension happens. And also less need for dynamic allocations in general, since lots of state can be put on the stack instead of b
643.
▲
by
dbaupp
10y ago
Huh. By that definition Java isn't managed, which seems to be missing the point and not as nearly useful as a broad category like everyone outside the Microsoft ecosystem uses it. That said, even if "CLR" is sensibly replaced
644.
▲
by
dbaupp
10y ago
I think that is a rather common belief... "Managed" is exactly referring to automatic memory management meaning the defining feature of the category is literally GC.
645.
▲
by
dbaupp
10y ago
I don't think the use of the system linker is why Swift has SIL, nor Rust has MIR. It's true that one of the possible benefits of Rust's MIR is faster compilations, but it is fundamentally motivated by representing (and check
646.
▲
by
dbaupp
10y ago
I believe inferring sum types like that would make the inference system far more sensitive and complicated and possibly even slower. For one, it would likely mean mistakes like, say, assigning two different types to a variable may result in
647.
▲
by
dbaupp
10y ago
Calling this a "memory leak" is rather misleading. The problem is literally leaking the contents of memory, yes, but the term memory leak usually means something else, something that is usually not as problematic as dumping random
648.
▲
by
dbaupp
10y ago
Ah yes, if you truly want to get rid of bugs in your software, then not mentioning them is the best way to get there. Start acting like your code has no bugs now! The status quo doesn't change if people don't talk about, analyse a
649.
▲
by
dbaupp
10y ago
It is Black History Month in the US, as the very first paragraph of the article says.
650.
▲
Deploying Rust in a large codebase
(medium.com)
22 points
by
dbaupp
10y ago
|
0 comments
651.
▲
by
dbaupp
10y ago
I believe the contention in the WiFi case is whether CSIRO really did do the R&D actually used in WiFi, or if it just happened to get lucky with a patent. Of course, they presumably did vaguely do some sort of R&D in this space giv
652.
▲
by
dbaupp
10y ago
While the whole WiFi thing is a little weird, CSIRO is a productive research organisation, e.g. Data61 (formerly NICTA, of seL4 fame) is part of it, as are most (all?) of the large telescopes in Australia, including the ASKAP precursor to t
653.
▲
by
dbaupp
10y ago
> Say if I was writing a programme which needed to make a computation which is doable only with a quadratic algorithm. Should I not write that programme at all because it'd be a bug, albeit in most cases it'd do the processing
654.
▲
by
dbaupp
10y ago
Note that the compiler already adds "obvious" attributes to function calls, being careful to not emit them for things that contain an `UnsafeCell`. This is why that type exists, as the building block for interior mutability that t
655.
▲
by
dbaupp
10y ago
The reason I can think of are: - it'd be annoying to have to write `println!("{}", &s);`, - this is not an inconsistency one thinks about in practice: ownership is important in Rust, but the compiler does all the annoying
656.
▲
by
dbaupp
10y ago
I'm not 100% sure, but I believe LLVM doesn't have a way to understand the (im)mutability of pointers rewritten into memory, like the borrow is here.
657.
▲
by
dbaupp
10y ago
LLVM is literally designed as an production quality optimisation/code-generation backend, so it's seems perfectly reasonable for projects to rely on LLVM's optimisations without doing their own, especially when there are othe
658.
▲
by
dbaupp
10y ago
> FWIW you can use Weak for this. There's a performance cost though. The sentence before your quote mentions ref-counting. This is referring to Weak.
659.
▲
by
dbaupp
10y ago
unique_ptr is unfortunately still unsafe (in the Rust sense): there's nothing in the language stopping use-after-move of the unique_ptr value itself (which is a null-dereference and undefined behaviour), nor references to the interior
660.
▲
by
dbaupp
10y ago
> If the answer to "can I write a data-structure in Rust" is "Ya totally got this makes sense" then writing an application will be relatively easy. > However if the answer is "Wow I did it but there were a
More ›