Activity for Sanmayce
-
Sanmayce created ticket #394
Command line options for MAX compression
-
Failed to extract/test .bz2 of Chinese Wikipedia
-
Hi Igor, here some feedback comes from my laptop 'Compressionette': https://github.com/facebook/zstd/issues/2551#issuecomment-808213083
-
Thanks for the fopen64 workaround, but the issue remains unaddressed! So maximal size of read per attempt is on 32-bit 2^32-1, and on 64-bit 2^64-1 bytes Obviously, not in practice, so in order to avoid problems documentations should state this issue.
-
I am pretty sure that our fread/fwrite routines work pretty well. Kai, I'm using MinGW packages that have certainly that problem, are you 100% sure yours is working with e.g. 2+GB in one go?! Still cannot figure out where the problem is, added the return value: if ((fp = fopen(argv[1], "rb")) == NULL) { printf("Nakamichi: Can't open '%s' file.\n", argv[1]); exit(13); } ... BUG_totalREAD = fread(SourceBlock, 1, SourceSize, fp); // Bug in MinGW, 2020-Oct-01 fclose(fp); According to https://man7.org/linux/man-pages/man3/fread.3.html...
-
For what is worth the OS is Windows 7 Pro, also the quick checking of a textual file shows the GCC binary works "PROPERLY": D:\Satanichi_aka_Nakamichi_2020-Jun-09>dir 06/11/2020 09:16 AM 55,397 lzsse2.cpp 06/11/2020 09:16 AM 1,316,439 Nakamichi_Ryuugan-ditto-1TB_btree.c 09/06/2019 11:50 AM 969,050,128 NCBI_FTP_Homo_sapiens_(human)_GCA_000001405.28_GRCh38.p13_genomic.fna.Nakamichi 06/15/2019 02:37 AM 3,313,087,324 q 01/07/2018 05:26 PM 191,644 Satanichi_GCC730_64bit.exe 06/11/2020 09:16 AM 198,144...
-
The same said the GCC guy in the link above: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97215#c4 (In reply to Andrew Pinski from comment #2) You need b if you don't want \r\n to be turned into just \n. At 11,945th line I use: if ((fp = fopen(argv[1], "rb")) == NULL) { printf("Nakamichi: Can't open '%s' file.\n", argv[1]); exit(13); } 1] As far as I investigated, the problem is that fread() reads less (around 860 bytes) than specified. 2] Also, as I wrote: This bug never appeared with files 1GB...
-
The same said the GCC guy in the link above: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97215#c4 (In reply to Andrew Pinski from comment #2) You need b if you don't want \r\n to be turned into just \n. At 11,945th line I use: if ((fp = fopen(argv[1], "rb")) == NULL) { printf("Nakamichi: Can't open '%s' file.\n", argv[1]); exit(13); } 1] As far as I investigated, the problem is that fread() reads less (around 860 bytes) than specified. 2] Also, as I wrote: This bug never appeared with files 1GB...
-
The same said the GCC guy in the link above: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97215#c4 (In reply to Andrew Pinski from comment #2) You need b if you don't want \r\n to be turned into just \n. At 11,945th line I use: if ((fp = fopen(argv[1], "rb")) == NULL) { printf("Nakamichi: Can't open '%s' file.\n", argv[1]); exit(13); } As far as I investigated, the problem is that fread() reads less (around 860 bytes) than specified.
-
Possible fread() malfunction of GCC 7.3.0
-
The thread on Overclock forum exploits 32MB dictionary for the purpose to stress RAM. I think you failed to get the need for third result - Highest MIPS, after all, it is just one more line in your GUI. The first pass serves no purpose when dictionaries bigger than LLC are used, yes? The whole point is to get the MAX of the FLUCTUATIONS and to print a STABLE result. As you can see, users started using your new faster v.18.05, this defeats the purpose of getting LEGACY results, no problema, but using...
-
Hi Igor, please consider adding one more line in your GUI, the Benchmark screen/form. Namely, Highest MIPS. Currently, those 2 values (first run, current run) fail to cover the full picture, since previous results (between runs) are overwritten, one cannot see the best score. If those passes were reported in the log or command prompt then okay. The whole point is in getting the best score (along with rest ones). You can see how two similar fastest machines cannot be rated properly due to big fluctuations...
-
Sure, for a given number of Knight-Tours, but what about dynamic such! Let's say...
-
I thought that you have seen the benchmark hashing 1 trillion Knight-Tours at: http://www.codeproject.com/script/articles/download.aspx?file=/KB/cpp/716530/_KAZE_32bit_hash_showdown_FNV1A_YoshimitsuTRIAD_source.zip&rp=http://www.codeproject.com/Articles/716530/Fastest-hash-function-for-table-lookups-in-C...
-
I thought that you have seen the benchmark hashing 1 trillion Knight-Tours at: http://www.codeproject.com/script/articles/download.aspx?file=/KB/cpp/716530/_KAZE_32bit_hash_showdown_FNV1A_YoshimitsuTRIAD_source.zip&rp=http://www.codeproject.com/Articles/716530/Fastest-hash-function-for-table-lookups-in-C...
-
I thought that you have seen the benchmark hashing 1 trillion Knight-Tours at: http://www.codeproject.com/script/articles/download.aspx?file=/KB/cpp/716530/_KAZE_32bit_hash_showdown_FNV1A_YoshimitsuTRIAD_source.zip&rp=http://www.codeproject.com/Articles/716530/Fastest-hash-function-for-table-lookups-in-C...
-
I thought that you have seen the benchmark hashing 1 trillion Knight-Tours at: http://www.codeproject.com/script/articles/download.aspx?file=/KB/cpp/716530/_KAZE_32bit_hash_showdown_FNV1A_YoshimitsuTRIAD_source.zip&rp=http://www.codeproject.com/Articles/716530/Fastest-hash-function-for-table-lookups-in-C...
-
I am sorry for the delayed answer. If you have something as a start (description,...
-
Couldn't use 256MB dictionary
-
Hi Pengwenwei, the SPEED is VERY VERY important, sadly I am just an amateur and can't...
1