2012-10-15 28 views
5

有一個相對new Linux ABI referred to as x32,其中X86-64處理器在32位模式下運行,所以指針仍然只有32位,但在64位體系結構專用寄存器仍在使用。因此,與普通的32位一樣,您的內存使用量仍然限制在4GB以內,但是與64位相比,指針的緩存空間更少,您可以高效地執行64位算術操作,並且可以訪問更多寄存器(16)比你在香草32位(8)。<4GB工作負載在Linux x32 ABI中的性能會比x64差嗎?

假設你有一個工作量很好地配合4GB內,有沒有什麼辦法X32的表現可能會比在x86-64的差?

在我看來,如果你不需要額外的內存空間,不會丟失任何信息 - 你應該總是得到相同的PERF(當你已經裝入高速緩存)或更高(當指針節省空間可以讓你適應更多在緩存中)。但是,如果有分頁/ TLB /等,我不會感到驚訝。我不知道的細節。

+0

邪惡的是細節,所以我會不會很驚訝,如果在某些罕見的情況下,在你的情況,有時X32可以比x86-64的差那麼一點點。但是我不相信這是很常見的......(你可以想象,對齊約束在x32上不太強大,並且這很少會影響緩存性能)。 –

+0

請記住,指針大小不是兩個ABI之間唯一的區別 - x86-64也有更多的寄存器,這可以減少加載/存儲指令的數量,還有其他一些差異。因此,這個問題並不是一個簡單的答案,基準測試幾乎總是決定哪個「更好」的定義對於該特定項目很重要的最佳途徑。 – twalberg

+1

@twalberg:我想你可能會誤解這個問題--x32和x86-64具有相同數量的寄存器。我不是在談論普通的32位。 –

回答

8

當然,如果你有一個多線程程序,數據結構在x32上較小的事實可能會導致線程之間的緩存行爭奪 - 不同的對象可能分配在x32模式下的同一緩存行和x86_64模式下的不同緩存行。如果兩個線程獨立修改這些對象,則緩存乒乓可能會嚴重降低x32代碼的速度。當然,不管指針大小如何,這種緩存效果都可能發生,但如果代碼已經被調整爲假定64位指針,那麼去32位指針可能會使事情失調。

+1

+1,但在實踐中,您應該將任何可能被兩個線程觸及的數據對齊到緩存行。 –

+0

@JosephGarvin:是的,但對齊可能已經完成,假設一個特定的指針大小。如果有人填充了填充64位指針的緩存行,則更改爲32位指針而不更新填充可能是個問題。如果您正在使用現有的已調優源代碼並在x32模式下進行重新編譯而不做任何更改,這主要只是一個問題。 –

2

在X32處理器被實際執行在「長模式」中,相同的模式爲x86_64的。也就是說,處理器在尋址時看到的地址仍然是64位,但X32 ABI確保所有地址都足夠小,以適應32位。因此,在某些情況下,當指針必須從32位擴展到64時,會有一些輕微的開銷。

此外,需要x86/x86-64/x32庫在RAM中,我想這是什麼最終會在實踐中結束(除非你正在談論一些嵌入式或其他嚴格控制的系統而不是通用計算機),可能會消耗X32的一些好處。

+1

這些指針是否實際簽名擴展?我不相信在長模式下32位加載或存儲指令會有任何性能損失,符號擴展和零擴展是在同一週期內(不添加延遲)在硬件中處理的非常便宜的操作。 –

+0

我認爲嵌入和嚴格控制的系統是預期的目標,所以我懷疑庫的RAM使用問題會突然出現。 –

+0

@BenVoigt:他們的確可能是符號擴展而不是零,我忘記了它。不,在長模式下32位加載/存儲不會有任何代價,相反,與rXX寄存器編碼相比,32位寄存器編碼需要更多的空間。是的,符號/零擴展是非常便宜的,儘管它們佔用了一小部分解碼器BW並且膨脹了代碼。 – janneb