bremac
Joined 16 years ago
Karma
229
Submissions
47
Member since
Dec 19
Recent submissions
Comment · 1 year ago
Comment · 1 year ago
Location: San Francisco, CA
Remote: Yes
Willing to relocate: Yes
Technologies: Java, C, C++, SQL, Python, Kubernetes, Linux, perf, PostgreSQL, OCaml
Résumé/CV: http://macdonell.net/resume.pdf
Email: [email protected]
Shoot me an email if you want to chat.
No management positions, please!
Comment · 1 year ago
Unfortunately none of the hardware used for testing supports FP16 arithmetic. Between Intel and AMD, the only platform that supports AVX512-FP16 is currently Sapphire Rapids.
Comment · 2 years ago
Value types still require allocation for types larger than 128 bits if the value is either nullable or atomic — that seems like a reasonable trade-off to me.
Comment · 2 years ago
Keep in mind that you still need send a print job to the fake printer to trigger the exploit. If you send the job to your real printer, nothing happens.
Comment · 2 years ago
Per the bug report, all versions since Java 8 are affected.
Comment · 2 years ago
Unfortunately, unless the JIT can prove that the address you are accessing via the segment is non-negative, it can't elide the bounds check. See https://mail.openjdk.org/pipermail/panama-dev/2023-July/0194... for a bit more information.
Comment · 2 years ago
As the comment you replied to indicates, both of those APIs perform bounds-checking. In certain tight loops, this can add up to quite a bit of overhead [1]. However, it's not documented, but if you really know what you are doing you can convince the JIT to elide the bounds checks for MemorySegments [2].
[1] https://mail.openjdk.org/pipermail/panama-dev/2023-July/0193...
[2] https://mail.openjdk.org/pipermail/panama-dev/2023-July/0194...
Comment · 3 years ago
Reading between the lines, it sounds as if they're using mmap. There is no "append" operation on a memory mapping, so the file would need to be preallocated before mapping it.
If the preallocation is done using fallocate or just writing zeros, then by default it's backed by blocks on disk, and readahead must hit the disk since there is data there. On the other hand, preallocating with fallocate using FALLOC_FL_ZERO_RANGE or (often) with ftruncate() will just update the logical file length, and even if readahead is triggered it won't actually hit the disk.
Comment · 3 years ago
I think you may have linked to the wrong graph — while that graph does have a spike on it, the spike happens when the index was broadened in May 2020 to include savings and money market accounts.
Comment · 3 years ago
Thanks for mentioning this, I couldn't think of where I'd read about this technique before. I was remembering https://webkit.org/blog/6161/locking-in-webkit/
Comment · 3 years ago
I think that the answer here is "not easily". To use the x32 ABI, you would need:
1. Kernel support to be enabled in order to make x32 system calls. Checking /proc/config.gz on Arch Linux, my kernel does not appear to have it enabled.
2. An x32 toolchain to build against. For gcc and glibc, that would mean re-compiling as described here: https://sourceware.org/glibc/wiki/x32
3. All of the libraries you link with to be recompiled for the x32 ABI.
x86 is definitely easier to build against since there's still legacy software using it, whereas almost nobody seems to use x32. However, over the long term I expect x86 compatibility will bit-rot too.
Comment · 3 years ago
> If you allocate a chunk on the heap with 8-byte alignment, then you can throw away the lowest 3 bits of precision, and then you can address 32GB with a 32-bit pointer.
This part is totally doable, and in fact it's one of the pointer compression modes built into the JVM: https://shipilev.net/jvm/anatomy-quarks/23-compressed-refere...
For C++, it's a really interesting thought experiment, but in practice there are a few rough edges:
1. Your debugging tools will probably struggle to interpret compressed pointers.
2. You'll need to roll your own containers too. Otherwise, vectors, strings, maps, smart pointers, etc. will still use 64-bit pointers. In my experience, containers account for most pointers in a modern C++ code base.
3. _Technically_, the representation of null pointers is implementation-defined, so truncating to 32 bits and then zero-extending is not portable: it could convert a null pointer to a non-null pointer. In practice it doesn't matter though, since every modern target uses a zero bit pattern for null pointers.
Comment · 3 years ago
-m32 doesn't target the x32 ABI though, it targets x86. Per the manual:
> The -m32 option sets int, long, and pointer types to 32 bits, and generates code that runs on any i386 system.
That restricts you to the smaller register set, removes all amd64 instructions, and uses the x86 ABI (on Linux, parameters are passed on the stack instead of in registers.) I suspect that this is why your program became slower, as opposed to using 32-bit pointers.
Remote: Yes
Willing to relocate: Yes
Technologies: Java, C, C++, SQL, Python, Kubernetes, Linux, perf, PostgreSQL, OCaml
Résumé/CV: http://macdonell.net/resume.pdf
Email: [email protected]
Staff engineer with over a decade of experience leading products to successful delivery and beyond. Recently focused on high-performance streaming analytics at Sight Machine (I led the design and implementation of their stream processing engine, and before that, their data acquisition product), I can also work as a generalist backend developer or team lead.
Shoot me an email if you want to chat!