<Wanda[cis]>
have managed to convert versal code to two ColId per interconnect column as well
<Wanda[cis]>
since I touched versal code, tradition dictates I should now add one more versal tile or feature to the geometry database, then get incredibly frustrated with versal again and leave it for a few months
<Wanda[cis]>
in 30 years this will result in a complete database.
<Wanda[cis]>
I really need a better machine if I want to RE Ultrascale or Versal
<Wanda[cis]>
I'm so completely RAM-limitted
<Wanda[cis]>
limitting my stuff to 2 threads to not OOM
<Wanda[cis]>
considering buying a decomissioned server with ridiculously unbalanced RAM-to-CPU ratio
mei[m] has joined #prjcombine
<mei[m]>
how much RAM does your machine have?
<Wanda[cis]>
the VM doing RE is 64GB RAM and 20 threads of Ryzen 5900
<Wanda[cis]>
(the whole machine has 128GB RAM but it's also doing a bunch of other things)
<Wanda[cis]>
actually it's not just vivado; the ISE reversing tool already has code to limit itself to 8 threads for the largest virtex7 devices
<mupuf>
ha ha
<Wanda[cis]>
oh for fuck's sake.
<Wanda[cis]>
why is my serialization format incompatible on-disk between 32-bit and 64-bit builds
<Wanda[cis]>
sigh.
<Wanda[cis]>
so. bitvec crate.
<Wanda[cis]>
BitVec has type parameters: backing store unit (u8/u16/u32/u64) and bit order.
<Wanda[cis]>
the type parameters have defaults. the default backing store follows target pointer size.
<Wanda[cis]>
further, when you use serde and serialize a bitvec, it gets serialized as an array of the backing store units.
<Wanda[cis]>
so, if you have a BitVec in a serializable structure, you get fucked over.
<Wanda[cis]>
I also particularly like how, for some reason, serializing a BitVec dumps the bit order into the serialized stream.
<Wanda[cis]>
as a string. `any::type_name::<Order>()` specifically.
<Wanda[cis]>
then it also includes the "start bit index" within the first word of the slice in the serialized stream.
<Wanda[cis]>
and length (obviously)
<Wanda[cis]>
end result is that serializing, say, a 5-bit bitvec takes a few dozen bytes
<Wanda[cis]>
prjcombine serializes a lot of 5-bit bitvecs because all bitstream enum values are stored as bitvecs, and they're all like single-digit or small-double-digit wide.
<mei[m]>
but hey, if you switch to bincode 2.0, you'll sidestep bitvec's serde implementation and get to hammer out something actually efficient
<Wanda[cis]>
I guess that answers my question from earlier today about how the fuck the raw bincode-serialized databases are larger than the same thing exported to JSON where it's all written as [false, true, true, false, ...]
<Wanda[cis]>
mei: well I could
<Wanda[cis]>
though I'm kind of pissed off enough at this bullshit that I'm seriously considering going with `Vec<bool>` out of spite
<Wanda[cis]>
gods this binary file has a lot of "bitvec::order::Lsb" in it.
<Wanda[cis]>
how do you design serialization this badly
<mupuf>
Wanda[cis]: by not caring about efficiency due to having datasets that could fit in your $L1
<Wanda[cis]>
it's not about efficiency!
<Wanda[cis]>
it's about basic fitness for purpose
<Wanda[cis]>
like. I only learned about all this because my tools blew up when compiled for wasm32 and I decided to investigate.
<_whitenotifier-4>
[prjunnamed/prjcombine] wanda-phi 6737554 - versal: convert to two `ColId`s per interconnect column.
<mupuf>
Wanda[cis]: oh, yeah. A serialization library that serializes differently depending on the cpu architecture is indeed badly broken. I mean, I guess it *can* be ok, but it should be an opt-in, not a default.
<mei[m]>
well, you see, it's not a serialization library
<mei[m]>
it's a generic data structure library that has an optional integration into a generic serialization library