arm的cpu會是未來嗎? (第6頁)

yorkwu
個人積分：12分
文章編號：33461468

12分

51樓

2012-01-22 22:13

ReinforceII wrote:
windows 8由X86轉去ARM, 絕對不止是cross-compiling那麼簡單的一件事.
如果只追求correctness,應該真的recompile一次source code便完成了, 可是那種kernel只會嚴重浪費掉那顆CPU的真正潛能.

其實搞不好一次 compile, 但是問題是每個 CPU 都是分開的程式...
換個例子, Android 的程式碼不是 Google 放一次 release 就好了嗎? 為何那麼多家手機公司還延後這麼久才出使用新版本的新機以及新版的更新? 還不就是一大堆的調整和改部份程式以便讓自己的機器能發揮能力。比較上層的可能都沒動, 但是最底層部份免不了多次細部調整。

vincent323

vincent323
個人積分：3分
文章編號：33463147

3分

52樓

2012-01-23 0:23

ReinforceII wrote:
windows 8由X86轉去ARM, 絕對不止是cross-compiling那麼簡單的一件事.

kernel是一切的根本, 是一個極需要追求極限效能的地方.
為了個別CPU做的optimization一定不會少的.
(最簡單, 一般商用軟體, application module極少會由programmer人手做loop unnesting,在kernel中這倒是很常見到的事)

如果只追求correctness,應該真的recompile一次source code便完成了, 可是那種kernel只會嚴重浪費掉那顆CPU的真正潛能.

(小弟公司, 最近正正為了用Xeon, ARM, ATOM那顆CPU作我們未來下一世代server,天天都在吵......)

編kernel本來就要針對硬體去修source code，這有很難理解嗎...

應該這樣說，扯到底層硬體的，幾乎都要修source code，又不是像hello world這種純軟體東西，
到哪裡都能跑，大大可以port一個i2c的module，就了解問題所在了。

至於貴公司會去吵那3顆CPU來做下一世代server，就單純看應用，之前公司一個客戶是老美生物學教授，
他的應用就是要低功耗、野外環境、有GPRS、用電池就能長期記錄處理資料，你會推給他Xeon?

vincent323

vincent323
個人積分：3分
文章編號：33463247

3分

53樓

2012-01-23 0:31

yorkwu wrote:
其實搞不好一次 compile, 但是問題是每個 CPU 都是分開的程式...
換個例子, Android 的程式碼不是 Google 放一次 release 就好了嗎? 為何那麼多家手機公司還延後這麼久才出使用新版本的新機以及新版的更新? 還不就是一大堆的調整和改部份程式以便讓自己的機器能發揮能力。比較上層的可能都沒動, 但是最底層部份免不了多次細部調整。

其實底層不會去動，因為都是在ARM的架構下，這裡你可能誤解了。

會拖很久，單純就是要客製化新軟體或穩定測試，誰敢保證自己做的東西跟google開發平台100%
相容?

底層就是那顆ARM不會動，客製化的硬體越多，越容易有不相容的狀況發生，這都不是底層範圍了。

yohowo

yohowo
個人積分：29分
文章編號：33464243

29分

54樓

2012-01-23 2:12

非常好
現在這個討論串進入了正題了(我要居功一下這個點在這討論串好像是我先提的...

)
那就是軟體的支援

畢竟架構的優秀與否/省電/製程都不見得是處理器能否決定市場的主因
(想想Transmeta，MIPS，或甚至SPARC?)
軟體的支援才是重點

現在就兩派
一是覺得移植有問題
把Windows放到ARM上多年來的累積的優勢就沒有了
而這軟體上的legacy是Windows能不能把現在當紅Android(或甚至iOS?)翻掉的主力

二是覺得移植不會有問題

我是主張一啦
但我是硬體出身的
對底層Kernal/ring-0很不熟
不過我公司內部的聲音讓我認為一是對的
所以帶有成見的用"windows arm difficulty legacy"這幾個關鍵字去估狗了一下
大至瞄了一眼
應該說目前M$自己都沒有出來證實這兩派說法誰是對的

以下隨意抓幾個分析有興趣練英文的可以看看
http://www.mobilemag.com/2011/12/02/windows-8-for-arm-tablets-may-lose-traditional-desktop-mode-support/

http://www.zdnet.com/blog/microsoft/just-how-important-is-desktop-app-support-for-windows-8-arm-tablets/11347

http://arstechnica.com/microsoft/news/2011/12/why-microsoft-should-and-shouldnt-support-the-legacy-windows-desktop-on-arm.ars

http://www.theverge.com/2011/09/16/windows-8-arm-tablets-legacy-apps-microsoft-office/

現在都是在猜
所以兩派都有理
只好等年底Win 8 + ARM的平版正式出來才能定論了!

kamuy

kamuy
個人積分：32分
文章編號：33465069

32分

55樓

2012-01-23 6:48

yohowo wrote:
現在就兩派
一是覺得移植有問題
把Windows放到ARM上多年來的累積的優勢就沒有了
而這軟體上的legacy是Windows能不能把現在當紅Android(或甚至iOS?)翻掉的主力

二是覺得移植不會有問題(恕刪)

我是站在第三方(?)
認為移植的過程會像.NET Framework慢慢溶入Windows那樣
至少在五年內x86與ARM市佔比例，應該不會與目前相差太遠

頂多大概是x86被ARM吃掉可用SoC取代的低功率部份
像EeePC即可滿足需求的使用者這塊
至於其他需要適度高負載運算的PC部份應該影響不大

至於未來
個人推測應該有機會看到，在x86 Host上可執行的ARM Guest環境
或是這個需求直接被JIT取代(這個狀況個人認為是不太可能就是)

不過我看了一些你給的連結
總覺得ARM版的Win8應該比較接近windows phone魔改的東西

當然這都只是推測，沒啥根據就是

vincent323

vincent323
個人積分：3分
文章編號：33469765

3分

56樓

2012-01-23 18:10

yohowo wrote:
現在就兩派
一是覺得移植有問題
把Windows放到ARM上多年來的累積的優勢就沒有了
而這軟體上的legacy是Windows能不能把現在當紅Android(或甚至iOS?)翻掉的主力

二是覺得移植不會有問題

我是主張一啦
但我是硬體出身的
對底層Kernal/ring-0很不熟
不過我公司內部的聲音讓我認為一是對的

技術上一直都沒啥問題，而是兩個平台的應用面本來就有很大的差異，
而且MS早在1x年前就做過ARM的Windows CE，老實說，我不知道怎麼會這麼多人擔心移植問題。

win8就很單純，要多工、效能就x86，要省電就ARM，ARM的fans也不用期待哪天ARM效能會
突飛猛進，把x86打趴在地上，類似架構的power pc已經失敗了。

一切都是看需求，ARM不是未來，他就只是低功耗下可行的解決方案。

題外話，INTEL當初吃下迪吉多時，就做過ARM的東西了，效能還打趴當時所有ARM base CPU，
只是當時行動裝置沒現在這麼流行，他就把ARM的東西打包賣掉了...

yorkwu

yorkwu
個人積分：12分
文章編號：33473911

12分

57樓

2012-01-24 0:54

vincent323 wrote:
題外話，INTEL當初吃下迪吉多時，就做過ARM的東西了，效能還打趴當時所有ARM base CPU，
只是當時行動裝置沒現在這麼流行，他就把ARM的東西打包賣掉了...

其實現在付錢給 ARM 買 IP 的公司裡面, Intel 也還是前幾名...
(Intel裡面很多機具也不可能全部改用自己的處理器啊)

移植 OS 本來就不是問題, 不過要保持軟體相容性並且還要跑得很好比較複雜.
要是微軟其實只做到和以前 WinNT 時代一樣的程度(多種平台, 各自跑不同的執行檔)那也是早就做到了, 這一定沒問題.
但是顯然可能有些使用者並不懂這些, 可能會有錯誤的期待(就像錯誤的把 EeePC 當作全功能筆電), 這樣對 Win8 能否擊敗 iPad(3 or 4) 就是問題了(還是有人期望他能光復 iPad 的"失土"), 算了, 也許這也不是問題, 打不過也沒差... 至少我是做壁上觀啦! 我覺得說實在 iPad 還真是不錯的產品...
至少, Win8 for PC 還能慢慢取代掉舊有的 Windows 版本, 這樣也就夠了, 整個 Windows 平台還佔有 92%, 光替代就夠賺了.

vincent323

vincent323
個人積分：3分
文章編號：33475471

3分

58樓

2012-01-24 7:00

yorkwu wrote:
其實現在付錢給 ARM 買 IP 的公司裡面, Intel 也還是前幾名...

很好奇INTEL付錢給ARM買了啥IP回來做哪些產品能買到前幾名，最近沒聽過I有推ARM SOC的東西。

話說回來，INTEL當初把迪吉多的StrongARM買下來時，就不需要跟ARM這家公司買IP了，
後來出了一系列ARM base的Xscale CPU，當時叫好不叫座，最後INTEL乾脆把這系列的專利通通賣給
Marvell，哪知道最近幾年ARM又紅回來，應該是失算。

yorkwu wrote:
(Intel裡面很多機具也不可能全部改用自己的處理器啊)

INTEL裡面的機具，肯定可以完全用I家的處理器，但除非INTEL開家分公司或新部門專門作機具，
不然還是買機具比較划算，有能力不代表一定要去做，IBM就是最好的例子。

INTEL做的東西，多到超乎一般電腦使用者的想像，DSP、CPU都有自家產品，
I不是靠x86 CPU起家的，工業會用到的處理器，大概都逃不過I的魔掌。

yorkwu

yorkwu
個人積分：12分
文章編號：33481476

12分

59樓

2012-01-24 20:55

vincent323 wrote:
很好奇INTEL付錢給ARM買了啥IP回來做哪些產品能買到前幾名，最近沒聽過I有推ARM SOC的東西。

我有根據的:
http://nccc.cool3c.com/article/55042

Intel 也有做像是 SSD 之類, 裡面有些控制器恐怕免不了用ARM...大概付出的權利金就是在這方面

vincent323 wrote:
INTEL裡面的機具，肯定可以完全用I家的處理器，但除非INTEL開家分公司或新部門專門作機具，

我倒是有興趣閣下的根據在哪?
如果說"很多是"那應該沒問題, 但是完全是個人是不相信的...

bluesystem

bluesystem
個人積分：2058分
文章編號：33483806

2058分

60樓

2012-01-24 23:51

yohowo wrote:
非常好
現在這個討論串進入了正題了(我要居功一下這個點在這討論串好像是我先提的...)
那就是軟體的支援

畢竟架構的優秀與否/省電/製程都不見得是處理器能否決定市場的主因
(想想Transmeta，MIPS，或甚至SPARC?)
軟體的支援才是重點

現在就兩派
一是覺得移植有問題
把Windows放到ARM上多年來的累積的優勢就沒有了
而這軟體上的legacy是Windows能不能把現在當紅Android(或甚至iOS?)翻掉的主力

二是覺得移植不會有問題

我是主張一啦
但我是硬體出身的
對底層Kernal/ring-0很不熟
不過我公司內部的聲音讓我認為一是對的
所以帶有成見的用"windows arm difficulty legacy"這幾個關鍵字去估狗了一下
大至瞄了一眼
應該說目前M$自己都沒有出來證實這兩派說法誰是對的

我是支持一的說法.

不過這跟什麼x86還是ARM無關吧? 而是Windows API本身被x86 PC架構綁死的關係.

像OS X基本上幾乎是無痛從IBM POWER架構移到Intel x86架構, 事實證明是
做得到的! 不過在聽過一些微軟如何開發軟體的軼事, 跟長期寫程式, 知道微軟
是如何幫自己不斷的挖坑之後, 我不認為微軟可以像Apple那樣把這個問題處理好.
就算只是x86的Windows, 前後版本都還有太多的相容性問題是經過長時間才有改善
(還不到解決的階段). Windows的包袱太大,也太多了....

kamuy wrote:
我是站在第三方(?)
認為移植的過程會像.NET Framework慢慢溶入Windows那樣
至少在五年內x86與ARM市佔比例，應該不會與目前相差太遠

光一個.Net Framework, 問題就很多了... 微軟不斷的在推更新的東西, 把原有
的東西想法辦排擠掉(而且新東西通常是當紅的團隊做的,當紅的團隊通常都紅不了太久).
我的老同學說他從不學微軟的東西, 也不會浪費錢去買微軟相關技術的書(除非是公費).
因為學會了之後有可能就被微軟遺棄掉了... MFC現在還有人用嗎? VB還是主流嗎?
.Net Framework會不會哪一天又被什麼微軟自己要推的技術給取代掉了? 這實在讓我
樂觀不起來...

好吧, 頂多ARM的Windows有MS Office可以用, 然後呢? 要叫其它原本用C/C++寫
應用軟體的人改用Managed C++或把自己的legacy code改包裝成Managed C++?
對了, Managed C++被微軟用C++/CLI取代掉了~~ 哈!

與失敗為伍者，天天靠盃都是別人的錯。與成功為伍者，天天跟失敗切磋直到不再出錯。