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 realpero 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.