The main goals of EGLIBC (described http://www.eglibc.org/mission) are all targeting embedded platforms:
- Provide options to reduce on-disk and in-memory footprint:
As long as you want to keep binary compatibility to glibc these options are useless or have nearly no effect on x86-64.
- Support cross-compilation and cross-validation:
Well... Who does cross-compiling for x86-64...
- Support processors used in embedded systems:
I guess you don't run "x86-64" embedded systems, so it's useless, too.
- Incorporate support for processor-specific functionality where appropriate:
glibc already has full optimizations for x86
- Retain API and ABI compatibility with GLIBC wherever feasible.
I wouldn't suggest using eglibc unless your distribution fully supports it, otherwise you may sometimes break linking when full ABI compatibility is not possible.
Though, many developers criticize the development-style of glibc and so non-technical reasons may favor eglibc over glibc.
API and ABI compatibility between eglibc and glibc disallow big changes and all x86-64 optimizations are probably merged into glibc, too.