Jak zrównoleglić skrypt narzędziowy napisany w bashu?

Cześć, szukam rozwiązania od wczoraj i nie mogę znaleźć nic co by mi pomogło.

Mam narzędzie linuxowe, które (mocno upraszczając) wycina mi sekwencje określone w pliku illumnaSeq. Mam 33 pliki, które mam przemielić. Jeden plik się procesuje koło 5h. Mam do dyspozycji serwer na centosie, ma 128 rdzeni.
Znalazłem kilka rozwiązań, ale każde działa tak, że używa tylko jednego rdzenia. Ostatnie niby odpala 33 nohupy, ale dalej ciśnie całość po jednym rdzeniu.

Moje pytanie brzmi, czy ma ktoś jakiś pomysł jak wykorzystać potencjał maszynki? Bo w zasadzie każdy plik może się niezależnie przetwarzać, nie ma między nimi żadnych relacji.

Tak wygląda aktualna wersja skryptu:

#!/bin/bash
PLIKI=/home/daw/raw/*
count=0

for f in $PLIKI
do
  base=${f##*/}
  echo "Przetwarzanie $f pliku..."
  nohup /home/daw/scythe/scythe -a /home/daw/scythe/illumina_adapters.fa -o "OUT$base" $f &
  (( count ++ ))
  if (( count = 31 )); then
        wait
        count=0
  fi
done

Tłumaczę jeszcze: PLIKI to lista plików z folderu raw.
Właściwa linijka wykonująca nohup: pierwsza ścieżka, to ścieżka do narzędzia, -a ścieżka to ścieżka do pliku z paternami do cięcia, out to out, ma się zapisywać jako taka sama nazwa pliku jak przetwarzany + OUT na początku. Ostatni parametr to plik wejściowy który ma być przetworzony.

Tutaj readme narzędzia:
https://github.com/vsbuffalo/scythe

Czy wie ktoś może jak można to ogarnąć?

Dość nietypowe. U siebie odpalam podobne taski jednordzeniowe w podobny sposób i nie mam z tym problemu (przynajmniej od dekady).

Najsampierw warto sprawdzić czy są ustawione jakieś limity:

nproc
ulimit -a
cat /etc/security/limits.conf

Gdy wszystko jest ok i pokazuje to co ma pokazać to możesz spróbować wywołać te komendy poleceniem parallel:
Parallel - przykłady użycia

Hej! Dziękuję za odpowiedź, będę próbował coś pokombinować z linkiem od Ciebie i parallelem.
Tymczasem ulimit -a zwrócił mi:

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 2063124
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 4096
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited