5 ms·
So it's better to write this sort of code in a language that's unsafe by default (e.g. C), rather than try to abuse Java. Reminds me of the code that Microsoft
by borissk 3y ago
So it's better to write this sort of code in a language that's unsafe by default (e.g. C), rather than try to abuse Java.
Reminds me of the code that Microsoft produced when they were trying to prove their new .NET Core is one of the fastest web runtimes - it was quite fast, but had nothing to do with the way C# code is written out there.
- coldpie 3y ago> So it's better to write this sort of code in a language that's unsafe by default (e.g. C), rather than try to abuse Java. I'm not necessarily disagreeing, but can you elaborate on why it's better? Using unsafe for some parts of the code doesn't throw out safety guarantees about all of the rest of the code.
- anonymoushn 3y agoIn this case it's better because C users have access to vector intrinsics that are much cheaper than the ones Java users have access to.
- pron 3y ago> Using unsafe for some parts of the code doesn't throw out safety guarantees about all of the rest of the code. That's actually hard to prove because you don't know which guarantees the unsafe code can break; being unsafe, it could potentially, say, mutate arbitrary final fields of any object in the program. So while such code doesn't necessarily break invariants, there's no easy way to tell whether and which it does. Once unsafe is used, no guarantee can be fully trusted. But the direction we're going with "integrity by default" (https://openjdk.org/jeps/8305968 https://openjdk.org/jeps/8305968) is that the application will need to acknowledge and approve the use of unsafe code by libraries, and so the author of the application could choose to more closely inspect the unsafe code and try to determine its blast radius.