As Daisetsu said, you're not doing anything wrong: CPU is just very slow at hashing WPA passwords. While I don't have experience on it, OSX shouldn't be a problem either.
The WPA/2 spec demands 4096 rounds of HMAC-SHA1 hashes to derive the final key. This equates to 16,384,000 general HMAC-SHA1 hashes/second at ~4k keys/second. Individually, they're rather fast. However WPA was designed in part to make brute force attacks harder (as well as more secure in general), and thus implemented many rounds of hashes instead of using just one.
Relying on CPU for cracking WPA isn't going to get you very far, as you've noticed. A much faster method would be GPU cracking. Even without a powerful GPU, you'll most likely get better results.
In my eyes, there are two major contenders in the GPU cracking game: hashcat and Pyrit;
hashcat
Site: https://hashcat.net/hashcat/
Tutorial: https://www.blackmoreops.com/2014/03/27/cracking-wpa-wpa2-with-hashcat-kali-linux/
hashcat is great if you don't have a lot of hard drive space. You can feed it input with crunch (like you're doing now), and it supports an incredible amount of algorithms; not just WPA. If you stop hashcat, you can pick it up later by specifying the start string in crunch, as hashcat gives you regular updates on its speed and current password as well as other things.
Pyrit
Site: https://github.com/JPaulMora/Pyrit
Tutorial: https://www.blackmoreops.com/2014/03/10/cracking-wifi-wpawpa2-passwords-using-pyrit-cowpatty/
Pyrit is great for precomputational attacks. Pyrit allows you to specify an SSID (since the SSID is used in the HMAC algorithm) and compute a table of keys based off of an input (be it a file or crunch) and keep them. If you knew the SSID you were after (say, Netgear; a default name) you could just compare the keys without having to recompute them over and over again. This is great because the comparison process is incredibly easy and will still use the gpu. With my SLI GTX650TI boost setup, I got about 55k hashes/second, and one-hundred million comparisons/second (if my memory is correct; this was a while ago).
Pyrit is more useful in the long run, as you have only to compute the keys once, then compare them with the captured handshake in your pcap files. With hashcat, you can get to cracking and comparing at the same time without the need to precompute everything and then compare it.
The difference is time: if you have an 8 character password, and you're going to try all possible combinations from aaaaaaaa to zzzzzzzz and your password was mmmmmmmm, Pyrit would have to compute all possible keys from aaaaaaaa to zzzzzzzz and then compare it, whereas hashcat would would get to mmmmmmmm, hash it, compare it, and tell you its found the answer without having to go through all the other possible candidates.
Now, if you then changed the password and wanted to compare another handshake, then Pyrit would be your boy, as you've already computed all the keys for aaaaaaaa to zzzzzzzz for that SSID, whereas hashcat would have to recompute them. Basically, if you will re-use an SSID many times, go for Pyrit. If its a one off, use hashcat.
As for raw speed numbers, this site has a very nice table comparing the speeds of many different graphics cards. In my experience, hashcat and Pyrit have about the same hashing speeds, so if that number is your main concern, using either GPU hashing program will yield approximately the same results. Your main concern between programs will be the re-use of that SSID.
I hope this makes sense. If not, let me know and I'll try to explain it better!
