pkolaczk

52 ms·

661.
by pkolaczk 6y ago
1. Sure, but JVM has a pretty state-of-the art GC tech developed for decades, so it is fair to draw comparisons to it. And it is still not even close to non-GCed languages, in particular when we also take memory use and pauses into account,
662.
by pkolaczk 6y ago
Then how come everything is so ridiculously slow these days, despite faster computers? I've ran into situations when displaying text on the screen was lagging - and that in several different programs, on various (modern) computers. Not
663.
by pkolaczk 6y ago
The problem with GC languages is that if the requirements (or data sizes) change and you run into performance problems related to GC later (e.g unacceptable pause times or high heap usage) then it is extremely hard to get out. Often the onl
664.
by pkolaczk 6y ago
I've heard studio noise floor is typically about 15-20 dB(A), and typical quiet living room is usually more than 30 dB(A). In my previous appartement in the city I measured something in range of 45-50 dB, which was actually pretty high
665.
by pkolaczk 6y ago
GC doesn't need to pause to have a negative effect on application latency. While not-pausing is generally a huge improvement (after several decades of GC development), now what about thrashing of CPU caches?
666.
by pkolaczk 6y ago
GC and memory settings are not the only cause. There are several other factors: * JVM overhead - all these advanced optimizing compilers and GCs have non-zero footprint. They need RAM to run their code and they need RAM to perform their tas
667.
by pkolaczk 6y ago
Oh yeah, some of my foreign friends thought it was dirt on their display when they first saw my name.
668.
by pkolaczk 6y ago
My personal blog site scored only 20 and the AI said the layout was too complex, although the layout is quite minimalistic :( https://pkolaczk.github.io/
669.
by pkolaczk 6y ago
Quite debatable. Yes, there are moments when I'm getting stuck for a long time, but I'm still learning. Java was definitely simpler to learn. But on the other hand Rust makes writing convoluted code almost impossible. I don't
670.
by pkolaczk 6y ago
The openness of match/switch over a sealed hierarchy is in another dimension - you can add more switches without changing old code. This is something that interfaces don't provide.
671.
by pkolaczk 6y ago
If you're matching on a sealed type, you do get a warning.
672.
by pkolaczk 6y ago
In Scala or OCaml you get a compile-time warning + runtime error. In Java 14, Kotlin and Rust there is a compile-time error if switch/match expression is non-exhaustive.
673.
by pkolaczk 6y ago
But then you should compare a trait with no default method to a switch with no default case. And a switch with no default case would be reported as an error if some cases are not covered. Also a switch with no default case is still open to
674.
by pkolaczk 6y ago
The same applies to abstract class / trait with a default implementation. The compiler would also silently accept if after adding a new behavior you forget to update the implementations which need a customized version of that behavior.
675.
by pkolaczk 6y ago
Adding a new value and not updating the switch properly will result in a compile time error in modern languages.
676.
by pkolaczk 6y ago
Even in Java, you can always use a switch based on enums or even int constants. The only thing missing would be exhaustiveness checking, but the other claims about extensibility or readability made in the article still hold.
677.
by pkolaczk 6y ago
How would Rust, Haskell or Kotlin be different? ;)
678.
In Defense of a Switch(pkolaczk.github.io)
56 points by pkolaczk 6y ago|46 comments
679.
by pkolaczk 6y ago
Interface composition is product of types, not sum.
680.
Multiple Scoped Thread Pools in Rust(pkolaczk.github.io)
2 points by pkolaczk 6y ago|0 comments
681.
by pkolaczk 6y ago
Semantically it is atomic, because if the seq lock is implemented as a separate abstraction, the caller never observes a partially written value (no tearing). Retrying a broken read is just an implementation detail.
682.
Performance Impact of Parallel Disk Access(pkolaczk.github.io)
11 points by pkolaczk 6y ago|0 comments
683.
by pkolaczk 6y ago
This is a matter of experience. If I have a tight loop looping millions of times but I have a heap allocation inside, I can be 99% sure this would be slow, without looking at the profiler and if there is an easy way to avoid it without obfu
684.
by pkolaczk 6y ago
They don't have to involve a mutex but some kind of synchronisation. A sequential lock is another way of efficiently implementing that, without blocking the happy read path. Instead of locking the large object, it detects if a read w
685.
by pkolaczk 6y ago
Point taken. What about swap?
686.
by pkolaczk 6y ago
Finalizers (IDisposable) or try-with-resources are not equally strong as deterministic destruction in C++ or Rust. Or did you mean a different feature for deterministic destruction in C# that I don't know of? I'm quite curious.
687.
by pkolaczk 6y ago
Pinning doesn't solve the problem of cache L3+ thrashing.
688.
by pkolaczk 6y ago
Right, it is concurrent, but it is still costly. It brings rarely used data into the caches and pushes useful data out of the caches. If some parts of the heap were swapped out, the impact of concurrent scanning can be quite dramatic.
689.
by pkolaczk 6y ago
When RC drops to zero it is not STW. It is stop the current thread only. And even that can be trivially solved by background deallocation. Solving latency problem of GC is far from trivial.
690.
by pkolaczk 6y ago
It doesn't only WARN about ignoring an error, it refuses to compile. T and Result<T, E> are different types.

More ›