xcrh
commented
8 years ago NB: I've fixed issue like this:
diff --git a/_lzbench/lzbench.cpp b/_lzbench/lzbench.cpp
index d7bb8b5..522eda9 100644
--- a/_lzbench/lzbench.cpp
+++ b/_lzbench/lzbench.cpp
@@ -76,7 +76,7 @@ typedef struct string_table
{
std::string column1;
float column2, column3, column5;
- size_t column4;
+ uint64_t column4;
string_table(std::string c1, float c2, float c3, size_t c4, float c5) : column1(c1), column2(c2), column3(c3), column4(c4), column5(c5) {}
} string_table_t;...not sure if printf expects exactly this, but now I'm getting proper compr. size, so it seems is was size_t on ARM to blame.
jibsen
inikep
Configuration: Ubuntu @ ARMv7, hardfloat ABI, 32-bit LE CPU. lzbench: current version, at commit 5937923 Compiler: GCC 4.8.1 (Linaro) - armhf abi, target is ARMv7 (Allwinner A10 based board). Flags: defaults from makefile, I've only changed the following lines to match my system better:
Problem description:
Note: Compr size looks pretty close to 2^32, which could be something like integer overflow or other bug related to dealing with (32-bit) integers. Keep in mind that on ARM and in general, sizeof(int), long, pointers, etc could vary and you can't expect it to have certain size, unless you go for something like uint32_t, etc from modern C standards.
And btw, when it comes to 64 bits, there're 64-bit ARMs and they seems to have sunrise of their popularity, so you better do not expect each 64 bit CPU to be x86. Some could be ARMs, etc.
Bonus: If you want a test run results from rather strange machine, I can launch whatever benchmark you want, subject to machine limits (only 1Gb of RAM for everything, no swap, CPU and RAM aren't exactly fastest, memcpy tops at 256Mb/sec or so).
Example output on just a 512Kb file follows: