Last login: Fri Jan 24 15:32:41 on ttys000
/Applications/test/parpar ; exit;
manuelsan@Manuels-iMac ~ % /Applications/test/parpar ; exit;
Values for `out` and `input-slices` are required
Enter `parpar --help` for usage information
[Proceso completado]
Es que Python a secas siempre usa un solo core independientemente del número de hilos que use el programa. Con OpenMP es otra historia...Me han confirmado que funciona en un Mac real pero sólo usa 1 core. Afortunadamente, he encontrado la forma de solucionarlo.
CC="/usr/local/opt/llvm/bin/clang -Xpreprocessor -fopenmp" CXX="/usr/local/opt/llvm/bin/clang++ -Xpreprocessor -fopenmp" LDFLAGS="-L/usr/local/opt/llvm/lib" CPPFLAGS="-I/usr/local/opt/llvm/include" /usr/local/opt/node@12/bin/node build.js --fully-static
Sí, pero usando un único core. Éste tiene soporte para múltiples cores.
Copia un fichero tocho donde tengas el parpar y ejecuta:
./parpar -s10M -r10% -m4096M -o test.par2 ficherotocho.ext
Tengo curiosidad por saber el tiempo que tarda en tu Hackintosh y el número de cores que usa
Last login: Sat Jan 25 12:30:56 on ttys000
manuelsan@Manuels-iMac test % ./parpar -s10M -r10% -m4096M -o test.par2 FBI.mkv
Multiply method used: XOR JIT (128 bit), 16 threads
Generating 290 MiB recovery data (29 slices) from 2814.82 MiB of data
Calculating: 100.00%
PAR2 created. Time taken: 8.832 second(s)
manuelsan@Manuels-iMac test %
Openmp no da a Python soporte “multihilo” sino soporte “multinucleo”. Python a secas si ofrece soporte “multihilo” Solo que todos los hilos se ejecutan en el mismo núcleo.
manuelsan@Manuels-iMac test % ./parpar -s1M -r10% -m8192M -O -o test2.par2 1492.mkv
Too many input slices: 33994 exceeds maximum of 32768. Please consider increasing the slice size, or reducing the amount of input data
Enter `parpar --help` for usage information
manuelsan@Manuels-iMac test % ./parpar -s10M -r10% -m8192M -O -o test2.par2 1492.mkv
Multiply method used: XOR JIT (128 bit), 16 threads
Generating 3400 MiB recovery data (340 slices) from 33.2 GiB of data
Calculating: 100.00%
PAR2 created. Time taken: 362.644 second(s)
manuelsan@Manuels-iMac test %
parpar -s10M -r10% -m8192M -O -o test2.par2 d:\Ubuntu\osx\Test4\
Multiply method used: XOR JIT (128 bit), 8 threads
Generating 3220 MiB recovery data (322 slices) from 31.41 GiB of data
Calculating: 100.00%
PAR2 created. Time taken: 00:10:42
6 minutos me parece demasiado para esa máquina. En mi AMD FX-8350 con la versión de Windows:
Insertar CODE, HTML o PHP:parpar -s10M -r10% -m8192M -O -o test2.par2 d:\Ubuntu\osx\Test4\ Multiply method used: XOR JIT (128 bit), 8 threads Generating 3220 MiB recovery data (322 slices) from 31.41 GiB of data Calculating: 100.00% PAR2 created. Time taken: 00:10:42
Si tienes Windows en ese PC, descárgate el parpar para Windows desde github y haz el mismo test. Si no, déjalo y perdona las molestias.
edito: Ahora que miro los datos de tu primer test:
PAR2 created. Time taken: 8.832 second(s)
No entiendo nada, porque con un fichero unas diez veces más grande, debería haber tardado menos de 100 segundos con el de 33 GB.
C:\Test>parpar -s10M -r10% -m8192M -O -o test2.par2 1492.mkv
Multiply method used: Shuffle (256 bit), 16 threads
Generating 3400 MiB recovery data (340 slices) from 33.2 GiB of data
Calculating: 100.00%
PAR2 created. Time taken: 146.191 second(s)
Si averiguas el porqué de la diferencia de rendimiento, o al menos sospechas de algo, dímelo. Por curiosidad.
--method Algorithm for performing GF multiplies. Process
can crash if CPU does not support selected method.
Choices are:
lh_lookup: split 2x 8-bit scalar table lookup
xor: vector XOR bit dependencies
xor128: force SSE2 variant of `xor`
xor256: force AVX2 x64 variant of `xor`
xor512: force AVX512BW x64 variant of `xor`
shuffle: split 4x 4-bit vector table lookup
shuffle128: force SSSE3 variant of `shuffle`
shuffle256: force AVX2 variant of `shuffle`
shuffle512: force AVX512BW variant of `shuffle`
affine: split 2x 8-bit vector XOR dependencies
affine128: force GFNI variant of `affine`
affine512: force AVX512BW + GFNI `affine`
Sobre NTFS, si luego lo va a conectar a algún PC, o a un repro para ver pelis en la tele o algo así, yo pillaría el Paragon NTFS y su Mac ya podrá leer (y escribir) en ese sistema de archivos. Si no, le tocará usar HFS+, y el disco ya solo le servirá en otro Mac.