Trent Nelson

Re: https://github.com/citation-file-format/citation-file-format#references-optional

It has occurred two more times, both on HP Z620 machines, always running the Jenkins algorithm. On tn11: ``` c:\src\perfecthash-keys>echo Started Wed 02/26/2020 15:27:45.84 Started Wed 02/26/2020 15:27:45.84 c:\src\perfecthash-keys>timemem PerfectHashBulkCreate.exe...

Happened again on `tn10`: ``` c:\src\perfecthash-keys>echo Started Fri 02/28/2020 15:27:14.85 Started Fri 02/28/2020 15:27:14.85 c:\src\perfecthash-keys>timemem .\PerfectHashBulkCreate.exe c:\src\perfecthash-keys\random2.subset e:\ph\random2.Jenkins2 Chm01 Jenkins And 30 --AttemptsBeforeTableResize=100000000000 --MaxNumberOfTableResizes=0 --BestCoverageType=LowestNumberOfEmptyCacheLines --BestCoverageAttempts=1000000 --FindBestGraph --MainWorkThreadpoolPriority=Low --NoFileIo --TryLargePagesForKeysData...

(Just wanted to add a quick note saying that I'm delighted to see PyParallel included in these discussions; I think that there were some very interesting outcomes from the design...

@bdice oh interesting, didn't know that's your preferred style for cudf. Sure, I'll switch to a merge workflow going forward.

@vuule that all sounds great. I anticipated that the PR would be far more likely to spur I/O model changes like you've described, versus just getting approved and merged as-is,...

WIP/draft PR here: https://github.com/rapidsai/cudf/pull/17115

Anything other than mmap :-) Literally carrier pidgeon would probably have been preferred. And these weren't weak-sauce network links; they were 200GB NICs. In our case, we had a custom...

@vuule pushed a relatively-flushed-out implementation to the PR branch here: https://github.com/rapidsai/cudf/pull/17115.

I've posted a new PR for this work to align it a bit better with other recent changes, plus added tests etc.: https://github.com/NVIDIA/cccl/pull/4662