Re:Why is Arrays.fill 265 times slower on G1GC?
by anamexis on Friday September 04, 2026 @10:30AM
(#49565212)
I don't know if it's AI or not, but if it is, it isn't egregious, and certainly not "garbage" or disrespectful to the reader.
Re:Why is Arrays.fill 265 times slower on G1GC?
by hyperpape on Friday September 04, 2026 @11:31AM
(#49566106)
I will admit I shouldn’t have said “garbage”, because it is too emotional.
But I absolutely think it is bad for the reader, and deserves to be called out. Authors should know that it’s not good enough.
Re:Why is Arrays.fill 265 times slower on G1GC?
by xpct on Friday September 04, 2026 @10:46AM
(#49565444)
I don't think the Pangram result is shareable to others.
"If you are sure the link is correct, please make sure you are logged in with the account associated with this result."
Re:Why is Arrays.fill 265 times slower on G1GC?
by Capricorn2481 on Friday September 04, 2026 @10:52AM
(#49565536)
Even if that were AI (and I think there are better examples in the article to indicate that it is), why do you care if you just used AI anyway to summarize it anyway?
Re:Why is Arrays.fill 265 times slower on G1GC?
by hyperpape on Friday September 04, 2026 @11:00AM
(#49565650)
I don’t really care that it’s AI, the problem is that it’s bad AI writing.
The summary I shared is much more straightforward. It’s mediocre, but just barely good enough to extract the message without making me super annoyed.
> So the difference has to be in what the JIT generated, and the profiler gives us exactly that.
> That is the whole vocabulary. Let’s read some code.
> Decoding the x86 version instruction by instruction is out of scope here.
> What is not architecture specific is the logic.
Here’s a segment flagged by Pangram: https://www.pangram.com/history/87e25169-30a4-4030-a65a-dba8...