青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

C++ Coder

HCP高性能計算架構,實現,編譯器指令優化,算法優化, LLVM CLANG OpenCL CUDA OpenACC C++AMP OpenMP MPI

C++博客 首頁 新隨筆 聯系 聚合 管理
  98 Posts :: 0 Stories :: 0 Comments :: 0 Trackbacks

2013年4月24日 #

http://bbs.hiapk.com/thread-7959-1-1.html
http://mobile.51cto.com/android-220033_1.htm

在一個Android應用中,主要是由四種組件組成的,這四種組件可參考“Android應用的構成”。
而這四種組件是獨立的,它們之間可以互相調用,協調工作,最終組成一個真正的Android應用。

在這些組件之間的通訊中,主要是由Intent協助完成的。
Intent負責對應用中一次操作的動作、動作涉及數據、附加數據進行描述,Android則根據此Intent的描述,負責找到對應的組件,將 Intent傳遞給調用的組件,并完成組件的調用。
因此,Intent在這里起著一個媒體中介的作用,專門提供組件互相調用的相關信息,實現調用者與被調用者之間的解耦。
例如,在一個聯系人維護的應用中,當我們在一個聯系人列表屏幕(假設對應的Activity為listActivity)上,點擊某個聯系人后,希望能夠跳出此聯系人的詳細信息屏幕(假設對應的Activity為detailActivity)
為了實現這個目的,listActivity需要構造一個 Intent,這個Intent用于告訴系統,我們要做“查看”動作,此動作對應的查看對象是“某聯系人”,然后調用startActivity (Intent intent),
將構造的Intent傳入,系統會根據此Intent中的描述,到ManiFest中找到滿足此Intent要求的Activity,系統會調用找到的 Activity,即為detailActivity,最終傳入Intent,detailActivity則會根據此Intent中的描述,執行相應的操作。

一、抽象描述要描述什么

在Android參考文檔中,對Intent的定義是執行某操作的一個抽象描述(確實很抽象)。我們先來看看這里的抽象描述,到底描述了什么。
首先,是要執行的動作(action)的一個簡要描述,如VIEW_ACTION(查看)、EDIT_ACTION(修改)等,Android為我們定義了一套標準動作:

MAIN_ACTION
VIEW_ACTION
EDIT_ACTION
PICK_ACTION
GET_CONTENT_ACTION
DIAL_ACTION
CALL_ACTION
SENDTO_ACTION
ANSWER_ACTION
INSERT_ACTION
DELETE_ACTION
RUN_ACTION
LOGIN_ACTION
CLEAR_CREDENTIALS_ACTION
SYNC_ACTION
PICK_ACTIVITY_ACTION
WEB_SEARCH_ACTION
此外,我們還可以根據應用的需要,定義我們自己的動作,并可定義相應的Activity來處理我們的自定義動作。

其次,是執行動作要操作的數據(data),Android中采用指向數據的一個URI來表示,如在聯系人應用中,一個指向某聯系人的URI可能為:content://contacts/1。
這種URI表示,通過 ContentURI這個類來描述,具體可以參考android.net.ContentURI類的文檔。

以聯系人應用為例,以下是一些action / data對,及其它們要表達的意圖:
VIEW_ACTION content://contacts/1-- 顯示標識符為"1"的聯系人的詳細信息
EDIT_ACTION content://contacts/1-- 編輯標識符為"1"的聯系人的詳細信息
VIEW_ACTION content://contacts/-- 顯示所有聯系人的列表
PICK_ACTION content://contacts/-- 顯示所有聯系人的列表,并且允許用戶在列表中選擇一個聯系人,然后把這個聯系人返回給父activity。例如:電子郵件客戶端可以使用這個Intent,要求用戶在聯系人列表中選擇一個聯系人

另外,除了action和data這兩個重要屬性外,還有一些附加屬性: 
category(類別),被執行動作的附加信息。例如 LAUNCHER_CATEGORY 表示Intent 的接受者應該在Launcher中作為頂級應用出現;而ALTERNATIVE_CATEGORY表示當前的Intent是一系列的可選動作中的一個,這些動作可以在同一塊數據上執行。
type(數據類型),顯式指定Intent的數據類型(MIME)。一般Intent的數據類型能夠根據數據本身進行判定,但是通過設置這個屬性,可以強制采用顯式指定的類型而不再進行推導。
component(組件),指定Intent的的目標組件的類名稱。通常 Android會根據Intent 中包含的其它屬性的信息,比如action、data/type、category進行查找,最終找到一個與之匹配的目標組件。但是,如果 component這個屬性有指定的話,將直接使用它指定的組件,而不再執行上述查找過程。指定了這個屬性以后,Intent的其它所有屬性都是可選的。
extras(附加信息),是其它所有附加信息的集合。使用extras可以為組件提供擴展信息,比如,如果要執行“發送電子郵件”這個動作,可以將電子郵件的標題、正文等保存在extras里,傳給電子郵件發送組件。

總之,action、 data/type、category和extras 一起形成了一種語言。
這種語言使系統能夠理解諸如“查看某聯系人的詳細信息”之類的短語。
隨著應用不斷的加入到系統中,它們可以添加新的action、 data/type、category來擴展這種語言。
應用也可以提供自己的Activity來處理已經存在的這樣的“短語”,從而改變這些“短語”的行為。

二、Android如何解析Intent

在應用中,我們可以以兩種形式來使用Intent:
直接Intent:指定了component屬性的Intent(調用setComponent(ComponentName)或者setClass(Context, Class)來指定)。通過指定具體的組件類,通知應用啟動對應的組件。
間接Intent:沒有指定comonent屬性的Intent。這些Intent需要包含足夠的信息,這樣系統才能根據這些信息,在在所有的可用組件中,確定滿足此Intent的組件。
對于直接Intent,Android不需要去做解析,因為目標組件已經很明確,Android需要解析的是那些間接Intent,通過解析,將 Intent映射給可以處理此Intent的Activity、IntentReceiver或Service。
Intent解析機制主要是通過查找已注冊在AndroidManifest.xml中的所有IntentFilter及其中定義的Intent,最終找到匹配的Intent。在這個解析過程中,Android是通過Intent的action、type、category這三個屬性來進行判斷的,判斷方法如下:
如果Intent指明定了action,則目標組件的IntentFilter的action列表中就必須包含有這個action,否則不能匹配;
如果Intent沒有提供type,系統將從data中得到數據類型。和action一樣,目標組件的數據類型列表中必須包含Intent的數據類型,否則不能匹配。
如果Intent中的數據不是content: 類型的URI,而且Intent也沒有明確指定它的type,將根據Intent中數據的scheme (比如 http: 或者mailto: ) 進行匹配。同上,Intent 的scheme必須出現在目標組件的scheme列表中。
如果Intent指定了一個或多個category,這些類別必須全部出現在組建的類別列表中。比如Intent中包含了兩個類別:LAUNCHER_CATEGORY 和 ALTERNATIVE_CATEGORY,解析得到的目標組件必須至少包含這兩個類別。

三、應用例子

以下,以Android SDK中的便箋例子來說明,Intent如何定義及如何被解析。這個應用可以讓用戶瀏覽便箋列表、查看每一個便箋的詳細信息。 


  • <manifest
  • xmlns:android="http://schemas.android.com/apk/res/android"
  • package="com.google.android.notepad">
  • <application
  • android:icon="@drawable/app_notes"
  • android:label="@string/app_name">
  • <provider
  • class="NotePadProvider"
  • android:authorities="com.google.provider.NotePad"
  • />
  • <activity
  • class=".NotesList"
  • android:label="@string/title_notes_list">
  •      <intent-filter>
  •        <action android:value="android.intent.action.MAIN"/>
  •        <category android:value="android.intent.category.LAUNCHER"/>
  •       </intent-filter>
  •      <intent-filter>
  •        <action android:value="android.intent.action.VIEW"/>
  •        <action android:value="android.intent.action.EDIT"/>
  •        <action android:value="android.intent.action.PICK"/>
  •        <category android:value="android.intent.category.DEFAULT"/>
  •        <type android:value="vnd.android.cursor.dir/vnd.google.note"/>
  •       </intent-filter>
  •      <intent-filter>
  •        <action android:value="android.intent.action.GET_CONTENT"/>
  •        <category android:value="android.intent.category.DEFAULT"/>
  •        <type android:value="vnd.android.cursor.item/vnd.google.note"/>
  •       </intent-filter>
  •     </activity>
  •   <activity class=".NoteEditor" android:label="@string/title_note">
  •      <intent-filter android:label="@string/resolve_edit">
  •        <action android:value="android.intent.action.VIEW"/>
  •        <action android:value="android.intent.action.EDIT"/>
  •        <category android:value="android.intent.category.DEFAULT"/>
  •        <type android:value="vnd.android.cursor.item/vnd.google.note"/>
  •       </intent-filter>
  •      <intent-filter>
  •        <action android:value="android.intent.action.INSERT"/>
  •        <category android:value="android.intent.category.DEFAULT"/>
  •        <type android:value="vnd.android.cursor.dir/vnd.google.note"/>
  •       </intent-filter>
  •     </activity>
  •   <activity class=".TitleEditor" android:label="@string/title_edit_title" android:theme="@android:style/Theme.Dialog">
  •      <intent-filter android:label="@string/resolve_title">
  •        <action android:value="com.google.android.notepad.action.EDIT_TITLE"/>
  •        <category android:value="android.intent.category.DEFAULT"/>
  •        <category android:value="android.intent.category.ALTERNATIVE"/>
  •        <category android:value="android.intent.category.SELECTED_ALTERNATIVE"/>
  •        <type android:value="vnd.android.cursor.item/vnd.google.note"/>
  •       </intent-filter>
  •     </activity>
  • </application>
  • </manifest>

復制代碼
例子中的第一個Activity是com.google.android.notepad.NotesList,它是應用的主入口,提供了三個功能,分別由三個 intent-filter進行描述:

1、第一個是進入便箋應用的頂級入口(action為android.app.action.MAIN)。類型為android.app.category.LAUNCHER表明這個Activity將在Launcher中列出。
2、第二個是,當type為vnd.android.cursor.dir/vnd.google.note(保存便箋記錄的目錄)時,可以查看可用的便箋(action為android.app.action.VIEW),或者讓用戶選擇一個便箋并返回給調用者(action為 android.app.action.PICK)。
3、第三個是,當type為vnd.android.cursor.item/vnd.google.note時,返回給調用者一個用戶選擇的便箋(action為android.app.action.GET_CONTENT),而用戶卻不需要知道便箋從哪里讀取的。有了這些功能,下面的 Intent就會被解析到NotesList這個activity:

{ action=android.app.action.MAIN }:與此Intent匹配的Activity,將會被當作進入應用的頂級入口。
{ action=android.app.action.MAIN, category=android.app.category.LAUNCHER }:這是目前Launcher實際使用的 Intent,用于生成Launcher的頂級列表。
{ action=android.app.action.VIEW data=content://com.google.provider.NotePad/notes }:
顯示"content://com.google.provider.NotePad/notes"下的所有便箋的列表,使用者可以遍歷列表,并且察看某便箋的詳細信息。
{ action=android.app.action.PICK data=content://com.google.provider.NotePad/notes }:
顯示"content://com.google.provider.NotePad/notes"下的便箋列表,讓用戶可以在列表中選擇一個,然后將選擇的便箋的 URL返回給調用者。
{ action=android.app.action.GET_CONTENT type=vnd.android.cursor.item/vnd.google.note }:和上面的action為pick的Intent類似,不同的是這個Intent允許調用者(在這里指要調用NotesList的某個 Activity)指定它們需要返回的數據類型,系統會根據這個數據類型查找合適的 Activity(在這里系統會找到NotesList這個Activity),供用戶選擇便箋。
第二個Activity是com.google.android.notepad.NoteEditor,它為用戶顯示一條便箋,并且允許 用戶修改這個便箋。
它定義了兩個intent-filter,所以具有兩個功能。

第一個功能是,當數據類型為 vnd.android.cursor.item/vnd.google.note時,允許用戶查看和修改一個便簽(action為 android.app.action.VIEW和android.app.action.EDIT)。
第二個功能是,當數據類型為 vnd.android.cursor.dir/vnd.google.note,為調用者顯示一個新建便箋的界面,并將新建的便箋插入到便箋列表中(action為android.app.action.INSERT)。
      有了這兩個功能,下面的Intent就會被解析到NoteEditor這個activity:

{ action=android.app.action.VIEW data=content://com.google.provider.NotePad/notes/{ID}} :向用戶顯示標識為 ID的便箋。

{ action=android.app.action.EDIT data=content://com.google.provider.NotePad/notes/{ID}}:允許用戶編輯標識為ID的便箋。

{ action=android.app.action.INSERT data=content://com.google.provider.NotePad/notes }:在“content://com.google.provider.NotePad/notes”這個便箋列表中創建一個新的空便箋,并允許用戶編輯這個便簽。當用戶保存這個便箋后,這個新便箋的URI將會返回給調用者。
最后一個Activity是com.google.android.notepad.TitleEditor,它允許用戶編輯便箋的標題。

它可以被實現為一個應用可以直接調用(在Intent中明確設置component屬性)的類,不過這里我們將為你提供一個在現有的數據上發布可選操作的方法。

在這個 Activity的唯一的intent-filter中,擁有一個私有的action: com.google.android.notepad.action.EDIT_TITLE,表明允許用戶編輯便箋的標題。

和前面的view和edit 動作一樣,調用這個Intent 的時候,也必須指定具體的便箋(type為vnd.android.cursor.item/vnd.google.note)。不同的是,這里顯示和編輯的只是便箋數據中的標題。

      除了支持缺省類別(android.intent.category.DEFAULT),標題編輯器還支持另外兩個標準類別: android.intent.category.ALTERNATIVE和
android.intent.category.SELECTED_ALTERNATIVE。

實現了這兩個類別之后,其它 Activity就可以調用queryIntentActivityOptions(ComponentName, Intent[], Intent, int)查詢這個Activity提供的action,而不需要了解它的具體實現;

或者調用addIntentOptions(int, int, ComponentName, Intent[], Intent, int, Menu.Item[])建立動態菜單。需要說明的是,在這個intent-filter中有一個明確的名稱(通過android:label= "@string/resolve_title"指定),在用戶瀏覽數據的時候,如果這個Activity是數據的一個可選操作,指定明確的名稱可以為用戶提供一個更好控制界面。

有了這個功能,下面的Intent就會被解析到TitleEditor這個Activity:

{ action=com.google.android.notepad.action.EDIT_TITLE data=content://com.google.provider.NotePad/notes/{ID}}:顯示并且允許用戶編輯標識為ID的便箋的標題。
posted @ 2013-04-24 14:19 jackdong 閱讀(536) | 評論 (0)編輯 收藏

     摘要: http://www.cnblogs.com/keyindex/articles/1822463.htmlandroid的Handler前言  學習android一段時間了,為了進一步了解android的應用是如何設計開發的,決定詳細研究幾個開源的android應用。從一些開源應用中吸收點東西,一邊進行量的積累,一邊探索android的學習研究方向。這里我首先選擇了jwood的 Stan...  閱讀全文
posted @ 2013-04-24 10:55 jackdong 閱讀(745) | 評論 (0)編輯 收藏

http://www.pin5i.com/showtopic-android-handler.html

一、Handler的定義:

          主要接受子線程發送的數據, 并用此數據配合主線程更新UI.

          解釋: 當應用程序啟動時,Android首先會開啟一個主線程 (也就是UI線程) , 主線程為管理界面中的UI控件,進行事件分發, 比如說, 你要是點擊一個 Button ,Android會分發事件到Button上,來響應你的操作。  如果此時需要一個耗時的操作,例如: 聯網讀取數據,    或者讀取本地較大的一個文件的時候,你不能把這些操作放在主線程中,,如果你放在主線程中的話,界面會出現假死現象, 如果5秒鐘還沒有完成的話,,會收到Android系統的一個錯誤提示  "強制關閉".  這個時候我們需要把這些耗時的操作,放在一個子線程中,因為子線程涉及到UI更新,,Android主線程是線程不安全的,也就是說,更新UI只能在主線程中更新,子線程中操作是危險的. 這個時候,Handler就出現了.,來解決這個復雜的問題 ,    由于Handler運行在主線程中(UI線程中),  它與子線程可以通過Message對象來傳遞數據, 這個時候,Handler就承擔著接受子線程傳過來的(子線程用sedMessage()方法傳弟)Message對象,(里面包含數據)  , 把這些消息放入主線程隊列中,配合主線程進行更新UI。

二、Handler一些特點

        handler可以分發Message對象和Runnable對象到主線程中, 每個Handler實例,都會綁定到創建他的線程中(一般是位于主線程),
        它有兩個作用: (1):  安排消息或Runnable 在某個主線程中某個地方執行, (2)安排一個動作在不同的線程中執行
      
        Handler中分發消息的一些方法
        post(Runnable)
        postAtTime(Runnable,long)
        postDelayed(Runnable long)
        sendEmptyMessage(int)
        sendMessage(Message)
        sendMessageAtTime(Message,long)
        sendMessageDelayed(Message,long)

        以上post類方法允許你排列一個Runnable對象到主線程隊列中,
        sendMessage類方法, 允許你安排一個帶數據的Message對象到隊列中,等待更新.

三、Handler實例

      (1) 子類需要繼承Hendler類,并重寫handleMessage(Message msg) 方法, 用于接受線程數據

      以下為一個實例,它實現的功能為 : 通過線程修改界面Button的內容
  1. public class MyHandlerActivity extends Activity {
  2.     Button button;
  3.     MyHandler myHandler;

  4.     protected void onCreate(Bundle savedInstanceState) {
  5.         super.onCreate(savedInstanceState);
  6.         setContentView(R.layout.handlertest);

  7.         button = (Button) findViewById(R.id.button);
  8.         myHandler = new MyHandler();
  9.         // 當創建一個新的Handler實例時, 它會綁定到當前線程和消息的隊列中,開始分發數據
  10.         // Handler有兩個作用, (1) : 定時執行Message和Runnalbe 對象
  11.         // (2): 讓一個動作,在不同的線程中執行.

  12.         // 它安排消息,用以下方法
  13.         // post(Runnable)
  14.         // postAtTime(Runnable,long)
  15.         // postDelayed(Runnable,long)
  16.         // sendEmptyMessage(int)
  17.         // sendMessage(Message);
  18.         // sendMessageAtTime(Message,long)
  19.         // sendMessageDelayed(Message,long)
  20.       
  21.         // 以上方法以 post開頭的允許你處理Runnable對象
  22.         //sendMessage()允許你處理Message對象(Message里可以包含數據,)

  23.         MyThread m = new MyThread();
  24.         new Thread(m).start();
  25.     }

  26.     /**
  27.     * 接受消息,處理消息 ,此Handler會與當前主線程一塊運行
  28.     * */

  29.     class MyHandler extends Handler {
  30.         public MyHandler() {
  31.         }

  32.         public MyHandler(Looper L) {
  33.             super(L);
  34.         }

  35.         // 子類必須重寫此方法,接受數據
  36.         @Override
  37.         public void handleMessage(Message msg) {
  38.             // TODO Auto-generated method stub
  39.             Log.d("MyHandler", "handleMessage......");
  40.             super.handleMessage(msg);
  41.             // 此處可以更新UI
  42.             Bundle b = msg.getData();
  43.             String color = b.getString("color");
  44.             MyHandlerActivity.this.button.append(color);

  45.         }
  46.     }

  47.     class MyThread implements Runnable {
  48.         public void run() {

  49.             try {
  50.                 Thread.sleep(10000);
  51.             } catch (InterruptedException e) {
  52.                 // TODO Auto-generated catch block
  53.                 e.printStackTrace();
  54.             }

  55.             Log.d("thread.......", "mThread........");
  56.             Message msg = new Message();
  57.             Bundle b = new Bundle();// 存放數據
  58.             b.putString("color", "我的");
  59.             msg.setData(b);

  60.             MyHandlerActivity.this.myHandler.sendMessage(msg); // 向Handler發送消息,更新UI

  61.         }
  62.     }

  63. }
復制代碼
posted @ 2013-04-24 10:35 jackdong 閱讀(394) | 評論 (0)編輯 收藏

2013年3月8日 #

http://maxianhui120.blog.163.com/blog/static/2700629720101130111041369/

嵌入式linux入門學習規劃  

嵌入式Linux操作系統及其上應用軟件開發目標: 
(1) 掌握主流嵌入式微處理器的結構與原理(初步定為 arm9)                                                                                                                    
(2) 必須掌握一個嵌入式操作系統 (初步定為uclinux或linux,版本待定) 
(3) 必須熟悉嵌入式軟件開發 流程并至少做一個嵌入式軟件項目。 
從事嵌入式軟件開發的好處是: 
(1)目前國內外這方面的人都很稀缺。這一領域入門門檻較高,所以非 專業IT人員很難切入這一領域;另一方面,是因為這一領域較新,目前發展太快,大多數人無條件接觸。 
(2)與企業計算等應用軟件不同,嵌入式領 域人才的工作強度通常低一些(但收入不低)。 
(3)哪天若想創業,搞自已的產品,嵌入式不像應用軟件那樣容易被盜版。硬件設計一般都是請其它公 司給訂做(這叫“貼牌”:OEM),都是通用的硬件,我們只管設計軟件就變成自己的產品了。 
(4)興趣所在,這是最主要的。 
從事嵌入 式軟件開發的缺點是: 
(1)入門起點較高,所用到的技術往往都有一定難度,若軟硬件基礎不好,特別是操作系統級軟件功底不深,則可能不適于此 行。 
(2)這方面的企業數量要遠少于企業計算類企業。 
(3)有少數公司經常要碩士以上的人搞嵌入式,主要是基于嵌入式的難度。但大多 數公司也并無此要求,只要有經驗即可。 
(4)平臺依托強,換平臺比較辛苦。 
興趣的由來: 
1、成功觀念不同,不虛度此生,就 是我的成功。 
2、喜歡思考,挑戰邏輯思維。 
3、喜歡C 
C是一種能發揮思維極限的語言。關于C的精神的一些方面可以被概述成 短句如下: 
相信程序員。 
不要阻止程序員做那些需要去做的。 
保持語言短小精干。 
一種方法做一個操作。 
使 得它運行的夠快,盡管它并不能保證將是可移植的。 
4、喜歡底層開發,討厭vb類開發工具(并不是說vb不好)。 
5、發展前景好,適合 創業,不想自己要死了的時候還是一個工程師。 
方法步驟: 
1、基礎知識: 
目的:能看懂硬件工作原理,但重點在嵌入式軟件,特 別是操作系統級軟件,那將是我的優勢。 
科目:數字電路、計算機組成原理、嵌入式微處理器結構。 
匯編語言、C/C++、編譯原理、離散 數學。 
數據結構和算法、操作系統、軟件工程、網絡、數據庫。 
方法:雖科目眾多,但都是較簡單的基礎,且大部分已掌握。不一定全學,可 根據需要選修。 
主攻書籍:the c++ programming language(一直沒時間讀)、數據結構-C2。 

2、 學習linux: 
目的:深入掌握linux系統。 
   方法:使用linux—〉linxu系統編程開發—〉驅動開發和分析 linux內核。先看深,那主講原理。看幾遍后,看情景分析,對照深看,兩本交叉,深是綱,情是目。剖析則是0.11版,適合學習。最后深入代碼。 
主 攻書籍:linux內核完全剖析、unix環境高級編程、深入理解linux內核、情景分析和源代。 
3、學習嵌入式linux: 
目 的:掌握嵌入式處理器其及系統。 
方法:(1)嵌入式微處理器結構與應用:直接arm原理及匯編即可,不要重復x86。 
   (2)嵌 入式操作系統類:ucOS/II簡單,開源,可供入門。而后深入研究uClinux。 
   (3)必須有塊開發板(arm9以上),有條件可參 加培訓(進步快,能認識些朋友)。 
   主攻書籍:毛德操的《嵌入式系統》及其他arm9手冊與arm匯編指令等。 

4、深入 學習: 
   A、數字圖像壓縮技術:主要是應掌握MPEG、mp3等編解碼算法和技術。 
   B、通信協議及編程技術:TCP/IP 協議、802.11,Bluetooth,GPRS、GSM、CDMA等。 
   C、網絡與信息安全技術:如加密技術,數字證書CA等。 
    D、DSP技術:Digital Signal Process,DSP處理器通過硬件實現數字信號處理算法。 
    說明:太多細節未說明,可根據實際情況調整。重點在于1、3,不必完全按照順序作。對于學習c++,理由是c++不只是一種語言,一種工具,她還是一 種藝術,一種文化,一種哲學理念、但不是拿來炫耀得東西。對于linux內核,學習編程,讀一些優秀代碼也是有必要的。 
   注意: 要學會 舉一反多,有強大的基礎,很多東西簡單看看就能會。想成為合格的程序員,前提是必須熟練至少一種編程語言,并具有良好的邏輯思維。一定要理論結合實踐。 
    不要一味鉆研技術,雖然擠出時間是很難做到的,但還是要留點余地去完善其他的愛好,比如宇宙,素描、機械、管理,心理學、游戲、科幻電影。還有一些不 愿意做但必須要做的! 
   技術是通過編程編程在編程編出來的。永遠不要夢想一步登天,不要做浮躁的人,不要覺得路途漫上。而是要編程編程在編 程,完了在編程,在編程!等機會來了在創業(不要相信有奇跡發生,盲目創業很難成功,即便成功了發展空間也不一定很大)。 

   嵌入式 書籍推薦 
   Linux基礎 
   1、《Linux與Unix Shell 編程指南》 
   C語言基礎 
    1、《C Primer Plus,5th Edition》【美】Stephen Prata著 
   2、 《The C Programming Language, 2nd Edition》【美】 Brian W. Kernighan David M. Rithie(K & R)著 
   3、 《Advanced Programming in the UNIX Environment,2nd Edition》(APUE) 
    4、《嵌入式Linux應用程序開發詳解》 
   Linux內核 
   1、《深入理解Linux內核》(第三版) 
    2、《Linux內核源代碼情景分析》毛德操 胡希明著 
   研發方向 
   1、 《UNIX Network Programming》(UNP) 
   2、《TCP/IP詳解》 
   3、《Linux內核編 程》 
   4、《Linux設備驅動開發》(LDD)  
   5、《Linux高級程序設計》 楊宗德著
   硬件基礎 
    1、《ARM體系結構與編程》杜春雷著 
   2、S3C2410 Datasheet 
   英語基礎 
   1、《計算 機與通信專業英語》 
   系統教程 
   1、《嵌入式系統――體系結構、編程與設計》 
   2、《嵌入式系統――采用公開 源代碼和StrongARM/Xscale處理器》毛德操 胡希明著 
   3、 《Building Embedded Linux Systems》   
   4、《嵌入式ARM系統原理與實例開發》 楊宗德著
    理論基礎 
   1、《算法導論》 
   2、《數據結構(C語言版)》 
   3、《計算機組織與體系結構?性能分析》 
    4、《深入理解計算機系統》【美】Randal E. Bryant David O''Hallaron著 
   5、《操作系統:精髓與 設計原理》 
   6、《編譯原理》 
   7、《數據通信與計算機網絡》 
   8、《數據壓縮原理與應用》 

    C語言書籍推薦 
   1. The C programming language 《C程序設計語言》 
    2. Pointers on C 《C和指針》 
   3. C traps and pitfalls 《C陷阱與缺陷》 
盡可能多的編碼,要學好C,不能只注重C本身。算法,架構方式等都很重要。

posted @ 2013-03-08 16:12 jackdong 閱讀(611) | 評論 (0)編輯 收藏

2013年2月19日 #

http://www.csdn.net/article/2013-02-17/2814154-AMD_creat_HSA

摘要:在PC產業日漸頹勢和移動行業方興未艾的大環境下,AMD作為PC CPU芯片行業的兩個供應商之一,如何在上下夾擊的態勢下突出重圍,大家一直拭目以待。經過近兩年的調整,AMD并非沒有出路,他們已經為自己規劃了三個快速發展的機遇:雙核、異構、低功耗。而開放和開源的思維貫穿始終。

開放才是未來

早在2012年,AMD就高調宣布要設計基于64-bit ARM架構的處理器,而為了在2014年處理器問世前打造一條完整的軟硬件生態鏈,AMD更是同ARM一起成立了HSA基金會(異構系統架構基金會)。HSA基金會倡導的是一種更簡單、開放,同時還可以涵蓋PC與移動設備(不光是跨 OS)的標準。目的在于通過基于GPU的并行運算來提升處理器的表現。比如圖像處理器將不僅僅用于圖像、游戲等方面,普通的任務和應用也可以用到它。


圖:HSA幫助從服務器端到移動端提升效率、降低功耗

“雖然用OpenCL這個工業標準已經能達到這種效果,但這樣的做法仍舊太復雜,而且主流的開發者也不容易接受。NVIDIA雖然大力推進自己的CUDA運算架構,不過CUDA和OpenCL是同一層面的技術,而基于私有架構的開發棧終將沒落。”

AMD中國開發合作與解決方案中心總監楚含進坦言,目前AMD所有做的事情都是為將來某一段時間產品集中爆發做技術上系統儲備。在HSA基金會中,其中的廠商從服務器到PC到手機廠商都會有,AMD將幫助各個伙伴更好的去驅動軟件生態系統,促使軟件里面的工具、軟件里面的庫、軟件里面的開發環境讓更多的人更容易的去使用。

“其次,我們將一直致力于降低功耗,這兩年我們會把生態鏈去閉環運營。在中國來說,我們有一個開發團隊會幫助國內的開發人員能夠學會如何在GPU上進行編程;而在技術層面上,我們更希望能夠向著平板電腦這個方向進行過度。 最終目的是在低功耗上推出AMD的一系列產品,x86和ARM雙核并行戰略。”

而從市場的直接反饋結果來看,AMD擁抱開放技術的策略也受到了開發者的一致歡迎。

作為軟件開發人員尤其是學生開發人群,是AMD首先取悅的人群,在前不久舉行的異構編程大賽上,AMD收到了40多個作品,從開發者的關注點來看,他們也正向著云計算、多媒體、移動互聯網應用這些深層次的產品優化的方向,同目前的行業熱點是有很好的契合點的。并且在相當多的參賽作品中,無論是學生本人,還是在導師的帶領下,這些行業還是都比較容易產生有創意或者是有深度有質量的軟件實現的算法或者產品的核心技術,而這些注定是未來軟件公司差異化的核心。

從作品的類型來看,有數據搜索和數據的作品,也有算法優化方面的內容。而在多媒體、圖形圖像方面,比如損失圖像的修復、二維圖像的三維化、圖像的拼接以及細化和分割,這些(技術)在很多領域無論是移動還是多媒體領域有著深遠的意義。

對于此次大賽的結果,楚含進表示,“大賽只是AMD對異構編程技術的一個普及推廣形式。根據以往的大賽經驗,在作品的推廣中,學生是不利的。一般參賽的大部人是年輕人,年輕人有干勁,但是他們有時只見樹木不見森林。如果把大賽中學生的每一件作品拿出來,稍加深化補充,都可以成為一個很好的分子。但是把分子作為一個產品還要花一段時間的。所以AMD一直在思考能不能把學生做的引擎收集起來,不論是計劃上的還是部分實現上的,讓他們能夠沿著這個方向更好的研究下去,產生一些有影響力的,不論是論文還是實際案例,抑或在他們自己的產品中能夠把它延伸到自己研究的領域。”

“因此,從AMD幫助學生開發技術提高來看,會做三件事,第一是與CSDN一起來探討利用學生的自身優勢和他們本身已經完成的工作,繼續能夠指導他們做一些成果出來。我們不是只針對TOP10,甚至是TOP20。第二種是扶植學生能夠真正的發布自己的作品,以及針對于當前工作真正有用的。我們給予他們業務層面的指導。還有一種想法是把他們的某一些業務成果提交給我們的客戶,這樣能把他們轉化為真正的生產力。第三點是我們希望能夠與CSDN形成一個比較切實的基于GPU的異構開發人群,然后把一些作品放在開源的社區來進行一些補充。這個項目本身不會成為一個獨立運行的具有某種功能的產品模塊,但是我們希望過開源社區的力量,把這些產品形成一種相對來說比較獨立通用的一個庫,并提供相應的訪問接口。這樣,越來越多的人就會去很容易的使用它,而且這樣可以真正的培養開發人員尤其學生的軟件產品意識。”

AMD結盟ARM, 橫跨x86和ARM架構?

目前的芯片市場,實際上是有兩大芯片陣營,ARM與x86兩大陣營在博弈。在智能手機出現之前,是通用處理器的天下,這種通用處理器包括ARM、x86。實際上更多領域用的還是通用處理器,通用處理器時代,CPU的設計是個門檻,決定這個公司的成敗。但隨著智能手機和移動互聯的大量實現,決定這個公司的未來是是否具有設計CPU以及設計多核CPU的能力。

“通用處理器的設計已經不再是門檻了,因為ARM已經把整個CPU體系幫你設計完成了。第二,Intel的x86處理器通用處理器也由于開始受到主機的云應用的影響。用戶會問,問什么要用通用處理器來做這種非通用的應用?給我一個理由,這會是一個很大的問題。”從技術層面,這背后其實系統和產品設計日益差異化需求的問題。、

在未來的CPU發展趨勢上也許我們可以看到幾個趨勢:一、像Facebook、Google已經把精力放在整個架構上,希望他們自己的服務器作為行業標準化,個性定制化?開發化,所謂的標準化就是說不需要限定在某種通用處理器,而是需要針對自己應用和系統架構構建專屬系統。二、在移動領域,芯片設計的趨勢是從通用處理器到SoC,而從SoC又逐漸是往專屬領域有獨特要求的處理器演變。這種情況下,生產通用處理器的公司會受到非常非常大的挑戰,那么將來的局面會是,任何一個行業里面的任何一個公司所生產出來的芯片不會是萬能的,應該是在本行業里有獨特的特點,符合行業的趨勢和需求。比如做手機的核心一定是通信功能,做游戲的核心一定是游戲的引擎,做服務器的核心一定是數據處理能力和帶寬和在某個領域具有處理特定需求的能力。

“AMD對于GPU的發展技術上有很獨創的見解,在游戲以及圖形圖像處理上非常的專注,所以這就是AMD能夠走SoC和將來走可定制化專用服務器領域的一個信號”,楚含進表示。

可以看到,目前x86上很多的開源項目是集成在服務器領域里面,而傳統的ARM則是集中在手機領域。兩者本質的區別是x86的開源是集中在通用處理器上,而ARM在完善了基于以linux內核為核心的一套開源系統之后,更多的會布置在專用的領域上,比如基于ARM的多媒體應用、基于ARM的編譯器,以及很多開源項目。隨著開源的項目越來越多,在這個領域就會形成一定的技術門檻,尤其是軟件技術門檻,所以x86面臨的問題就是開發者為什么要用通用處理器去做非通用的事情。在這種大的背景下,如果所有的開源都是為通用服務的話,為什么還要用通用的軟件去搭建一個需要特定處理能力的平臺?所以在目標不一致、指導思想不一致的情況下,研發人員在做開源項目的整個方向就不一樣。舉個例子,比如開源項目Ubuntu,它在PC上的用戶體驗與在手機上完全不一樣,雖然都是同一套Linux,都是開源搭出來的。它桌面的Xwindow系統都已經不再用在手機上了。如果你把Xwindow強行放在手機上,你所產生的成本,以及所占用的資源都會是很大的。那么在未來,ARM服務器和手機更交融的情況來看,ARM和x86兩種開源社區也會出現交融的情況,這種交融會帶來更多獨創的開源項目。比如在ARM上運行的底層軟件,能不能實時的在x86上運行,x86上運行的軟件能不能不改動任何代碼就放到手機上運行,現在已經有一些好的開源項目在開始做了,比如LLVM項目。

ARM和x86在服務器市場的爭奪將愈演愈烈

另一個值得關注的領域在于服務器,標志性的事件是,以Facebook、百度為首的互聯網企業已經在服務器端開始大量采用ARM架構作為存儲服務器。

對此,楚含進認為,如果把web接入、存儲服務器等高并發但輕量級應用作為當前云計算重要的落地形式,則云計算反而是ARM服務器在服務器的主要切入點。而在大數據、科學計算等領域,ARM要走的路很長。畢竟通用處理器在高性能計算,尤其是密集型計算中還是占有得天獨厚的優勢,包括其軟件。但這并不妨礙大家看到,在移動終端硬件競爭和服務器硬件競爭上面,實際上服務器還是屬于藍海。

“百度用ARM不完全是基于價格的考慮,而是基于未來百度把自己的軟件按照專屬領域的業務特點然后來配備相應的硬件而做的規劃,這種規劃會使自己從供應鏈、軟件、硬件的生態系統當中變得標準化和開放,同時也會降低整個的成本。畢竟百度是以軟件為生存的一個公司,而ARM的服務器也只是有限的部署在在百度的某些服務領域,占很小的一部分。”

那么未來服務器芯片領域的格局是什么呢?以前服務器領域傳統的格局只會是HP、DELL、IBM這些公司,而ARM服務器的出現會使得芯片公司有機會在設計服務器,或者說是類服務器的技術門檻降低。因為原來只能在x86服務器上做的東西現在有可能用低成本的ARM服務器來替代。而對于芯片廠商來說,會使許多原來認為“在x86領域做服務器門檻很高”的企業進入這個領域。這也對以前老牌的服務器廠家提出了巨大的挑戰,也就是說他如何去面對現在終端和云端這種相互的格局下能夠定位自己的產品。第二,在移動端,有著很深厚背景的公司,比如某些移動芯片制造公司,他們進入服務器領域也是有可能的,因為他們本身對ARM的技術并不缺乏,而且對自己所做的業務也很熟悉,軟件能力也很成熟,唯一缺乏的是制造服務器芯片的一顆芯。其實,很多公司已經制造出了具有服務器功能的ARM架構芯片,可是我們要看到,這并不代表他們能夠制造出真正意義上的基于ARM服務器和打造完整的ARM服務器軟件生態系統。

“很多ARM的服務器要考慮的不僅僅是功能上的,還有背板總線、內存技術、主板布置技術、電源布置技術等,這都是做服務器廠家和做移動端廠家不同的地方。現在ARM的服務器剛剛開始,原來的服務器一家獨大的場面會逐漸變得市場細分,會使更多的芯片廠商進入服務器領域中來嘗試走出自己的紅海到另外一個藍海領域中擴大自己的陣營,AMD是有限的具有制造服務器芯片和打造服務器生態鏈的基因的公司,這一點是其他廠家無可比擬的,對于AMD 的ARM服務器未來一定會引起產業的格局變化”

從公司的長遠技術趨勢來看,AMD肯定不會放棄x86的;ARM短期內在科學計算等高性能領域可能不大有很好的作為,因為其指令集架構和應用生態系統不是完全為這方面服務的。那么AMD基于ARM的異構和x86的異構在未來會不會在高性能領域成為主導呢?

楚含進表示,未來基于APU的服務器,不管是ARM異構還是x86異構,一定會為高性能領域帶來非常非常重大的影響,會在很多在非結構化數據處理方面能夠產生非常深的影響。因為在現在大數據的前提下,一些非結構化數據的處理,有的時候不能完全靠CPU的處理能力,要靠GPU和CPU的協同處理能力才能更好的有效的完成。目前中國有很多客戶對異構服務器都非常感興趣。而其實APU服務器的出現,并不是簡單的CPU和GPU的合成,而是整個系統框架的變化,是主板布局的變化,最重要的是業務模型,編程模型的變化,整個業務的部署也會隨著在不同級別服務器的部署產生很大的變化。這些都會為業界帶來很好的機會。至于下一代高性能計算的趨勢,我認為不是簡單的CPU的編程或是GPU的編程,而是要看業務,而且業務應該是與云計算綁定在一起的。開發人員與業務人員會去考慮是單純的利用CPU還是異構服務器。

而在高性能計算領域,GPU現在還是作為CPU的協作處理器存在,通過PCIE傳輸數據,對異構計算而言,這似乎是一個嚴重的瓶頸。

楚含進認為,GPU現在有兩個問題。第一,硬件瓶頸問題,就是GPU與CPU之間的通訊和數據搬遷造成成性能功耗的問題。第二,GPU作為一個協處理器或者將來作為一個可編程處理器,如何讓用戶更容易編程,這是GPU如何作為通用處理器的第二個瓶頸。

“AMD目前做了兩件事情,公司的大策略是低功耗,包括嵌入式,所做的一切都是為了低功耗。APU實際上是把CPU和GPU結合起來做了一個架構叫做Heterogeneous System Architecture(HSA),這是一個異構的架構。目前LG、三星、高通都已經和AMD在加入HSA基金會之力于異構系統結構的標準化,涵蓋服務器終端到桌面的領域。這個架構最大的解決了兩個問題,第一,把CPU與GPU進行更緊密的結合,不僅在實際上減少了數據在CPU和GPU之間傳輸時產生的功耗,更對很多程序來說是莫大的幫助;第二,我們在HSA上為GPU開發出一套非常容易讓高層的編程語言人員能夠使用的工具,這個工具不用太多的考慮GPU里專有的編程語言。我們立足于希望這些開發人員利用這種工具能夠對自己的業務了解即可,而不用考慮GPU,而最終把GPU變成通用編程的模型。為了做到這一點,我們提供了HSA編譯工具、可調式的工具、基于開源的中間件。”

“在未來,我們真正的基于HSA的APU產品出來之后,你會看到對GPU的編程模型會徹底的改變。因為在CPU和GPU的通訊架構上做了很徹底的改變,而使得CPU和GPU的數據的傳輸可以不通過內存拷貝,這也就達到了省電和低功耗的目的。AMD把這種技術作為長足的發展,這種技術會用在我們的服務器領域,也會用在未來的PC機領域,同時也會用到低功耗的產品領域。”同時不要忘了,當我們說異構,不單單是指GPU和CPU,AMD的APU的SoC內同時集成了如入視頻編碼,解碼,音頻處理,內容安全等專用的處理模塊,同時提供特定的編程接口,這也是異構的表現。

給開發人員的建議:如何避免同質化開發?

在中國,好的開發人員非常多,這一點從異構大賽可以看出,有些產品的創意,性能和應用領域都非常有商業和學術價值;好的產品規劃師也很多。但是中國做出來的產品同質化非常嚴重,針對某一應用領域做出自己專屬產品的框架前提的指導下,以前只要掌握編程可能就能開發出應用,但是現在就不一樣了。楚含進認為,對目前的中國軟件開發人員而言,目前的市場大環境對他們提出了幾個方面的需求:

首先,架構人員應該有全局觀,不但要對業務領域有所熟悉,而且更需要拓展與此專業領域相關的知識領域,要想辦法利用現有的各種技術來時自己產品在性能,特性產生差異化和提高技術門檻,從硬件,軟件,算法,性能綜合考慮,而不是單純吧摸個產品功能實現就可以。這樣就能使你們的產品變得與眾不同。

第二,要有原創精神,培養自己內功,現在的技術,流派太多了,軟件人員一輩子也學完,等你學會了這個,結果新的潮流來了,好像總是落伍。有一個例子,大家都去學hadoop, 我問了很多人去學Hadoop干什么,居然沒有幾個回答我,只是覺得這個東西很熱,所以去看看,盲從的心理不會產生好的軟件產品。所以我建議要對自己學習的東西有所判斷,要關注新的技術產生,對新技術要敏感,用于嘗試。現在的代碼程序員太多,思想成員太少了。

最后,對于軟件人員,我特別希望無論你是應用層還是底層的開發人員, 都應該去了解計算機體系結構,了解CPU和GPU的方向。CPU和GPU一定是未來硬件的兩大軟件承載核心,所謂先知者先行。以前GPU很多停留在游戲行業,但是隨著異構計算的到來,GPU和CPU融合產生應用的變化,很多有前瞻性的軟件人員早已開始涉足此領域來占領先機。(文/譚茂 責編/包研)

posted @ 2013-02-19 08:40 jackdong 閱讀(457) | 評論 (0)編輯 收藏

2013年2月17日 #

http://blog.csdn.net/zhang0311/article/details/8224093
近年來,基于CPU+GPU的混合異構計算系統開始逐漸成為國內外高性能計算領域的熱點研究方向。在實際應用中,許多基于 CPU+GPU 的混合異構計算機系統表現出了良好的性能。但是,由于各種歷史和現實原因的制約,異構計算仍然面臨著諸多方面的問題,其中最突出的問題是程序開發困難,尤其是擴展到集群規模級別時這個問題更為突出。主要表現在擴展性、負載均衡、自適應性、通信、內存等方面。

一、    CPU+GPU協同計算模式

CPU+GPU異構協同計算集群如圖1所示,CPU+GPU異構集群可以劃分成三個并行層次:節點間并行、節點內CPU與GPU異構并行、設備(CPU或GPU)內并行。根據這三個層次我們可以得到CPU+GPU異構協同計算模式為:節點間分布式+節點內異構式+設備內共享式。

1           節點間分布式

CPU+GPU異構協同計算集群中,各個節點之間的連接與傳統CPU集群一樣,采用網絡連接,因此,節點間采用了分布式的計算方式,可以采用MPI消息通信的并行編程語言。

2           節點內異構式

CPU+GPU異構協同計算集群中,每個節點上包含多核CPU和一塊或多塊GPU卡,節點內采用了異構的架構,采用主從式的編程模型,即每個GPU卡需要由CPU進程/線程調用。

由于每個節點上,CPU核數也比較多,計算能力也很大,因此,在多數情況下,CPU也會參與部分并行計算,根據CPU是否參與并行計算,我們可以把CPU+GPU異構協同計算劃分成兩種計算模式:

1)       CPU/GPU協同計算:CPU只負責復雜邏輯和事務處理等串行計算,GPU 進行大規模并行計算;

2)       CPU+GPU共同計算:由一個CPU進程/線程負責復雜邏輯和事務處理等串行計算,其它CPU進程/線程負責小部分并行計算,GPU負責大部分并行計算。

由于CPU/GPU協同計算模式比CPU+GPU共同計算模式簡單,下面的介紹中,我們以CPU+GPU共同計算模式為例進行展開介紹各種編程模式。

在CPU+GPU共同計算模式下,我們把所有的CPU統稱為一個設備(device),如雙路8核CPU共有16個核,我們把這16個核統稱成一個設備;每個GPU卡成為一個設備。根據這種劃分方式,我們可以采用MPI進程或OpenMP線程控制節點內的各設備之間的通信和數據劃分。

3           設備內共享式

1)       CPU設備:每個節點內的所有多核CPU采用了共享存儲模型,因此,把節點內的所有多核CPU看作一個設備, 可以采用MPI進程或OpenMP線程、pThread線程控制這些CPU核的并行計算。

2)       GPU設備:GPU設備內有自己獨立的DRAM存儲,GPU設備也是共享存儲模型,在GPU上采用CUDA或OpenCL編程控制GPU眾核的并行計算。CUDA編程模式只在NVIDIA GPU上支持,OpenCL編程模式在NVIDIA GPU和AMD GPU都支持。

根據前面對CPU+GPU異構協同計算模式的描述,我們可以得到CPU+GPU異構協同計算的編程模型(以MPI和OpenMP為例)如表1所示。


圖1 CPU+GPU異構協同計算架構

表1 CPU+GPU異構協同計算編程模型

 

節點間分布式

節點內異構式

設備內共享式

CPU

GPU

模式1

MPI

OpenMP

OpenMP

CUDA/OpenCL

模式2

MPI

MPI

OpenMP

CUDA/OpenCL

模式3

MPI

MPI

MPI

CUDA/OpenCL

二、    CPU+GPU協同計算負載均衡性設計

下面以模式2為例簡單介紹多節點CPU+GPU協同計算任務劃分和負載均衡,模式2的進程和線程與CPU核和GPU設備對應關系如圖2所示。若采用主從式MPI通信機制,我們在節點0上多起一個進程(0號進程)作為主進程,控制其它所有進程。每個節點上啟動3個計算進程,其中兩個控制GPU設備,一個控制其余所有CPU核的并行,在GPU內采用CUDA/OpenCL并行,在CPU設備內采用OpenMP多線程并行。

由于CPU+GPU協同計算模式分為3個層次,那么負載均衡性也需要在這3個層次上分別設計。在模式2的編程方式下,節點內和節點間均采用MPI進程,合二為一,設計負載均衡時,只需要做到進程間(設備之間)的負載均衡和CPU設備內OpenMP線程負載均衡、GPU設備內CUDA線程負載均衡即可。

對于設備內,采用的是共享存儲器模型,CPU設備上的OpenMP線程可以采用schedule(static/ dynamic/ guided )方式;GPU設備上只要保證同一warp內的線程負載均衡即可。

對于CPU+GPU協同計算,由于CPU和GPU計算能力相差很大,因此,在對任務和數據劃分時不能給CPU設備和GPU設備劃分相同的任務/數據量,這就增加了CPU與GPU設備間負載均衡的難度。CPU與GPU之間的負載均衡最好的方式是采用動態負載均衡的方法,然而有些應用無法用動態劃分而只能采用靜態劃分的方式。下面我們分別介紹動態劃分和靜態劃分。

1)       動態劃分:對于一些高性能計算應用程序,在CPU與GPU之間的負載均衡可以采用動態負載均衡的優化方法,例如有N個任務/數據,一個節點內有2個GPU卡,即三個設備(CPU和2個GPU),動態負載均衡的方法是每個設備先獲取一個任務/數據進行計算,計算之后立即獲取下一個任務,不需要等待其他設備,直到N個任務/數據計算完成。這種方式只需要在集群上設定一個主進程,負責給各個計算進程分配任務/數據。

2)       靜態劃分:在一些應用中,無法采用動態劃分的方式,需要靜態劃分方法,然而靜態劃分方法使異構設備間的負載均衡變得困難,有時甚至無法實現。對于一些迭代應用程序,我們可以采用學習型的數據劃分方法,如先讓CPU和GPU分別做一次相同計算量的計算,然后通過各自的運行時間計算出CPU與GPU的計算能力比例,然后再對數據進行劃分。


圖2 CPU+GPU協同計算示意圖(以每個節點2個GPU為例)

三、    CPU+GPU協同計算數據劃分示例

假設某一應用的數據特點如圖3所示,從輸出看,結果中的每個值的計算需要所有輸入數據的信息,所有輸出值的計算之間沒有任何數據依賴性,可以表示成outj=;從輸入看,每個輸入值對所有的輸出值都產生影響,所有輸入數據之間也沒有任何數據依賴性。從數據特點可以看出,該應用既可以對輸入進行并行數據劃分也可以對輸出進行數據劃分。下面我們分析CPU+GPU協同計算時的數據劃分方式。


圖3 并行數據示例

1         按輸入數據劃分

假設按輸入數據劃分,我們可以采用動態的方式給每個CPU或GPU設備分配數據,做到動態負載均衡,然而這種劃分方式,使所有的線程向同一個輸出位置保存結果,為了正確性,需要使所有的線程對每個結果進行原子操作,這樣將會嚴重影響性能,極端情況下,所有線程還是按順序執行的。因此,這種方式效果很差。

2         按輸出數據劃分

按輸出數據劃分的話可以讓每個線程做不同位置的結果計算,計算完全獨立,沒有依賴性。如果采用靜態劃分的方式,由于CPU和GPU計算能力不同,因此,很難做到負載均衡。采用動態的方式可以做到負載均衡,即把結果每次給CPU或GPU設備一塊,當設備計算完本次之后,立即向主進程申請下一個分塊,這樣可以做到完全負載均衡。按輸出數據劃分,無論采用靜態劃分還是動態劃分,都會帶來另外一個問題,由于每個結果的計算都需要所有輸入信息,那么所有進程(設備)都需要讀取一遍所有輸入數據,動態劃分時還不只一次,尤其對于輸入數據很大時,這將會對輸入數據的IO產生很大的影響,很有可能使IO程序性能瓶頸。

3         按輸入和輸出同時劃分

由于按輸入或按輸出劃分都存在不同的缺點,我們可以采用輸入和輸出同時劃分的方式進行數據劃分,如圖4所示。

從輸出角度,讓所有的計算進程(設備)都有一份計算結果,設備內的線程對結果進行并行計算,每個設備都有一份局部的計算結果,所有設備都計算完畢之后,利用MPI進程對所有設備的計算結果進行規約,規約最后的結果即是最終的結果。

從輸入角度,按輸入數據動態劃分給不同的計算進程(設備),這樣可以滿足所有的計算進程負載均衡。


圖4 CPU+GPU協同計算數據劃分示例

posted @ 2013-02-17 13:27 jackdong 閱讀(1733) | 評論 (0)編輯 收藏

2013年1月9日 #

     摘要: http://devgurus.amd.com/thread/158866VLIW on Cypress and vector addition此問題被 假設已回答。cadorino 2012-7-2 上午10:31Hi to everybody.I'm thinking about VLIW utilization on a 5870 HD.Suppose you have ...  閱讀全文
posted @ 2013-01-09 16:37 jackdong 閱讀(508) | 評論 (0)編輯 收藏

http://devgurus.amd.com/thread/158866

Low ALUBusy and low FetchUnitBusy

此問題 未被回答 。

NURBSNewbie
NURBS 2012-3-19 下午1:35

Hi,

      When my kernel performs badly, the APP profiler reports a very low ALUBusy and low FetchUniBusy, (Both less than 10%)

      What can be the bottleneck here? Could it be because of the high number of code paths?

 

 

Thanks

NURBS

有用答案 作者 pesh 
  • 140 瀏覽次數
  • 有用答案Re: Low ALUBusy and low FetchUnitBusy
    peshNewbie
    pesh 2012-3-26 上午7:07 (回復 NURBS)

    Hi, NURBS!

    Can you provide information about your device? If it's an AMD APU then there were problems with performance counters in previous versions of APP Profiler.

    Also, check ALUPacking counter, if it has low value, then you code is VLIW limited and ALUBusy is poor, in this case try to reduce some data dependencies across sequential operations, it will allow compiler to better pack ALU instructions in VLIW, and utilize ALU resources. Try to reduce control flow statements, they affect counters to. In your situation, maybe you have if-statements, where in one branch you do fetch operation, and in another do some computations? That will cause some part of wavefront do fetch, and only after that remainder of wavefront will do ALU operations. So you will use only part of resources at time.

    • Re: Low ALUBusy and low FetchUnitBusy
      NURBSNewbie
      NURBS 2012-3-26 上午7:57 (回復 pesh)

      I have dual Radeon 6950 with either 12.3 or the new beta driver. It seems control flow was the issue, things are much better now. Is there an equation  I can use to sum up the numbers of counters to 100%, so that I can be more certain I am not getting bogus numbers?

      • Re: Low ALUBusy and low FetchUnitBusy
        peshNewbie
        pesh 2012-3-26 上午8:46 (回復 NURBS)

        I guess no, there is no such equation. First of all because when fetch instruction is applied by wavefront executing on compute unit, this wavefront goes to fetch unit, where it sits until fetch is done. At this time other wavefronts are doing calculations, or wait unit fetch unit become free, to execute next fetch instructions. So when some wavefronts are doing memory read or write other can do computations, and in the best case both counters can have 100% value, and ALUFetchRatio counter will equal to 1. Another important counters is FetchUnitStalled and WriteUnitStalled, try to keep them about 0 value. If it's too big, then many of wavefront are waiting for fetch unit to do memory read/write. To improve performance first of all, try to use sequential memory access pattern, then try to use local memory, if your algorithm reuse data several timers within workgroup.

posted @ 2013-01-09 16:26 jackdong 閱讀(451) | 評論 (0)編輯 收藏

     摘要: http://devgurus.amd.com/thread/159558Understanding performance counters此問題被 假設已回答。chersanya 2012-8-5 下午12:03I have a kernel, and each workitem processes tens of elements (firstly perform som...  閱讀全文
posted @ 2013-01-09 13:36 jackdong 閱讀(531) | 評論 (0)編輯 收藏

     摘要: http://devgurus.amd.com/thread/158655ALUBusy question此問題 已被回答。viscocoa 2012-2-20 下午2:39What does ALUBusy in APP profiler really mean? If there is branching in a kernel, the SIMD unit wi...  閱讀全文
posted @ 2013-01-09 10:35 jackdong 閱讀(366) | 評論 (0)編輯 收藏

僅列出標題  下一頁
青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            午夜激情综合网| 亚洲成色www8888| 黑人一区二区三区四区五区| 最近中文字幕日韩精品 | 久久阴道视频| 在线视频一区观看| 久久婷婷蜜乳一本欲蜜臀| 国产精品综合| 欧美激情黄色片| 亚洲欧美成人一区二区三区| 亚洲精品美女免费| 99视频一区二区三区| 午夜国产一区| 欧美激情精品久久久久久久变态 | 国产精品日韩在线观看| 亚洲人成在线观看网站高清| 99热精品在线| 亚洲一区视频| 亚洲精选在线观看| 亚洲高清不卡在线观看| 99热免费精品在线观看| 久久精品国产清自在天天线| 在线观看欧美日韩| 亚洲欧美日韩国产中文在线| 国产欧美日韩精品一区| 欧美一区二区三区久久精品茉莉花 | aaa亚洲精品一二三区| 欧美一级精品大片| 一区二区三区成人精品| 欧美亚洲视频在线看网址| 欧美一激情一区二区三区| 久久这里有精品视频| 亚洲精品日产精品乱码不卡| 亚洲精品国产欧美| 国产欧美短视频| 亚洲精品你懂的| 欧美不卡视频一区| 久久久综合网站| 欧美日韩一区国产| 国产精品久久激情| 欧美一级日韩一级| 国产精品视频区| 久久综合网络一区二区| 欧美一区二区在线观看| 伊人精品在线| 一区二区三区**美女毛片| 国产一区二区精品久久| 亚洲观看高清完整版在线观看| 欧美激情一区三区| 久久精品一本| 欧美精品三级日韩久久| 欧美一区二区三区在线观看 | 久久精品国产免费看久久精品| 亚洲高清自拍| 在线午夜精品| 亚洲电影在线播放| 亚洲一区三区视频在线观看| 亚洲毛片视频| 久久精品在线观看| 亚洲欧美国产另类| 欧美黄色免费网站| 久久琪琪电影院| 国产精品久久久久9999| 亚洲激情成人网| 狠狠色丁香久久婷婷综合_中| 99这里有精品| 日韩天天综合| 麻豆91精品| 久久夜色撩人精品| 国产一级久久| 亚洲中午字幕| 亚洲综合色自拍一区| 欧美另类在线观看| 亚洲福利电影| 亚洲黄色在线观看| 久久视频精品在线| 久久综合九色综合久99| 国外成人网址| 久久精品国产亚洲5555| 欧美一区二视频| 国产精品家教| 亚洲一区国产视频| 亚洲视频一区在线| 欧美日韩亚洲一区二区| 亚洲三级影院| 91久久国产综合久久蜜月精品| 久久精品二区| 久久综合久色欧美综合狠狠| 国产一区久久久| 欧美伊人久久久久久久久影院| 欧美在线网址| 狠狠做深爱婷婷久久综合一区 | 欧美日韩亚洲成人| 亚洲欧洲日本国产| 一本色道久久综合狠狠躁篇怎么玩 | 欧美影院成人| 亚洲欧美日韩高清| 亚洲专区一区二区三区| 国产精品夫妻自拍| 一区二区电影免费观看| 亚洲无线视频| 国产精品不卡在线| 亚洲宅男天堂在线观看无病毒| 欧美一区二区视频在线观看2020| 国产美女精品免费电影| 欧美在线视频免费播放| 欧美成人亚洲| 99精品热6080yy久久| 欧美午夜一区二区福利视频| 亚洲欧美另类在线观看| 久久一区亚洲| 亚洲日本欧美天堂| 欧美日韩国产首页在线观看| 亚洲一级免费视频| 久久久亚洲成人| 亚洲精选视频在线| 国产精品专区第二| 久久噜噜噜精品国产亚洲综合| 欧美成人综合一区| 亚洲视频专区在线| 国产视频综合在线| 久久久国产视频91| 日韩图片一区| 两个人的视频www国产精品| 日韩一级大片在线| 国产精品爽爽爽| 欧美电影在线观看完整版| 中文国产一区| 欧美电影在线| 欧美在线一二三四区| 91久久在线观看| 国产精品久久福利| 久久综合久久综合久久综合| 在线亚洲激情| 国产精品久久久久久久一区探花| 欧美在线观看网址综合| 亚洲国产另类精品专区| 午夜亚洲激情| 亚洲精品久久7777| 国产日韩亚洲欧美| 欧美全黄视频| 久久视频一区二区| 亚洲欧美成人综合| 亚洲精品视频在线观看网站| 久久九九有精品国产23| 一区二区国产精品| 91久久久久久| 国产一区二区三区直播精品电影 | 国产真实久久| 欧美日韩在线不卡| 久久人体大胆视频| 欧美在线观看天堂一区二区三区| 9i看片成人免费高清| 美腿丝袜亚洲色图| 欧美在线影院| 亚洲午夜av电影| 夜夜嗨av色一区二区不卡| 久久国产精品久久久| 一区二区三区日韩精品| 欧美二区不卡| 久久综合网hezyo| 久久久91精品国产| 性色av一区二区怡红| 亚洲免费在线观看视频| 999亚洲国产精| 亚洲激情视频网| 午夜精品一区二区在线观看| 欧美精品国产精品日韩精品| 久久精品国产亚洲一区二区三区 | 国产精品私拍pans大尺度在线| 欧美激情视频一区二区三区不卡| 欧美日韩国产影片| 久久亚洲欧美| 欧美日韩免费观看一区=区三区| 亚洲自拍偷拍麻豆| 久久久久高清| 亚洲综合精品| 毛片av中文字幕一区二区| 一本色道久久综合一区| 久久成人免费| 欧美自拍偷拍午夜视频| 亚洲精品激情| 国产精品尤物福利片在线观看| 欧美jizz19hd性欧美| 久久精品国产欧美亚洲人人爽| 亚洲在线播放| 欧美在线视频不卡| 久久国产精品网站| 久久精品午夜| 麻豆av一区二区三区| 欧美成人有码| 亚洲欧洲日韩综合二区| 亚洲激情欧美激情| 在线一区二区日韩| 先锋影院在线亚洲| 久久久久网址| 欧美精品尤物在线| 国产精品爽黄69| 在线看欧美日韩| 亚洲婷婷综合久久一本伊一区|