A resposta é que não é muito diferente. Ele tem um cache maior e não é explicitamente danificado para evitar que ele funcione em sistemas com vários processadores. Os Xeons também têm suporte para memória ECC, que normalmente não é suportada em chips de CPU do consumidor. Caso contrário, o núcleo básico do processador é praticamente o mesmo.
Em sistemas antigos de 32 bits, o MMU do Xeon era um pouco mais inteligente, pois suportava múltiplos espaços de processamento de 4GB em até 64GB de RAM física. Os chips SPARC v8 tinham um recurso similar na MMU. Esse recurso funcionou devido à diferença no número de bits necessários para endereçar um deslocamento dentro de uma página (12 para uma página de 4KB) e o número de bits necessários para registrar o status de uma página (RWX, sujo, etc.). Os bits extras podem ser usados para uma referência de página física um pouco mais ampla (24 bits versus 20 para especificar o número da página), permitindo um endereço físico de 36 bits. No entanto, um único processo só pode ver um espaço de endereço contíguo de 4 GB a qualquer momento.
Alguns sistemas (por exemplo, versões do centro de dados do Windows Server) tinham uma API que permitia a um processo controlar a MMU para sobrepor partes desse espaço de endereço físico em seu espaço virtual. Esse recurso foi usado em versões corporativas do SQL Server para oferecer suporte a caches de disco maiores.
A maioria, se não todas, as CPUs modernas suportam este recurso quando executadas no modo de 32 bits, e provavelmente há muitas lojas ainda executando aplicativos legados de 32 bits nesse modo, seja em VMs (onde a MMU é emulada com um maior ou menor quantidade de suporte de hardware) ou estanho físico. No entanto, as compilações de 64 bits são muito mais comuns em compilações modernas de servidores de memória grande atualmente, que permitem imagens de memória contíguas maiores em um processo.