【?】有這種程式嗎

[gwochern]

purk兄,現在的電腦已無法再跳出舊電腦的陰霾了...
如果你以前是比爾蓋茲的夥伴的話,把你的想法告訴他,
可能現的電腦就又不一樣,cpu的管線是一個低層的東西,
你要做的程式是比cpu的管線高,這就像網路7層一樣,
cpu的管線是為了,提高CPU在執行機器碼的速度,所以不可混合一談

[VicLin]

最初由 gwochern 發表
purk兄,現在的電腦已無法再跳出舊電腦的陰霾了...
如果你以前是比爾蓋茲的夥伴的話,把你的想法告訴他,
可能現的電腦就又不一樣,cpu的管線是一個低層的東西,
你要做的程式是比cpu的管線高,這就像網路7層一樣,
cpu的管線是為了,提高CPU在執行機器碼的速度,所以不可混合一談

比爾蓋子是玩軟體起家的吧= =
不是搞硬體起家的

[Javen]

大家似乎都把焦點放在程式的大小, 但是事實上問題並不在這裡.

一隻程式的效率除了大小之外, 最重要的莫過於"執行過程".

這個解釋起來, 可能不是三言兩語能夠解釋清楚.

舉個例子來說好了, 假設桌上有一疊文件要排序, 你會怎麼做呢? 1. 看指導手冊? 2.運用"常識"?
無論你用上述哪一個方法, 其實都在"執行"程式. 只不過, 來源不同.

再來呢, 假設手冊告訴你, 你有 N 份文件, 就必需先騰出桌面上 N 個空間以利排序, 然後先把文件全部攤開, 在一個一個從最大到最小的疊起來. 你覺得這樣有效率如何?

再來, 我們的常識告訴我們, 其實不用那麼麻煩, 我只需要 2~3 個空間就可以執行這樣排序的動作, 先把第一份拿到另一疊, 再來看第二份是比前一份大還是小, 小的話就往上疊, 大的話就往下疊... 以此類推. 那麼, 這個方法真的比較有效率嗎?

或許你會說, 第一個方法比第二個方法有效率可能是當文件很多的時候. 若文件不超過 10 件, 那麼我用第二個方法會比第一個方法好很多, 最起碼, 我不需要清桌面 (別忘了, 清理桌面也是"執行"的一部份) 或是找一張更大的桌子來擺這十份文件...

我個人認為目前這些大覺得沒有效率的程式的問題就出在程式設計師, 然而要算出一個演算法真正所需的時間其實並不是那麼簡單. 更遑論發展多種演算法然後觀察他們的效率. 也就是說, 現在的軟體品管因為硬體進步的關係愈來愈不受重視了(只 PC 而言).

我相信若今日 Windows 作業系統仍然動輒 1~2GB 但是效率及穩定性與其它的 OS 有得拼的話, 那誰會在乎那 1~2 GB ?

[purk]

http://forum.pcdvd.com.tw/showthread...hreadid=190575

[xbug]

>我舉個例子好了 例如 我們將英文的ATCG 直接跟鹼基的ATCG對應 然後將鹼基
>對應成01碼 也就是A鹼基對應01 C鹼基對應00 T鹼基對應11 G鹼基對應10 那
>當我們輸入 英文字 CAT時假設原來目前的01編碼 是出現 00 01 11 好了那
>他是不是要佔去6個bits 那變成類生物編碼可以縮小成0011 變成4個bit 但是
>經過解譯都是同樣的結果
這個例子中假設每個"鹼基"都對應2bit, 所以"生物編碼"的結果0011去解譯時可以回推成 00 01 11... 但是, 如果不是每個"鹼基"都是 2 bit 呢?!
也就是說如果 A鹼基=101 T鹼基=1 C鹼基=10 G=01, 那結果會如何?
而 x86 cpu 指令集就是這種指令長度不固定的情況~

[zxczzz]

最初由 purk 發表
嗯 看來我沒有說清楚 嗯我的說法是說 編寫程式 可以像打一篇文章一般 但是 由一個特殊的編譯的程式 (程式寫好不事都要編譯程式嗎) 將他轉成01碼的時候 可以造成較為精簡的編碼
然後程式執行時由cpu的設計或由os等其他東西的支援(最好是cpu啦) 可以將一段01碼 多次讀取但是讀取的位置不同 這就造成了出來的結果不同 另外由於cpu的配合 可以出現每個cpu的管線 分別處理不同讀取的01碼 然後最後交給最終匯整的元件做出輸出的動作

嗯希望大家看的董我的意思

thx

我比較了解你的意思了,我覺得你的想法用軟體的方式應該達不到,
不管什麼軟體都需要經過CPU執行,要用不同的方式解讀同一段程式碼,
必須多經過一道解讀程式碼的手續,不如直接將未經過編碼的程式丟到CPU執行,
若使用硬體來做解讀程式碼的工作,我覺得應該可行,但會增加硬體設計的的困難,其實好像也有類似的東西,電腦的平行處理,多CPU系統,採取的方式應該和你的想法差不多,像超級電腦深藍,就擁有百多顆的處理器,但他們的方式應該不是用不同的讀取方式,來讀同一段程式碼,而是將一段程式拆解成不同的部分,丟到不同的處理器做運算,然後再將結果整合起來.

[cat_devil]

近來聲浪不小的"格網"
似乎就是這樣的運算處理方式..

[purk]

某甲 2003/3/1 上午 01:34 某乙 兄 我不懂你說的意思呢 可以解說一下嗎
thx

某乙 2003/3/1 上午 01:35 什麼?


某甲 2003/3/1 上午 01:35 那個 程式的問題

某乙 2003/3/1 上午 01:36 哦.. 就是 x86 cpu 指令集,
每個指令的長度不是固定的呀


某甲 2003/3/1 上午 01:36 為何 如此設計

某乙 2003/3/1 上午 01:37 一部份是為了舊電腦的相容性

某甲 2003/3/1 上午 01:38 嗯 那應該可以用那個 來作 特性轉換

某乙 2003/3/1 上午 01:38 另一部份則是指令特性的關係

某甲 2003/3/1 上午 01:38 我再想啦 我 今天問了 有人說可以

某乙 2003/3/1 上午 01:39 可以是可以, 只不過沒什麼好處吧了

某甲 2003/3/1 上午 01:41 有阿 就像我說的 cat 如果 用心的編碼
只要4個 bit 舊的或許要6個 那 如果
cpu有36到管線 那 我的編碼
至少可以先跑9到以上的程式 但是就的
只能跑6到 不是嗎

某乙 2003/3/1 上午 01:42 沒錯, 但是這種方法有資料相依性的關係,
也就是說如果前沒有解出來,後面就一定不能執行?
吧....


某乙 2003/3/1 上午 01:43 可是現在的cpu超管線已經克服資料相依性的問題?
,
照你的那個做法只能減少大小,可是速度卻會變的?
慢


某甲 2003/3/1 上午 01:43 不一定阿 那個 有點項intel目前ht的功能
但又不全部都是 它可以相依也可以獨立阿

某乙 2003/3/1 上午 01:44 那就是說cpu還要另外去分辦現在讀進入來的資料?
不是壓縮的嚕?

某乙 2003/3/1 上午 01:45 那怎麼去分辨?

某甲 2003/3/1 上午 01:45 嗯 有兩個 辦法 一個 是 設計新的cpu 一個是
由os的 kernel 去做

某甲 2003/3/1 上午 01:45 他也不是壓縮

某乙 2003/3/1 上午 01:46 我的意思是說.. 如果有一筆資料 0011 cpu
讀進來, 怎麼知道 1100 是可以直接執行的,
還是是要解壓縮的

某甲 2003/3/1 上午 01:47 這樣說好了 他是一串的 01碼不是嗎
當kernel(不軟體或硬體的) 讀到一串特殊的01碼
就知道 這是一串程式 他要執行
然後我一串常常的程式碼內 包含很多的
這種開始的 程式碼
但是這些開始的程式碼本身也是其他程式碼的
程式碼

某乙 2003/3/1 上午 01:49 嗯?

某甲 2003/3/1 上午 01:54 我舉例好了 以你剛說的 假設 kernel
知道只要是001開頭的就是起始好了
那一串 0010011110010100111100 那它可以看到
4個001 那這段程式 可以被當成有4個程式在工作

某乙 2003/3/1 上午 01:55 假設:
一串特殊的01碼 = 1111
但是這些開始的程式碼本身也是其他程式碼的
程式碼=0101 1111 0000100


^^^^ ^^^^ ^^^^^^^^


1 2 3
1 = 其它程式碼
2 = 特殊碼
3= 其它程式碼
怎麼辨識 1 = 0101, 而不是 01011 or 01011111

某甲 2003/3/1 上午 01:55 當那串01被讀入cpu後
或許可以放在站存區或快取 然後 快速的 讀取4次
而不用在外求

某乙 2003/3/1 上午 01:58 ok....我了解你的意思.... 就像你說的 001
是特殊碼, 問題就在這 001 是固定的嗎?!
也就是說只要cpu看到001就知道它是特殊碼?!
如果是這樣, 那跟現在的一般cpu指令有何不同?

某甲 2003/3/1 上午 02:00 跟線同的 再於 一次只能一串 然後出來一個解
但是 新的 可以一串進去
但是可能有包含多個獨立的問題 然後
丟出多個解

某甲 2003/3/1 上午 02:04 這樣可以嗎

某乙 2003/3/1 上午 02:04 是沒錯, 但是很慢呀....
001 001 111 00101 001 11100
^^^ ^^^ ^^^ ^^^^^ ^^^ ^^^^^
1 2 3 4 5 6
基本上 cpu 還是依 123456 的順序執行, 因為 1
可能有多個解, 所以不可能先執行 2以後的東西


某乙 2003/3/1 上午 02:05 你說的方法是可以做得到的,
但是我認為最大的問題在於速度

某甲 2003/3/1 上午 02:07 但是 cpu的 管線深度 就可以做到 如此阿
不是 1 開始工作後 當1工作道地2層的管線時
然後2開始工作 然後 再來依序
這是說如果要用目前的cpu來做的話

某乙 2003/3/1 上午 02:09 是呀, 但是目前的 cpu 指令是固定的呀.....
那也就是除非你的特殊碼也是固定的...
也就是說以目前 cpu 來說只是 "新增的指令"
而已


某乙 2003/3/1 上午 02:10 如果指令不固定 cpu 無法預測結果


某甲 2003/3/1 上午 02:10 所以說以目前的化 要用os的支援 讓os 去 達到
可以辨識特殊碼 然後給cpu做的能力
我是這麼想啦

某甲 2003/3/1 上午 02:12 如果 下一代的cpu 或許 可以直接設計如此
然後 再針對不01碼的組合 做出特殊指令集
或許速度會更快

某乙 2003/3/1 上午 02:12 其使x86cpu本身就有很多類似的指令了


某乙 2003/3/1 上午 02:13 有呀, 像 mmx 之類的都算是呀

某甲 2003/3/1 上午 02:14 對阿 但是我是說
因為這套是由模仿生物的atcg的改良出來的
或許可以參考 細菌的 atcg 做出特殊的加速部分

某乙 2003/3/1 上午 02:15 嗯

[ivantw]

看了很久都看不懂，一直不了解這個Idea要運用在什麼場合，小弟針對現有所認知的電腦作闡述，你的問題牽涉處理器及軟體開發等層面，自認涉獵不夠全面，現在稍微廢言一下，希望有所幫助。

[1] 站在精簡程式碼的角度來看，這個方法是不可行的。原因在於機械碼每一個指令都是相互獨立的，並不像DNA其自有之變異性，可以藉由一個DNA化出多個蛋白，機械碼之於處理器，就如同士兵對連長是一個口令一個動作。

[2] 人類的思考好比多台慢速電腦平行運算（好比千百萬部相互連結運算），雖然一般邏輯數學等運算，人類思考速度遠低於電腦許多，但若需要大量平行運算的時候，這時還是人腦較電腦強（如下圍棋，人腦連儲存都是平行運算處理。）。無論現代電腦多麼精進，在平行運算方面還是非常脆弱的，因此若是由處理器的微程式碼/機械語言指令集來下手，要能像生物一般演化，短時間內我想還是辦不到的，除了這樣的架構太過於複雜，成本太高，需要這麼強大平行處理的場合也不多。

[3] 以PC而言，約莫在486時代包含486之前，由於處理器運算速度不夠，作業系統也粗糙而老舊，因此在撰寫程式時，就特別要考慮程式執行時演算效能及資源的使用與分配是否合理。否則開發出來的軟體不是資源不足，就是效能太差根本無法使用。而當硬體越加進步之後，這個情況改變了，人們認為強大硬體可以不用讓程式撰寫人員像以前那樣注重程式語言的演算法。加上物件導向語言的崛起，其主要用意除了縮短程式開發的週期外，透過各種物件導向的元件使用，使得程式設計師的資源更為充足也是一個主要原因，這時候探討的不再是如何最佳化程式，而是如何寫出好的Idea的程式，以及如何良好的管理與撰寫程式，除非有某部分程式需要好的效能，才會考慮程式的最佳化或以低階語言撰寫該函式（事實上編譯器會針對原始程式在編譯時作最佳化，至於最佳化的程度則是各家編譯器皆不同）。

[4] 我不知道有關要用DNA變異的方法，你想運用在什麼場合。建議這一點你能夠說明清楚一點，我想這樣大家討論的方向會更清楚吧。

[ivantw]

最初由 purk 發表
..恕刪..

某甲 2003/3/1 上午 02:04 這樣可以嗎

某乙 2003/3/1 上午 02:04 是沒錯, 但是很慢呀....
001 001 111 00101 001 11100
^^^ ^^^ ^^^ ^^^^^ ^^^ ^^^^^
1 2 3 4 5 6
基本上 cpu 還是依 123456 的順序執行, 因為 1
可能有多個解, 所以不可能先執行 2以後的東西

..恕刪..

管線通常搭配指令預測，只要有一個預測錯誤，進入管線的指令就全部重來了，因此預測錯誤太多，處理器效能反而會大幅下降慘不忍睹。因此管線數及指令預測搭配是要最佳化的，並不是越大越好，這是錯誤觀念。

大概看了一下你的想法，恐怕預測錯誤會多的慘不忍睹...