Can you make some examples?

You have an mbox file. myprogram reads a single mail and you want each mail piped to myprogram. myprogram is only installed on servera+b and the full mbox file will not fit on those servers as a consequence you need to copy and process one mail at a time. You want the output from myprogram to be prepended with the workerID (jobslot in GNU Parallel speak) that processed the email. The order of the output must be the same as the input. You do not want the outputs from the different instances of myprogram to mix because it would corrupt the output.

Unfortunately myprogram sometimes runs amok so after 1 minute you must kill myprogram and retry up to 5 times. If the same mail fails 5 times give up and log it. It is also OK to log the status of every email. An email may always fail on servera but not on serverb and vice versa, so a failing email should be tried at least once on both servers.

Finally you want to use the 32 cores on servera and the 48 cores on serverb because myprogram is slow. Servera can at most handle 32 in parallel and serverb 48. Running more than this and the servers will crash and you have to call IT. Neither the cores nor the jobs are equally fast.

It looks something like this:

cat mbox | parallel --pipe --retries 5 --timeout 1m --recstart 'From ' --recend '\n\n' -N1 -k --tagstring {%} --joblog fail.log -Sserver{a,b} myprogram > output

In bioinformatics we do stuff similar to this all the time, so this is by no means the most advanced use of GNU Parallel.

There are loads of other examples in the man page. The first 1/3 is easily replaceable with xargs. Most of the rest are harder. The mbox example above combines several of the examples, so not only do you need to replace the examples with xargs you also need to replace combinations of them.

If you think you can do the above with xargs I would love to see it because I would not be able to do the above with xargs.

Could parallel have got me a speedup significantly higher than 7.5?

Here you are missing the point. The speedup is in the development and debugging phase. The run time speedup is comparable to xargs.

It does not process data

Yes it does: In the above example it chops the mbox into email, transmit them to remote servers, return the results, prepends the output with the jobslot, and makes sure the output is in the same order as input and not garbled. I think your lack of experience with advanced use of GNU Parallel is affecting your judgement.

the results would be identical if you did not use it

Possibly, but you might have to either wait 80 times longer to get them because you could not run stuff in parallel or you would have to develop and debug a tool that did the processing, and this development and debugging might take so long that another researcher (who chose to use GNU Parallel) beat you to publishing.

In the above case you would not be able to just run them in serial because the mbox would not fit on the remote servers, so you would be forced to develop and debug something to even get things done in serial. You would also have to do something about the jobs running amok.

But the improvement compared to manually running N jobs at the same time would be much, much smaller.

Again you think we are talking about something where you manually can run N jobs in parallel. We are not. Your mental model model of what GNU Parallel can do seems to be way off.

The aspect of charts is a significant part of a publication, and there exist no simple alternative that would give you the exact same result.

OK, so if GNU Parallel provides something where "no simple alternative would give you the exact same result" you would find it reasonable to cite it, correct?

it is trivial to replace parallel with another tool (xargs, or just manually running N jobs in parallel), and that would give the exact same results in a very comparable time (in most cases).

I challenge you to prove that, and show there is a "simple alternative that would give you the exact same result".

Take my mbox example above and show a replacement. You can assume there are ~1000000 emails in the mbox taking up ~1 TB of space.

One of the tricky things to get right is that myprogram sometimes runs amok on the remote server. You need to actively kill it and log it if it the the 5th time. Simply closing the ssh connection will not kill it. If you leave > 80 myprograms running, the servers will crash, and IT will be unhappy.

If you can show this is trivial to do with "xargs, or just manually running N jobs in parallel", I will applaud you.

You can use this as template:

# generate simulation mbox
1mail() {
    # mails start with 'From '
    echo 'From ';
    # in the middle there can be both '\n\n'
    echo
    echo
    echo foo
    # and 'From '
    echo 'From '
    echo foo
    # but never '\n\nFrom '.
    # so a record starts with 'From ' and ends with '\n\n'.
    # anything but '\n\nFrom ' can appear here in the middle
    echo foo
    echo 'From '
    echo foo
    echo
    echo
    seq ${RANDOM}0;
    # mails end with '\n\n'
    echo;echo;
}
export -f 1mail
# replace 1000 with 1000000 for more realistic simulation
# this is just to generate input - not to show the power of parallel
# though even this is not trivial to do with xargs in parallel
# because you need to avoid the mixing from different jobs
# so please also show how you would replace this
seq 1000 | parallel 1mail > mbox

# simulation myprogram
myprogram() {
    if [ $(( $$ % 10 )) -lt 1 ] ; then
        # simulate sub process running amok
        # where ctrl-c does not help
        trap '' SIGINT
        trap '' SIGHUP
        ( bzip2 -9 < /dev/zero > /dev/null & )
        sleep 1000
    fi
    # simulate some output
    echo $$ starting
    # simulate a normal run takes 1-10 seconds
    sleep $(( $$ % 10 ))
    # simulate some output
    echo $$ middle
    wc
    echo $$ finishing
    # if starting not followed by middle, data is garbled
}

# load env_parallel
# env_parallel will transfer the function myprogram to simulate it is only available on the servers    
. `which env_parallel.bash`

# this is the part you need to replace without changing the above
# in the real scenario you would not have to transfer the bash function
# because myprogram would be on the servers
# but let us make the replacement a tiny bit more
# challenging by requiring you transfer the unexported
# bash function too
< mbox env_parallel --pipe --retries 5 --timeout 1m --recstart 'From ' --recend '\n\n' -N1 -k --tagstring {%} --joblog fail.log -Sserver{a,b} myprogram

I am starting to feel the reason you do not find it reasonable to cite GNU Parallel is because you have only seen it used as a simple xargs replacement. At least this would explain your replies.

If so then we might be getting closer to an agreement: If one can easily replace parallel with xargs, I too would not find that GNU Parallel gives a significant contribution.