|  | ||
| Golden Member     加入日期: Dec 2001 
					文章: 2,930
					
				 | 剛又抽空看了一下MFLOPS地方 文章也有舉幾個有趣的例子 R10000測試出來效能有400MFLOPS at 200MHz 但R8000測試出來效能有360MFLOPS at 90MHz 為什麼呢?因為R10000只有1個浮點運算單元,R8000有2個 (像不像Phenom II跟推土機的狀況?  ) 然後下面還有舉個例子 一個64bit CPU效能被評定400MFLOPS,但程式只需要32bit的計算,那就有很多效能被浪費掉 最後還有寫說測試MFLOPS高是很好,但實際運用很依賴記憶體頻寬 高MFLOPS的CPU在低記憶體頻寬的環境表現也會不佳 此文章於 2015-10-16 10:35 AM 被 bureia 編輯. | |||||||
|  2015-10-16, 10:30 AM
			
			
	#21 |   | 
| Golden Member     加入日期: Dec 2001 
					文章: 2,930
					
				 | 關於CTP測試是找到這個,就是一個美國出口規範的測試項目 連公式都給你了,有興趣的自己看吧  https://books.google.com.tw/books?i...0Second&f=false http://www.intel.com/support/tw/pro...b/CS-017346.htm 在某些國家/地區,需要 CTP 分數做為處理器效能的度量,供出口規範用。 以下為 Intel 32 位元和 64 位元處理器的 Gigaflops (GFLOPS)、「合成理論效能」(CTP) 和「調整高峰效能」(APP) 值。若要尋找 Intel 微處理器的貿易分類資訊,請前往 http://www.intel.com.tw/content/www...mpliance.html。 美國商務部產業與安全署 (BIS) 於 2007 年 11 月 5 日發佈「出口事務管理規則 (EAR) 15 CFR」的修正條款,促成納入 2006 年 12 月 Wassenaar Arrangement Plenary Agreement Implementation。 本修正案推出一項新測量機制─ Gigaflops (GFLOPS),以利測量以出口為目的所生產的處理器效能。BIS 不再要求出口商測定 CTP。不過,在上述期限之前,若客戶所在的國家/地區仍要求以 CTP 作為測量處理器以符合出口規範,Intel 會持續提供 CTP 值。 CTP 計算係以修改過的公式為準。此公式係來自 1993 年 12 月 21 日的 Wassenaar 協商,於「美國商務部出口事務管理規則」(United States Department of Commerce Export Administration Regulations) 15 CFR 774 (第 4 類公告事項 4)」中發佈,且記載於 Millions of Theoretical Operations Per Second (MTOPS)。 APP 計算係以「美國商務部出口事務管理規則」(United States Department of Commerce Export Administration Regulations) 71 CFR 20876 中所發佈的公式為準,並以「加權每秒數兆次浮點運算」(Weighted Teraflops, WT) 說明。 | ||
|  2015-10-16, 11:37 AM
			
			
	#22 |   | 
| *停權中*  加入日期: Jun 2015 您的住址: 金一十大女支三 
					文章: 1,282
					
				 | 引用: 
 他沒說錯 我也沒說錯 不是不為A就等於B | |
|  2015-10-16, 01:02 PM
			
			
	#23 |   | 
| Golden Member     加入日期: Dec 2001 
					文章: 2,930
					
				 | 引用: 
 算了,我直接整理你的觀點 1.7-zip的演算法有很好的多執行緒最佳化,所以拿來測單執行緒效能很愚蠢 2.現在是多核多執行緒的時代,所以拿多執行緒最佳化很強的7-zip來測單執行緒效能很愚蠢 這些論點合不合理,專不專業,PCDVD藏龍臥虎就留給眾網友去決定了  | |
|  2015-10-16, 04:15 PM
			
			
	#24 |   | 
| *停權中*  加入日期: Dec 2005 
					文章: 6,087
					
				 |  | 
|  2015-10-16, 04:21 PM
			
			
	#25 |   |