Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
kaba0
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
45 ms
·
721.
▲
by
kaba0
3y ago
A couple of LTS releases is 2*n years, though.
722.
▲
by
kaba0
3y ago
> statically compiled languages I don’t think it’s relevant here, the JIT compiler can do the same optimizations here. If the branch predictor can basically 100% guess correctly (which will be the case in any correct program), it should
723.
▲
by
kaba0
3y ago
Yes they have, but you can always just go a “scope” higher, and instead of doing a loop that calls out to FFI, you call out to a loop itself.
724.
▲
by
kaba0
3y ago
But more “distance” between the two might be better, like, copying some value-like objects and doing the operation on that and copying back the result is much safer, than passing pointers between the two worlds. And this change might push
725.
▲
by
kaba0
3y ago
Do we know why is that? I would assume the branch predictor is mostly happy with it, is it just the code cache increase?
726.
▲
by
kaba0
3y ago
It won’t change for many many years to come. It becomes deprecated, which just gives you a warning.
727.
▲
by
kaba0
3y ago
Where it matters, you can just write that part in a low-level language and call out to that.
728.
▲
by
kaba0
3y ago
You might accidentally write an infinite loop as well - should we not use Turing-complete languages or what? It’s not like multithreaded computing wasn’t full of footguns anyway.
729.
▲
by
kaba0
3y ago
That’s M-on-N, with N being 1. That’s basically a trivial problem in comparison.
730.
▲
by
kaba0
3y ago
Every language with sufficient concurrency and parallelism primitives are prone to dead locks/live locks and any other kind of race conditions.
731.
▲
by
kaba0
3y ago
It spawns a new carrier thread in place, up to a certain, configurable limit. But starving carrier threads will also result in effectively live locks, so that’s not a solution. So I don’t see the big fuss about it - don’t spawn a million vi
732.
▲
by
kaba0
3y ago
Concurrency plus parallelism is complicated. There is no going around that.
733.
▲
by
kaba0
3y ago
It all has the cost of a significantly lower throughput in case of Erlang. Also, this is more of a user error, than a fundamental issue.
734.
▲
by
kaba0
3y ago
The model has been extensively tested in TLA+, which can reason about all possible timing combinations, among other things.
735.
▲
by
kaba0
3y ago
> For those those that don't know what this means: Blocking network TCP IO needs a sychronized block to work = you can't use virtual threads for networking That’s not true — blocking TCP IO is not implemented as blocking unde
736.
▲
by
kaba0
3y ago
Synchronized blocks are not a problem. Synchronized blocks that later don’t unblock the thread may sometimes be.
737.
▲
by
kaba0
3y ago
That sort of what happens, there is just a configurable hard limit on how much new thread may be created that was hit by this benchmark. As mentioned in another comment: jdk.virtualThreadScheduler.maxPoolSize
738.
▲
by
kaba0
3y ago
If your program was prone to deadlock as is, and is just more easily happening with virt threads, it means that the problem is your code.
739.
▲
by
kaba0
3y ago
Haskell is definitely not like the others and your last statement would be untrue with that on the list.
740.
▲
by
kaba0
3y ago
No data races is just a very tiny subset of semantic invariants, though.
741.
▲
by
kaba0
3y ago
Instagram also has a very good/addictive algorithm, for what it’s worth. I think it is more just network effect in play here - I feel that every generation has their de facto social media platform — the “boomers” have facebook, then co
742.
▲
by
kaba0
3y ago
> However, storing data normalized can increase the work to perform queries by requiring more joins. Oftentimes, that extra work is so much you’re forced to denormalize the database to improve performance. Databases have materialized vie
743.
▲
by
kaba0
3y ago
Well, if your program domain requires X level of essential complexity, you will have to achieve that somehow. You can either let it live in someone else's code, that's already written and battle tested, or you can rewrite it you
744.
▲
by
kaba0
3y ago
I think there is some "Turing-completeness" for this category as well, that is quite trivial to achieve, though the practical usability may be negligible. One hacky equivalence I can come up with is that you have a tuple with a si
745.
▲
by
kaba0
3y ago
Do you ever get to a place where you actually have to scale it? Like, the PC from my teenager age would probably be more than fast enough for 80% of companies' data. Also, are you sure your data is actually in a correct view across all
746.
▲
by
kaba0
3y ago
I don’t think we are running out of boxes. We just try to determine the minimum requirement that we could constitute as general AI, and that bound is hard to find. It’s quite trivial to find less than minimal bounds, say, writing a novel
747.
▲
by
kaba0
3y ago
> Trained Humans are surprisingly good at these problems Are we? I don’t think we would even start working on problems with big enough `n` where the complexity actually ramps up. Like, optimally scheduling even just a couple of things wi
748.
▲
by
kaba0
3y ago
Well, you can just start an exact solver on the problem in one thread, and an approximate algorithm on another. If the former doesn’t finish in n seconds, you cancel it and use the result of the latter.
749.
▲
by
kaba0
3y ago
Why would they be inadequate? They are a very good metric that lets one instantly recognize the way the problem’s certain properties change with respect to some other factor. Does it give a complete picture for everything? No. Why would it?
750.
▲
by
kaba0
3y ago
Find My is bluetooth-based, which is fine to use on airplanes as well.
More ›