On the other hand, you might not want to be hashing a 20meg password. It is fast on my computer but it's fair to limit at something more reasonable.

    $ python -c 'print "8 bytes\n" * (20 * 1024 * 1024 / 8)' > 20meg.txt; time shasum -a 512 20meg.txt 
    59cb7f88ad8d6229e6d3a74ee422dff57e17f168c6e6fa44ef32c3f07a73a6e455d8b55c1265d5212b9ed5475b6d9364286645200dada59aa16905a9ce748561  20meg.txt

    real	0m0.289s
    user	0m0.284s
    sys	0m0.004s

    $ python -c 'print "8 bytes\n" * (16 / 8)' > 16byte.txt; time shasum -a 512 16byte.txt
    b6043d3a520424d5ec17dc0c23ba3b591d74517e2b9faa0df2d69d13c89a5f372d6dc35f95836687ee05be18433277e1c4b67393eb2771b475d655a832b16654  16byte.txt

    real	0m0.045s
    user	0m0.040s
    sys	0m0.004s

When there will be multiple shorter passwords that hash to the same value, is there a point to a 20mb pass?

There is a slight exception to this. If they are using an older statically typed language like C, it might make sense for them to have a limit on the buffer ready to store your unhashed password. Yes it seems crazy these days, but it might apply to some of the older systems which have password length limits.

Hard limit of 72, beyond which many implementations will silently truncate, and reduced entropy from each character beyond 55 bytes.

Probably a good idea to pre-hash. Or use scrypt.