對于過去大約。20 年來，我一直在開發一個實作類似 METAFONT 的語言的 3D 圖形程式。它在 C 中。我現在已經開始研究將 3D 物件的資料寫入二進制檔案然后再次讀取它們的格式和函式。它旨在保存和快速加載已計算的資料，以避免每次運行程式時再次計算。
檔案格式的語法旨在用于類似機器的語言，該語言允許盡可能高的效率，而不必擔心人們閱讀或寫作是否舒適。
我的問題與將資料讀入暫存器的方式有關：我的計算機的體系結構是 x86_64，所以顯然我有 64 位暫存器。將資料讀入小于 64 位的物件（即字符、整數或浮點數）是否值得？讀取的內容不是讀入 64 位暫存器嗎？據我了解，暫存器的任何未使用位都設定為 0，這是一個額外的步驟，因此效率低于首先讀取 long int 或 double 。這是正確的嗎？有人對我應該如何進行有任何建議嗎？
這是我在回應 Scheff's Cat 的評論時所嘗試的。
/* ttemp.c */
#include <stdlib.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
void
write_uint(unsigned int i);
void
write_ulong(unsigned long int li);
int fd = 0;
int
main(int argc, char *argv[])
{
printf("Entering ttemp.\n");
fd = open("ttemp.output", O_WRONLY | O_CREAT, S_IRWXU);
printf("fd == %d\n", fd);
write_uint(~0U);
write_ulong(~0UL);
close(fd);
printf("Exiting ttemp.\n");
return 0;
}
void
write_uint(unsigned int i)
{
write(fd, &i, 4);
return;
}
void
write_ulong(unsigned long int li)
{
write(fd, &li, 8);
return;
}
然后我跑了：
gcc -pg -o ttemp ttemp.c
ttemp
gprof ttemp
這是 ttemp.output 的內容，根據 Emacs 的 Hexl 模式，所以物件顯然被寫入了輸出檔案：
00000000: ffff ffff ffff ffff ffff ffff ............
這是 gprof 輸出的相關部分：
Call graph (explanation follows)
granularity: each sample hit covers 2 byte(s) no time propagated
index % time self children called name
0.00 0.00 1/1 main [8]
[1] 0.0 0.00 0.00 1 write_uint [1]
-----------------------------------------------
0.00 0.00 1/1 main [8]
[2] 0.0 0.00 0.00 1 write_ulong [2]
-----------------------------------------------
所以，不是很有啟發性。我的猜測是暫存器中的歸零是在處理器級別執行的，并且它所花費的任何時間都不會顯示在系統呼叫級別上。但是，我不是系統程式員，我對這些主題的掌握并不是特別牢固。
uj5u.com熱心網友回復：
將資料讀入小于 64 位的物件（即字符、整數或浮點數）是否值得？
這取決于架構。在大多數平臺上，這非常便宜，例如 1 個周期，即使對于確切的目標代碼來說甚至不是免費的。有關這方面的更多資訊，請閱讀在 64 位計算機時代我應該繼續使用無符號整數嗎？. 請注意，浮點-雙精度轉換可能會慢得多，但在大多數主流 x86 平臺上它仍然需要幾十個周期（盡管在嵌入式設備上可能非常慢）。
讀取的內容不是讀入 64 位暫存器嗎？
實際上，處理器不會讀取每個 64 位塊的檔案。幾乎所有的 IO 操作都被緩沖（否則由于存盤設備甚至系統呼叫的高延遲，它們會非常非常慢）。例如，當你請求 4 個位元組時，系統可以獲取 256 KiB 的緩沖區，因為它知道應用程式經常連續讀取檔案，而且大多數存盤設備都針對連續操作進行了優化（每秒 IO 操作的數量通常很少） . 有關 IO 操作與其他操作相比延遲的更多資訊，請閱讀此內容（不是近似值）。簡而言之，IO 操作的延遲遠大于型別轉換的延遲，因此后者應該完全可以忽略不計在大多數平臺上（至少所有主流平臺）。即使讀/寫被緩沖，從/寫入內部緩沖區的函式呼叫的成本仍然高于強制轉換。因此，在這種情況下，您不應該太在意。
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/491644.html