For the posterity, I've managed to make Blitzping much faster: on the ARMv8-A device, it went from ~10.5 MiB/s to ~120 MiB/s. Instead of sendto(), I used a single connect() call to bind the raw socket to its destination, and then I used writev() calls to "queue" many packets for sending. Internally, writev() [and its other counterpart, sendmmsg()] still uses the same for-loop'ing mechanism to iterate through its queue, but said loop would exist in kernelspace, requiring less userspace->kernelspace syscalls to accomplish the same goal.
As of now, the code is just a proof of concept for achieving higher throughput than what currently available tools (e.g., nping/hping3) are capable of. Other than that, nping is just too slow, and hping3 has not been updated in 12 years; in any case, both of them lack proper support for "newer" TCP/IP features (e.g., DSCP/ECN instead of IP ToS, or TCP Options in general).
I am currently in the process of re-writing this proof of concept to actually become a full-fledged alternative to those tools. At first, I was planning to fork hping3 as to maintain it, but its code just had too many questionable design choices; there were global variables and unnecessary function calls all over the place.
Those underpowered processors were only used as an optimization benchmark; if it runs good enough there, you could always throw more computational power and cores at it.
EDIT: Also, the numbers were in MiB/s (mebibytes per second), not Megabits per second; 10.5 MiB/s would be ~88 Mbp/s (megabits per second).
Thanks, I hope it'll be useful in your experiments. As for looking more realistic, I think it does the job; when I checked with Wireshark checked how different applications (e.g., games, programs) were communicating with their servers, I saw that they were sending empty SYN packets (i.e., no options) in order to initiate the TCP handshake.
Although hping3 does not let you specify TCP options, it still lets you append them as raw data. Despite that, only one application that I tested actually sent TCP (+options) back to its server. However, this specific server still ACK'ed my packets and proceeded normally, even if I did not send these so-called options. In any case, it will be easy to just append the options as raw data at the end of the packet buffer, for targets that actually discriminate based on options.
None of the real-world applications that I tested used fragmentation, and they all tagged their packets with "DF" (do not fragment); due to that, I did not really look into how fragmentation would affect this.
The reason I specifically included CIDR support, something that both nping and hping3 lack in their source IP parameter, was that ISPs or mid-route routers could block "nonsense" traffic (e.g., a source IP outside of the ISP or even country's allocated range) coming from a client; this is called "egress filtering." However, in a DHCP-assigned scenario, you still have thousands of IP addresses in your subnet/range to spoof, which should not get caught by this filtering. Ultimately, because the source IP would be coming from an entire range of addresses, firewalls (and CDNs) will have a harder time detecting a pattern as to block it.
As for defending against TCP SYN flooding in general, you could use "SYN Cookies" (https://en.wikipedia.org/wiki/SYN_cookies) as to expand less resources in keeping connections open. Unfortunately, in a residential ISP scenario where you only have one "real" IP address, your spoofed source IP would be chosen from a range of otherwise-legitimate addresses; those addresses (upon unexpectedly receiving SYN-ACK from your targeted server) would usually respond back to the original server with a RST packet as to terminate the connection, making it so that your "half-open" connections (the goal of SYN flooding) do not get to last as long. Lastly, this tool only really lets you flood packets as quickly as possible; if you have (or rent) multiple datacenter-grade bandwidth, powerful x86_64 CPUs, and lots of "real" IP addresses at your disposal, there would be little that your target could actually do to prevent you from DDoS'ing them. At that point, in the worst-case scenario, they could go "scorched earth" and reject all traffic from entire countries' ranges (saving their CPU/memory usage), but your packets would still continue getting routed there, and you could still saturate their download line.
As for how this could be made faster (without just throwing more cores and computational power at it), the entire overhead is on the Linux Kernel's "sendto()" side; perhaps writing a kernel module to communicate directly with the underlying NIC is the way to go.