Oleksandr Kulkov

Thanks for the pointers, I will go over the datasets that you shared, and get back with results here. In the meantime, could you elaborate a bit on which `__uint256_t`...

Hi @jermp I tried running build on human.k63 with `__uint128_t` for `k=63` and `m=31`, and also with `uint256_t` from calccrypto. Unfortunately, `uint256_t` usage is extremely slow (e.g., reading seems to...

Hi @jermp, I spent a bit more time investigating possible ways to use a 256-bit type. At first, I did some changes to accommodate usage of `std::bitset`, but it obviously...

Thanks for the quick response! Sure, the space result looks good. And I do hope that it is genuine and not a result of some bug in the code that...

Ok, below is the log on the "toplevel" dataset. I prepared the input the same way as described in the [README](https://github.com/jermp/sshash?tab=readme-ov-file#input-files): Bench log on the "toplevel" human DNA, k=127 ```sh...

I'm sorry, I'm still a bit confused as to what I have to do with ggcat exactly. I built ggcat, and tried using the following command: ```sh $ gzip -d...

The error actually persists even with smaller datasets: ```sh $ gzip -d se.ust.k31.fa.gz $ ggcat build -k 31 -j 8 --eulertigs se.ust.k31.fa ... Final output saved to: output.fasta.lz4 $ lz4...

I opened a new issue about this with ggcat (https://github.com/algbio/ggcat/issues/42), but maybe I'm just misuse ggcat somehow :thinking:

I think I tried out without it as well, and got the same results. But surely would be nice to verify independently.

In the meantime, [here](https://github.com/jermp/sshash/files/14230423/human.k127.bench.check.log) is the full log with `--check` and `--bench` on `k=127` file that I built with BCALM2+UST. I also built sshash in Debug mode for it, so...