Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
nobugs
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
5 ms
·
1.
▲
by
nobugs
8y ago
FWIW: all allocators tested are user-space allocators - and moreover, to achieve this kind of performance they MUST be user-space (as user-kernel switch with all the checks is waaaay too expensive). And as soon as we're user-space - it
2.
▲
by
nobugs
8y ago
Good point but adjusting allocators from default is a separate task - which is better to be done by fans of respective allocator. If somebody is able to adjust their-favorite-allocator so results with this-publicly-available-test become bet
3.
▲
by
nobugs
9y ago
> I mean it's only the vast majority of concurrent systems which are built on shared-memory concurrency. ...which doesn't mean they work (~="they pretend to work, but happen to fail much more often than they should").
4.
▲
by
nobugs
9y ago
> so the semantics are much closer to Rust's references. Not really; I see Rust references (enforced in compile-time) ~= OP's "naked pointers" with limitations on scope. 'soft pointer' is an alternative to l
5.
▲
by
nobugs
9y ago
I'm still speaking about reference-counted RC<T>, which inevitably suffers from memory leaks. And moreover - _any_ implementation which avoids throwing an exception, in quite a few use cases has no other choice than to resort to
6.
▲
by
nobugs
9y ago
> Rust's (safe) pointers and references don't throw exceptions on explicit use Which essentially goes at the cost of having Java-style semantic memory leaks (very generally, _any_ kind of keeping-an-object-as-long-as-at-least-o
7.
▲
by
nobugs
9y ago
FWIW: in general, simpler controllers (especially those in-order ones) tend to be much more friendly to branching (exactly because they're not out-of-order). NB: I am not arguing whether unique_ptr<> should check or not: if I wan
8.
▲
by
nobugs
9y ago
> Pointer reads must check the tag ID and throw, which is like a read barrier Usually, "read barrier" is understood as a multithreaded stuff - and OP has nothing to do with MT. In other words, no "read fence" is neces
9.
▲
by
nobugs
9y ago
To the best of my knowledge, the only compilers to exploit overflows, are GCC/Clang (and those commercial compilers I know about, explicitly said that they are NOT going to exploit signed-overflow UB, IIRC I heard it from MSVC and xlC)
10.
▲
by
nobugs
9y ago
Yep, this one. On CPPCON17, Olivier Giroux has said: "[when designing Volta,] we were literally quoting C++ standard to each other".
11.
▲
by
nobugs
9y ago
Of course. The point is that (IF there is enough interest in the idea) these rules are simple enough (in particular, they're inherently local, i.e. don't require analysis to go beyond one single function) to be enforced by a tool
12.
▲
by
nobugs
9y ago
I happen to like quite a few things from it, but... there is a Big Fat Hairy Difference(tm) between "safe" and merely "safer". Make it "guaranteed to be safe" (which will most likely require tooling) rather tha
13.
▲
by
nobugs
9y ago
> that performance is worse due to the checks. I'd argue that use cases for 'soft pointers' are about the same as that of Rust's RC<T>, which also incurs runtime costs (very briefly - there is no magic here, ne
14.
▲
by
nobugs
9y ago
Well, the point of the OP goes further than that. Two Big Questions are (a) what to do with the non-owning back references (such as backref going up the owning tree) - for this 'soft' pointers are proposed (I _hate_ shared_ptr-lik
15.
▲
by
nobugs
9y ago
> You can static_cast a void * into other kinds of pointers. Moreover, you can use static_cast for downcasts (from the parent class to child class) - without runtime costs of dynamic_cast. static_cast is not safe (it doesn't perform
16.
▲
by
nobugs
9y ago
std::unique_ptr<> won't allow you to have 'owning' reference cycles; neither 'owning' reference cycles are really necessary in real-world programs.
17.
▲
by
nobugs
9y ago
-fwrapv should fix it (no warranties of any kind, batteries not included).
18.
▲
Real-World 802.11ac Wi-Fi Testing: 7×6 Routers-X-Adapters Matrix
(ithare.com)
1 points
by
nobugs
9y ago
|
0 comments
19.
▲
by
nobugs
10y ago
FWIW: IMO, we should separate CQRS and ES. CQRS is a Good Thing(tm); for a real-world example of it in work on a not-so-shabby system processing 10B+ transactions/year - see http://ithare.com/gradual-oltp-db-development