感覺雪豹的斑點慢慢在變淡中

0分

71樓

個人積分：0分

文章編號：14459857

MarsPing wrote:
所以依據我前面的問題 "此外蘋果有宣稱把 code 重編譯成 64-bit 軟體就會跑得比較快嗎??"
所以您給的答案是, 似乎蘋果沒有這樣做嘛!

改寫跟重新編譯是不一樣的,
重新編譯 (recompile) 指的是同一段程式碼, 到了新的編譯環境, 不更動內容, 重新執行一次 compile.

以新的 Finder 為例, 依照蘋果官方的說法是 "Rewritten for Snow Leopard"
這是重寫, 為了支援新的技術程式碼的本身有改過. 跟重編譯是兩回事.

我一直都說蘋果重寫64-bit程式啊，重新編譯從頭到尾都是你的宣稱，關我啥事?

MarsPing wrote:
... 所以前輩搞錯我的意思了...

我的意思是... 如果在 64-bit Cocoa Framework 裡頭所使用的 API 已經有對 GCD 和 OpenCL 進行最佳化
那麼, 就算廠商開發的軟體中並沒有使用 GCD 和 OpenCL, 也會因為使用到那些在 Cocoa-64 中已經最佳化的 API 而產生效能上的差異.

那廠商需要花多少成本去改版? 只需要使用新的 Framework 重新編譯一次程式碼就可以了, 這幾乎沒成本吧?

我相信GCD和OpenCL都是API的形勢，如果只要重新complie舊程式就可以有GCD和OpenCL，現在早就一推軟體宣稱支援這兩個功能了。你到底找到多少第三方軟體支援GCD和OpenCL?

MarsPing

119分

72樓

MarsPing

個人積分：119分

文章編號：14461342

gate2 wrote:
我一直都說蘋果重寫6...(恕刪)

首先...
煩請前輩回頭去看之前的討論...

在我認知下的改成 64 位元, 只要到 64 位元的開發環境下重新編譯就好了, 這樣也是 64 位元的應用程式.
依照您的說法, 以及我對雪豹中的軟體的認知,
這次並不是單純改成 64 位元, 連程式都重新為了採行新技術而改寫.

蘋果沒有宣稱改成 64 位元的軟體效能就會比較快吧?
那到底是誰說 64 位元會變快的??

gate2 wrote:
現在的10.6不就有內建的幾個程式是從32-bit改寫而來？只有上層改寫，底層一樣是32-bit kernel，這種狀況不就是蘋果目前宣成的64-bit變快了?

那既然重新編譯成 64 位元的軟體不見得會比較快~
而又確定利用 OpenCL 和 GCD 改寫而成 64-bit 的軟體會比較快...

又怎麼能說軟體在 10.6 的 32-bit Kernel 跑時, 無異於 10.5?
這又是誰說的? 囧...

gate2 wrote:
64-bit應用程式+32-bit kernel是 Leopard的架構，不使用64-bit kernel的Snow Leopard對上層的軟體而言和Leopard是沒有差異的

接著對這個做回覆

gate2 wrote:
我相信GCD和OpenCL都是API的形勢，如果只要重新complie舊程式就可以有GCD和OpenCL，現在早就一推軟體宣稱支援這兩個功能了。你到底找到多少第三方軟體支援GCD和OpenCL?

先說明一下, 小弟我並沒有在 OS X 上開發軟體的經驗, 我也沒說我找到了第三方的軟體支援 OpenCL 和 GCD, 我只是用我對執行緒的認知和 GUI 開發的經驗, 來討論在 10.6 上的 64-bit Cocoa Framework.

我也認同 GCD 和 OpenCL 會是以 API 的形式提供給開發人員, 但我沒有宣稱 recompile 舊程式就可以有 GCD 和 OpenCL, 之前小弟的說法是 “如果在 64-bit Cocoa Framework 裡頭所使用的 API 已經有對 GCD 和 OpenCL 進行最佳化”, 實際上有沒有我不清楚, 只有蘋果內部的開發人員知道, 但如果真的 Framework 有最佳化, 那重新編譯後應該是要變快的.

舉個例子來說, Java SE 1.5、1.6 是兩個不同版號的平臺, 簡單說 1.6 除了擁有 1.6 才有的新 API 之外, 同樣的也擁有 1.5 的所有 API. 舉這個例子能證明什麼? 很簡單, 只要把用 1.5 開發出的軟體的原始碼, 原封不動的拿到 1.6 去重新編譯和執行, 可以發現 1.6 平臺下運作的確比 1.5 來得快, 這就可以說是所謂 Framework 和 API 的改進.
也就是 ==> 開發人員不需要更動原始碼, 只要 Framework 和 API 改進, 性能一樣會提升.

另外, 寫過 GUI 的人應該都知道 GUI 本身就是個多執行緒, 使用者觸發事件的偵測、畫面的更新、資料的同步, 這些都要靠多執行緒才能完成. 所以如果 GCD 真的這麼好, Apple 把 GCD 拿來改進 Cocoa Framework 中的 GUI 元件 API 也很符合 common sense 吧? 同樣的, 如果 OpenCL 這麼好, 為什麼不拿來改進 Cocoa Framework 中其它適合用 OpenCL 改進的 API 呢?
當然這只是我的猜測, 實際上 Cocoa-64 有沒有做這樣的最佳化我不曉得, 只是我會這樣推論是有根據的.

我想小弟寫出來的文字都還蠻尊重的就是了 ^^ 應該沒有什麼會得罪人的地方...
這也是每次回文都要回很久的原因, 包括思索有沒有和自己先前的文章矛盾, 或是有寫錯或誤會人之類的, 能避免盡量避免.
在這發文, 小弟完全沒有討筆戰的意思, 如果單純只是想要找小弟筆戰, 那我不跟啦~
在這個版我也只是個新手, 發言討論是想多了解點東西, 是想分享點自己的經驗和知識, 是想來幫助看文章的人了解整個討論的目的與結果...
如果只是筆戰的惡性循環, 沒打算搞懂對方的說法就急著回覆, 那回應在多次也沒用, 也沒有值得再繼續討論的空間了...

gate2

0分

73樓

gate2

個人積分：0分

文章編號：14464774

MarsPing wrote:
在我認知下的改成 64 位元, 只要到 64 位元的開發環境下重新編譯就好了, 這樣也是 64 位元的應用程式.
依照您的說法, 以及我對雪豹中的軟體的認知,
這次並不是單純改成 64 位元, 連程式都重新為了採行新技術而改寫.

蘋果沒有宣稱改成 64 位元的軟體效能就會比較快吧?
那到底是誰說 64 位元會變快的??

啊不就是蘋果自己說的

64 位元內建應用軟體

幾乎所有的系統應用程式 - 包括 Finder、Mail、
Safari、iCal、iChat 等 - 均以 64 位程式碼構建，不僅充分利用了 Mac 中的所有記憶體，還大幅提升了整體效能。再加上 Snow Leopard 的其它調整和改進，從啟動 QuickTime 等應用程式、在 Safari 上執行 JavaScript、再到打開影像檔案，現在您做每一件事都更加快速流暢。

MarsPing wrote:
那既然重新編譯成 64 位元的軟體不見得會比較快~
而又確定利用 OpenCL 和 GCD 改寫而成 64-bit 的軟體會比較快...

又怎麼能說軟體在 10.6 的 32-bit Kernel 跑時, 無異於 10.5?
這又是誰說的? 囧...

我指的是上層軟體沒有重寫的情況下，10.6＋32-bit kernel和10.5+32-bit kernel的架構沒有差異。

MarsPing wrote:
我也認同 GCD 和 OpenCL 會是以 API 的形式提供給開發人員, 但我沒有宣稱 recompile 舊程式就可以有 GCD 和 OpenCL, 之前小弟的說法是 “如果在 64-bit Cocoa Framework 裡頭所使用的 API 已經有對 GCD 和 OpenCL 進行最佳化”, 實際上有沒有我不清楚, 只有蘋果內部的開發人員知道, 但如果真的 Framework 有最佳化, 那重新編譯後應該是要變快的.

舉個例子來說, Java SE 1.5、1.6 是兩個不同版號的平臺, 簡單說 1.6 除了擁有 1.6 才有的新 API 之外, 同樣的也擁有 1.5 的所有 API. 舉這個例子能證明什麼? 很簡單, 只要把用 1.5 開發出的軟體的原始碼, 原封不動的拿到 1.6 去重新編譯和執行, 可以發現 1.6 平臺下運作的確比 1.5 來得快, 這就可以說是所謂 Framework 和 API 的改進.
也就是 ==> 開發人員不需要更動原始碼, 只要 Framework 和 API 改進, 性能一樣會提升.

另外, 寫過 GUI 的人應該都知道 GUI 本身就是個多執行緒, 使用者觸發事件的偵測、畫面的更新、資料的同步, 這些都要靠多執行緒才能完成. 所以如果 GCD 真的這麼好, Apple 把 GCD 拿來改進 Cocoa Framework 中的 GUI 元件 API 也很符合 common sense 吧? 同樣的, 如果 OpenCL 這麼好, 為什麼不拿來改進 Cocoa Framework 中其它適合用 OpenCL 改進的 API 呢?
當然這只是我的猜測, 實際上 Cocoa-64 有沒有做這樣的最佳化我不曉得, 只是我會這樣推論是有根據的.

OK，我懂你的說法。你的意思是說同樣的軟體跑在10.5和10.6，雖然kernel一樣，但是因為Cocoa Framework的改進而得到效能的提升。是吧？我認為有可能，但這應該來自Framework本身自己的改進而不會和新加入的GCD或OpenCL有關。這兩個技術都和底層硬體有關，我的經驗是整合底層有關的東西在上層是最麻煩的，除了compile的環境可能要多加幾個library進來外，根據新加入的API改寫部份，甚至整個程式也不可免。我想這就是蘋果花了一年搞10.6的部份原因之一，如果只改進Framework本身，應該花不了蘋果這麼久的時間。

MarsPing

119分

74樓

MarsPing

個人積分：119分

文章編號：14467696

可能大家都因為某些原因, 沒表達清楚, 所以讀的人沒有了解寫的人的本意, 才會導致幾個爭論的點.

gate2 wrote:
OK，我懂你的說法。你的意思是說同樣的軟體跑在10.5和10.6，雖然kernel一樣，但是因為Cocoa Framework的改進而得到效能的提升。是吧？我認為有可能，但這應該來自Framework本身自己的改進而不會和新加入的GCD或OpenCL有關。

這部份的理由我不是很懂耶?? 為什麼在上層的 Cocoa Framework, 不能在改寫 API 的時候, 於 API "內部" 使用比較底層的 GCD 和 OpenCL? (原諒我寫的比較饒舌, 我是為了想表達清楚) 換句話說使用者使用的 Cocoa 提供的 API, 如: 顯示界面元件的部份, 可能已經是使用過 GCD 和 OpenCL 最佳化的.

小弟對 Java 比較熟悉, 舉個 Java 的例子, 假設我今天使用了某個人所寫的數學運算函式庫, 實際上我在使用這套函式庫的時候只看得到函式庫所提供的 API, 我並不曉得它其實是使用 JNI (Java Native Interface) 去撰寫, 也就是說, 這套函式庫呼叫了較底層的 C 語言函式庫.
所以我不懂, 為什麼沒辦法使用 GCD 和 OpenCL 去最佳化 Cocoa Framework??

至於為什麼會去討論到這個假設性的問題? 是因為前輩您先前說了

gate2 wrote:
問題是你目前手邊有多少第三方軟體加入GCD和OpenCL? 將來有多少廠商會為了GCD和OpenCL改寫自己的軟體? 如果改寫後再拿出來賣錢有人要買單嗎?

小弟只是想說, 如果同樣的軟體, 在正式 support GCD 和 OpenCL 之前, 可以先透過 Recompile 成 64-bit, 卻又可以獲得性能上的改進, 這何樂而不為? 當然這也得 Cocoa Framework 有如先前所討論, 真的有對 GCD 和 OpenCL 最佳化.

gate2 wrote:
我想這就是蘋果花了一年搞10.6的部份原因之一，如果只改進Framework本身，應該花不了蘋果這麼久的時間。

不過... 這個... orz...
我相信蘋果有大幅度的去改寫在 Snow Leopard 裡頭的程式... 我沒有說他們只新增了 GCD 和 OpenCL 的意思啊囧...

總之... 不管 64-bit Cocoa Framework 究竟如何, 10.6 整體的流暢度都比在 10.5 時好上太多~

gate2

0分

75樓

gate2

個人積分：0分

文章編號：14474098

MarsPing wrote:
這部份的理由我不是很懂耶?? 為什麼在上層的 Cocoa Framework, 不能在改寫 API 的時候, 於 API "內部" 使用比較底層的 GCD 和 OpenCL? (原諒我寫的比較饒舌, 我是為了想表達清楚) 換句話說使用者使用的 Cocoa 提供的 API, 如: 顯示界面元件的部份, 可能已經是使用過 GCD 和 OpenCL 最佳化的.

小弟對 Java 比較熟悉, 舉個 Java 的例子, 假設我今天使用了某個人所寫的數學運算函式庫, 實際上我在使用這套函式庫的時候只看得到函式庫所提供的 API, 我並不曉得它其實是使用 JNI (Java Native Interface) 去撰寫, 也就是說, 這套函式庫呼叫了較底層的 C 語言函式庫.
所以我不懂, 為什麼沒辦法使用 GCD 和 OpenCL 去最佳化 Cocoa Framework??

MarsPing wrote:
小弟只是想說, 如果同樣的軟體, 在正式 support GCD 和 OpenCL 之前, 可以先透過 Recompile 成 64-bit, 卻又可以獲得性能上的改進, 這何樂而不為? 當然這也得 Cocoa Framework 有如先前所討論, 真的有對 GCD 和 OpenCL 最佳化.

如果你認為SL的 Cocoa Framework可能已經是使用過 GCD 和 OpenCL 最佳化的, 可以先透過 Recompile 成 64-bit, 卻又可以獲得性能上的改進. 那就必須找出相關的證據支持你的假設,而不是追著我問為什麼你的假設不能為真.我從目前為止看到的文件都沒有看到相關的說法.

MarsPing

119分

76樓

MarsPing

個人積分：119分

文章編號：14478251

gate2 wrote:
如果你認為SL的 Cocoa Framework可能已經是使用過 GCD 和 OpenCL 最佳化的, 可以先透過 Recompile 成 64-bit, 卻又可以獲得性能上的改進. 那就必須找出相關的證據支持你的假設,而不是追著我問為什麼你的假設不能為真.我從目前為止看到的文件都沒有看到相關的說法.

我沒追著前輩問這個問題啊~
我只是做了個可能發生的假設, 去證明假設為真的確需要證據, 但去否定假設的存在也是需要證據.
統計學中的假設檢定不就是可以這麼玩的!?

由於前輩斬釘截鐵認定不可能, 我以為前輩認定這樣的情況不可能發生, 是因為我對 Mac OS X 10.6 實際運作, 或是開發流程, 或是甚至是我有軟體開發基礎上認知的問題存在.
而前輩正好看到我有這樣的盲點在, 有所本於是堅決的否定這種假設的可能性.

Cocoa 不是個 Open Source Project, 這在之前也提過了,
除了在這個專案裡頭的人, 沒人知道到底 Cocoa 是如何實作出來的. 因此就算我猜測在 10.6 的 Cocoa 有了這樣的內部改善, 也不為過吧?

我想我前面的發言, 應該沒有對任何未知的事實有過度的武斷與評論, 諸如 "一定是這樣這樣" 或是 "不是那樣那樣" 這般的情形應該沒在我的敘述中出現, 對吧?

誠如小弟所言, 來這發文, 是來討論交流的, 是來分享自己知道的, 學習自己不知道的, 完全沒針對任何人或筆戰的意思.
會對前輩提出問題, 單純只是為了了解前輩您敘述的內容, 有哪些是我不懂的部份, 這樣才能有自我學習的空間. 如果造成您的困擾, 小弟感到很抱歉, 也不繼續追問下去就是了 ^^

最後, 謝謝前輩抽空回答小弟從第 68 篇的第一個問題以來的所有問題.
不管前輩有沒有正面回應我的問題, 或多或少小弟都從前輩的言論中學到了不同的看法與想法.

sympholin

67分

77樓

sympholin

個人積分：67分

文章編號：14526318

Cullegg wrote:
因為是Apple自己說的：
Snow Leopard 支援 64 位元，JavaScript 的處理速度因此提升 50%。
Finder 的程式碼用 Cocoa 整個重新撰寫，以充分運用 Mac OS X 中的所有現代化技術。包括對 64 位元的支援和 Grand Central Dispatch。它從頭到尾都更加反應靈敏，而 Finder 也具有更快速的效能。

這些都是真的呀！使用者也都可以感受得到速度有各種程度的提昇，測試結果也都能驗證得出來。

還有，你自己說的，Leopard 讓Vista很難看，Win7總算救回這一點，說起來，明明Win7就是Vista的補完版（各PC廠出的Vista不是很多都強調可以免費換成Win7嗎？），怎麼被你說得反而SL才是補完版？

我認為應該說，10.6是10.7的先行版，而且，目標並不是使用者，而是軟體業者。藉由這一版，把64bit的驅動程式和應用程式引出來（Adobe Photoshop跑大圖的速度才拼得過Win 64bit版），也誘使大家從原本難搞又容易出錯的multi-thread 設計模式轉到GCD的思考和設計模式，另外就是開始嘗試用Open-CL來提昇多媒體工程演算的速度。

這兩者都需要developer花很多時間去學習和適應，負擔已經夠重了，如果10.6又加上一堆新功能，改變一堆API，那對軟體人員未免太殘酷了。

雪豹另一個隱身於底層的大變革是編譯器也改了，不再用GCC，改用Apple強力加持的（也是open source）LLVM。據Apple內部測試，編譯速度、object碼的大小、以及軟體執行速度各方面都比GCC好得多。是的，同樣軟體碼在雪豹上重新編譯一次就有可能跑得更快。另外，這個編譯器有一些Apple加進去的延伸功能，會讓程式撰寫者更容易運用GCD的功能。

說到這個GCD，有人質疑說，誰會為它改寫程式？
但依照行家的分析，GCD是個革命性的創新，你不用，你就得辛苦的自己去管理執行線緒的多工整合，別人卻可以很輕鬆、省時地依賴GCD來達到95%以上的多工效益，code比你少、bug比你少、線緒互鎖造成軟體死當的可能幾乎沒有，使用者還會覺得整體系統的反應更靈敏，不會被那種重量級傳統多線緒軟體給拖垮，而且是越複雜的軟體得利越多。

我敢大膽說，很快就可以看到一堆運用GCD的Mac專屬軟體。跨平台的軟體就很難說，只為Mac而改寫那些原先統一於pthread架構的多工緒程式，很不划算。也許，Apple會考慮把GCD技術放出來吧！