637 karma · joined September 12, 2022
Entirely separate, a common failure mode of dying mice is that they start generating spurious clicks. I've had a couple of logitechs do this to me. And the thing about scams is you can often legit make money off of very low success rates.
TBF, I don't think a lot of developers at the time (90's) were used to the idea of having to write MT-safe callback code. Nowadays thousands of object allocations per second is nothing to sweat over, so a framework might make a different decision to instantiate callbacks per request by default.
FWIW, I've personally owned three Teslas with zero problems, but none older than 2019. YMMV.
https://github.com/facebookincubator/cinder/blob/cinder/3.8/...
One technique I've seen is to set a goal for one optimization and, once that's met, throw the remaining resources at the other target. That feels like a bit of a cop out, though.
The magnitude matters.
- Complicated authorization systems bleed through everything else, adding exponential complexity. Maybe, as an industry, we should seek better tradeoffs? One example I can think of is preferring auditing over authorization. It's a lot easier to build a generic, unified auditing system and interface than to build sleek, fluent UIs that also have to accommodate arbitrarily complex authz behaviors.
- OTOH, I'm very keen on fine-grained controls over what data I grant third parties access to. For example, I want to be able to say, "grant this lender access to the last 18 months of account balance for this specific account" and exactly no more or less.
IMO, it destroys its competitors in the value market, and the media is being awfully silent about it. I guess it's far too easy to focus on Elon instead.
Oops, I need to correct myself!
ReentrantLock doesn't depend upon monitorEnter/Exit, but rather AbstractQueuedSynchronizer and LockSupport, which ultimately delegate to Unsafe methods like park/unpark and CAS (*compareAndSet*). Don't know why I had that confused in my head.
In any case, the point holds that "synchronized" as a language feature has mostly a zero cost for code that doesn't use it. It's a red herring when discussing modern Java concurrency.
Right. Synchronized is the key word here. The vast majority of code doesn't involve synchronized, and therefore the vast majority of objects don't have locks associated with them. That's quite important.
Those classes which do use synchronized were just going to create a ReentrantLock held for the duration of the call anyway, in which case it's all monitorEnter and monitorExit, regardless.
> This is going to put a damper on any further conversation.
Sadge.
Not true in any practical sense.
> And you end up having to trade single core performance for multi core by deciding to speculatively calculate the object.
What is the alternative you suggest? If you care about having the predicate actually hold, and you also don't want to have to hold the lock while constructing the object, then you're going to end up in an optimistic-concurrency scenario where you check the predicate under lock, compute the object, and check again before swapping the value in. You may end up having to throw your work away when you discover the predicate changed. Java is no better nor worse at doing this than anything else.
> And computeIfAbsent can end up holding the lock for too long if the function is slow.
How is this different from any other lock-holding code written anywhere?
Still there are a lot of things that can go wrong with mutexes: forgetting to unlock in the case of exceptions, priority inversion, recursive locking, deadlock, needlessly high contention, etc.
Java has had an excellent concurrency runtime with abstractions that are typically a better fit than a bare mutex for over 20 years now (c.f. Doug Lea). Synchronized still exists, because of Java's excellent backwards compatibility.
This is the author's lament. These students are skipping over personal mastery.
If you're missing deadlines, you can't both complain a) when there's no accountability and the business is going poorly, and b) when your managers are trying to hold you accountable.
Ultimately your employer has to make money to pay you for your work. Keeping this in mind is one way to help you avoid yak-shaving, bike-shedding, and other weed-entering activities.
"It was at that moment that it became obvious they deleted millions of messages using our API, leaving only 1 message in the channel. If you have been paying attention you might remember how Cassandra handles deletes using tombstones (mentioned in Eventual Consistency). When a user loaded this channel, even though there was only 1 message, Cassandra had to effectively scan millions of message tombstones (generating garbage faster than the JVM could collect it)."
And although the blog post talks about GC tuning, there's mention here [1] that they didn't do much tuning and were actually running on an old version of Cassandra (and presumably JVM) - having just switched over from CMS (!).
0) https://discord.com/blog/how-discord-stores-billions-of-messages
1) https://news.ycombinator.com/item?id=33136453However, on long road trips, autopilot definitely reduces fatigue for me far more than standard cruise. I'm hoping now that FSD is on interstates, it'll be even better. (Assuming they've fixed the issue where the new minimum speed signs in my area are being read as a speed limit).
However, it still doesn't serve a valuable purpose for me yet. I can't take my eyes off the road or my hands off the wheel. Instead, it's the opposite - I must still be hyper vigilante. In fact, it's even worse than that. Because it doesn't drive how I would, I find myself constantly intervening. E.G. I take over when I know there's a good spot to merge for an upcoming turn, but it's delaying the merge. You can force fsd to merge by signaling, but the navigable gaps between vehicles in heavy traffic can disappear faster than fsd will perform the merge. Then the maneuver shifts from reasonable to rude.
If I were just a passenger in the vehicle, I would probably care much less. But right now I'm the operator.
I don't know that anyone will ever train vehicles to behave how you would prefer to drive. I think the gold standard will rather be to behave as you find acceptable as a passenger.
For now, I'm appreciating the much improved summons. Having your vehicle pick you up in the rain is super nice.
> SoA requires unboxed arrays, otherwise it defeats the purpose. I may have been wrong about int[] being boxed
Yeah, that's wrong. Primitive arrays aren't "boxed". An int[] is not an Integer[], and no boxing is performed unless you ask for it. SoA is fine in Java.
> the fact that ints still auto-promote to Integer in certain circumstances
It's pretty easy to avoid boxing if you don't want it. They are separate types after all. Even so, Android lint has an inspection for it, and Intellij (presumably Android Studio too?) has an inspection you can turn on to detect it [1]. If you're running afoul of autoboxing, it's probably mostly in collections-based code and you'll want something like fastutil [2].
> It's also hilarious that Value Objects are still in preview.
Agreed, it's been a long time coming, but they've been doing a good job of releasing features that don't need deprecating five years later.
> This is false. structs in C or C++ don't have a language-imposed overhead. They may have different sizes depending on the alignment requirements of the platform.
Sorry, I misunderstood your comment. You were talking about different overheads on different platforms, and I read that as general overhead. (For example, if you run the exact same x86_64 binary on an Intel and AMD processor from the same generation, you can get drastically different results. Heck, you can get drastically different results within the same family from the same manufacturer for a half-dozen reasons). In any case, I wouldn't lose sleep over the varying size of object headers on different platforms. In the cases it matters, you should be avoiding them altogether.
> Also hilarious. It's 2024.
I don't know when Valhalla will land, but the Vector API is far smaller in scope. It's on its 8th incubator, and seems likely to land soon. You could give it a try.
> Checking every single array access in a tight loop, for example, is stupid.
This is a red herring in most situations. Your array accesses did get elided, you need to rewrite your code so it's easier for them to get elided, or the checks didn't have a performance impact. Also, you dev for mobile in Ada?
> No, I am talking about Java.
You must not be, because there are no exceptions used for control flow in code I write or review.
> Oh, and how does Java do low-level systems programming without unsigned integer types, lol?
It's annoying. You don't cast, you promote through a mask, e.g. val & 0xFF; That said, jOOU [3] looks interesting.
> And you better hope you don't need more than the native size, because then you get fuck-boxed into Integer
I don't understand this. You aren't using more than "native size" on any platform in any language without some sort of emulated Big* type.
> Also, you don't even have a guarantee that a variable is allocated on the stack even when the dumbest compiler can tell it's bound by function scope.
Implementations typically have both escape analysis and a nursery generation for this. This works well in a desktop/server environment. I can't speak to ART. Ultimately, Valhalla will solve this for constrained implementations.
> I love LWJGL
I'm knee-deep in GDX and LWJGL, right now, but again not in a mobile context. I used to hang out in the Java gaming forums with the folks who originated LWJGL (e.g. cas).
> This is a criticism of the language, not the library
I think your criticisms are mostly with ART. I agree there are a handful of language changes that would make things easier for ART.
1) https://www.jetbrains.com/help/inspectopedia/boxing.html#loc... 2) https://github.com/vigna/fastutil 3) https://github.com/jOOQ/jOOU
I don't understand what you're trying to say here, but clearly we disagree. To each their own.
You want project Valhalla, or more specifically Value Objects, which are in preview [0]. If you really want the highest performance related to cache accesses, you want to arrange things as SoA (struct of arrays) anyway, which has approx 0 object overhead and doesn't require Value Objects.
> Not only is the overhead bad, it's implementation-dependent, i.e. unpredictable.
This is silly. This happens with all other languages, and Java will give you better results on average. Use a different compiler or runtime for your C code, or run it on a different processor architecture, and have fun tuning your code.
> That, along with lacking SIMD
The Vector API [1] is available in preview.
> imposing stupid decisions like bounds checks on all array accesses
It's widely understood that doing the opposite has been perhaps one of the largest mistakes in the history of the industry. JITs elide access checks when safe, and it's easier for them to do with high performance code that doesn't bounce around in memory and thrash cache.
> making arrays boxed (int[] is not an array of ints, sorry)
What does this even mean? An int[] is a linear array of 32-bit int values in memory.
> or using exceptions for control flow, which is the wrong way to use exceptions
Are we now just talking about a small slice of people who write bad code?
> is a just part of the big laundry list of why Java is a piece of obsolete crap
Ah, ok. Have a fine day.
I haven't been cross shopping it with vehicles that cost 3x as much and get only 15% of the mileage, so maybe I'm missing something? But weighing 10% more and taking 20% longer to reach 60 doesn't seem particularly compelling.