This is mainly motivated by size, given that SHA2-256 provides more collision resistance than will ever be required, we end up storing 256 bits of 32 Bytes of needless data which for some archives of many files, can cost up to a Megabyte of wasted space. And since hashes are designed to end up as random as possible, this is a Megabyte of less-than-ideal data for the sake of compression.
SHA2-512 was initially chosen due to my early research online leading me to believe that on 64-bit processors (which nowadays almost everything is), SHA2-512 performs better than its 256 bit cousin due to more efficient use of the CPU and its cache.
But local benchmarking leads me to believe that reality runs counter to this claim as consistently SHA2-512 ends up slower than 256:
So with both space savings and speed improvements on the table, it seems silly not to change.
A member of the community ran the same benchmark and saw similar results:
This is mainly motivated by size, given that SHA2-256 provides more collision resistance than will ever be required, we end up storing 256 bits of 32 Bytes of needless data which for some archives of many files, can cost up to a Megabyte of wasted space. And since hashes are designed to end up as random as possible, this is a Megabyte of less-than-ideal data for the sake of compression.
SHA2-512 was initially chosen due to my early research online leading me to believe that on 64-bit processors (which nowadays almost everything is), SHA2-512 performs better than its 256 bit cousin due to more efficient use of the CPU and its cache.
But local benchmarking leads me to believe that reality runs counter to this claim as consistently SHA2-512 ends up slower than 256:
So with both space savings and speed improvements on the table, it seems silly not to change.
A member of the community ran the same benchmark and saw similar results: