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

C++ Coder

HCP高性能計(jì)算架構(gòu),實(shí)現(xiàn),編譯器指令優(yōu)化,算法優(yōu)化, LLVM CLANG OpenCL CUDA OpenACC C++AMP OpenMP MPI

C++博客 首頁(yè) 新隨筆 聯(lián)系 聚合 管理
  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

在一個(gè)Android應(yīng)用中,主要是由四種組件組成的,這四種組件可參考“Android應(yīng)用的構(gòu)成”。
而這四種組件是獨(dú)立的,它們之間可以互相調(diào)用,協(xié)調(diào)工作,最終組成一個(gè)真正的Android應(yīng)用。

在這些組件之間的通訊中,主要是由Intent協(xié)助完成的。
Intent負(fù)責(zé)對(duì)應(yīng)用中一次操作的動(dòng)作、動(dòng)作涉及數(shù)據(jù)、附加數(shù)據(jù)進(jìn)行描述,Android則根據(jù)此Intent的描述,負(fù)責(zé)找到對(duì)應(yīng)的組件,將 Intent傳遞給調(diào)用的組件,并完成組件的調(diào)用。
因此,Intent在這里起著一個(gè)媒體中介的作用,專門提供組件互相調(diào)用的相關(guān)信息,實(shí)現(xiàn)調(diào)用者與被調(diào)用者之間的解耦。
例如,在一個(gè)聯(lián)系人維護(hù)的應(yīng)用中,當(dāng)我們?cè)谝粋€(gè)聯(lián)系人列表屏幕(假設(shè)對(duì)應(yīng)的Activity為listActivity)上,點(diǎn)擊某個(gè)聯(lián)系人后,希望能夠跳出此聯(lián)系人的詳細(xì)信息屏幕(假設(shè)對(duì)應(yīng)的Activity為detailActivity)
為了實(shí)現(xiàn)這個(gè)目的,listActivity需要構(gòu)造一個(gè) Intent,這個(gè)Intent用于告訴系統(tǒng),我們要做“查看”動(dòng)作,此動(dòng)作對(duì)應(yīng)的查看對(duì)象是“某聯(lián)系人”,然后調(diào)用startActivity (Intent intent),
將構(gòu)造的Intent傳入,系統(tǒng)會(huì)根據(jù)此Intent中的描述,到ManiFest中找到滿足此Intent要求的Activity,系統(tǒng)會(huì)調(diào)用找到的 Activity,即為detailActivity,最終傳入Intent,detailActivity則會(huì)根據(jù)此Intent中的描述,執(zhí)行相應(yīng)的操作。

一、抽象描述要描述什么

在Android參考文檔中,對(duì)Intent的定義是執(zhí)行某操作的一個(gè)抽象描述(確實(shí)很抽象)。我們先來看看這里的抽象描述,到底描述了什么。
首先,是要執(zhí)行的動(dòng)作(action)的一個(gè)簡(jiǎn)要描述,如VIEW_ACTION(查看)、EDIT_ACTION(修改)等,Android為我們定義了一套標(biāo)準(zhǔn)動(dòng)作:

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
此外,我們還可以根據(jù)應(yīng)用的需要,定義我們自己的動(dòng)作,并可定義相應(yīng)的Activity來處理我們的自定義動(dòng)作。

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

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

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

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

二、Android如何解析Intent

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

三、應(yīng)用例子

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


  • <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>

復(fù)制代碼
例子中的第一個(gè)Activity是com.google.android.notepad.NotesList,它是應(yīng)用的主入口,提供了三個(gè)功能,分別由三個(gè) intent-filter進(jìn)行描述:

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

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

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

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

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

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

它可以被實(shí)現(xiàn)為一個(gè)應(yīng)用可以直接調(diào)用(在Intent中明確設(shè)置component屬性)的類,不過這里我們將為你提供一個(gè)在現(xiàn)有的數(shù)據(jù)上發(fā)布可選操作的方法。

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

和前面的view和edit 動(dòng)作一樣,調(diào)用這個(gè)Intent 的時(shí)候,也必須指定具體的便箋(type為vnd.android.cursor.item/vnd.google.note)。不同的是,這里顯示和編輯的只是便箋數(shù)據(jù)中的標(biāo)題。

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

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

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

有了這個(gè)功能,下面的Intent就會(huì)被解析到TitleEditor這個(gè)Activity:

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

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

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

一、Handler的定義:

          主要接受子線程發(fā)送的數(shù)據(jù), 并用此數(shù)據(jù)配合主線程更新UI.

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

二、Handler一些特點(diǎn)

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

        以上post類方法允許你排列一個(gè)Runnable對(duì)象到主線程隊(duì)列中,
        sendMessage類方法, 允許你安排一個(gè)帶數(shù)據(jù)的Message對(duì)象到隊(duì)列中,等待更新.

三、Handler實(shí)例

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

      以下為一個(gè)實(shí)例,它實(shí)現(xiàn)的功能為 : 通過線程修改界面Button的內(nèi)容
  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.         // 當(dāng)創(chuàng)建一個(gè)新的Handler實(shí)例時(shí), 它會(huì)綁定到當(dāng)前線程和消息的隊(duì)列中,開始分發(fā)數(shù)據(jù)
  10.         // Handler有兩個(gè)作用, (1) : 定時(shí)執(zhí)行Message和Runnalbe 對(duì)象
  11.         // (2): 讓一個(gè)動(dòng)作,在不同的線程中執(zhí)行.

  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對(duì)象
  22.         //sendMessage()允許你處理Message對(duì)象(Message里可以包含數(shù)據(jù),)

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

  26.     /**
  27.     * 接受消息,處理消息 ,此Handler會(huì)與當(dāng)前主線程一塊運(yùn)行
  28.     * */

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

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

  35.         // 子類必須重寫此方法,接受數(shù)據(jù)
  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();// 存放數(shù)據(jù)
  58.             b.putString("color", "我的");
  59.             msg.setData(b);

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

  61.         }
  62.     }

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

2013年3月8日 #

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

嵌入式linux入門學(xué)習(xí)規(guī)劃  

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

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

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

   嵌入式 書籍推薦 
   Linux基礎(chǔ) 
   1、《Linux與Unix Shell 編程指南》 
   C語言基礎(chǔ) 
    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應(yīng)用程序開發(fā)詳解》 
   Linux內(nèi)核 
   1、《深入理解Linux內(nèi)核》(第三版) 
    2、《Linux內(nèi)核源代碼情景分析》毛德操 胡希明著 
   研發(fā)方向 
   1、 《UNIX Network Programming》(UNP) 
   2、《TCP/IP詳解》 
   3、《Linux內(nèi)核編 程》 
   4、《Linux設(shè)備驅(qū)動(dòng)開發(fā)》(LDD)  
   5、《Linux高級(jí)程序設(shè)計(jì)》 楊宗德著
   硬件基礎(chǔ) 
    1、《ARM體系結(jié)構(gòu)與編程》杜春雷著 
   2、S3C2410 Datasheet 
   英語基礎(chǔ) 
   1、《計(jì)算 機(jī)與通信專業(yè)英語》 
   系統(tǒng)教程 
   1、《嵌入式系統(tǒng)――體系結(jié)構(gòu)、編程與設(shè)計(jì)》 
   2、《嵌入式系統(tǒng)――采用公開 源代碼和StrongARM/Xscale處理器》毛德操 胡希明著 
   3、 《Building Embedded Linux Systems》   
   4、《嵌入式ARM系統(tǒng)原理與實(shí)例開發(fā)》 楊宗德著
    理論基礎(chǔ) 
   1、《算法導(dǎo)論》 
   2、《數(shù)據(jù)結(jié)構(gòu)(C語言版)》 
   3、《計(jì)算機(jī)組織與體系結(jié)構(gòu)?性能分析》 
    4、《深入理解計(jì)算機(jī)系統(tǒng)》【美】Randal E. Bryant David O''Hallaron著 
   5、《操作系統(tǒng):精髓與 設(shè)計(jì)原理》 
   6、《編譯原理》 
   7、《數(shù)據(jù)通信與計(jì)算機(jī)網(wǎng)絡(luò)》 
   8、《數(shù)據(jù)壓縮原理與應(yīng)用》 

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

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

2013年2月19日 #

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

摘要:在PC產(chǎn)業(yè)日漸頹勢(shì)和移動(dòng)行業(yè)方興未艾的大環(huán)境下,AMD作為PC CPU芯片行業(yè)的兩個(gè)供應(yīng)商之一,如何在上下夾擊的態(tài)勢(shì)下突出重圍,大家一直拭目以待。經(jīng)過近兩年的調(diào)整,AMD并非沒有出路,他們已經(jīng)為自己規(guī)劃了三個(gè)快速發(fā)展的機(jī)遇:雙核、異構(gòu)、低功耗。而開放和開源的思維貫穿始終。

開放才是未來

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


圖:HSA幫助從服務(wù)器端到移動(dòng)端提升效率、降低功耗

“雖然用OpenCL這個(gè)工業(yè)標(biāo)準(zhǔn)已經(jīng)能達(dá)到這種效果,但這樣的做法仍舊太復(fù)雜,而且主流的開發(fā)者也不容易接受。NVIDIA雖然大力推進(jìn)自己的CUDA運(yùn)算架構(gòu),不過CUDA和OpenCL是同一層面的技術(shù),而基于私有架構(gòu)的開發(fā)棧終將沒落。”

AMD中國(guó)開發(fā)合作與解決方案中心總監(jiān)楚含進(jìn)坦言,目前AMD所有做的事情都是為將來某一段時(shí)間產(chǎn)品集中爆發(fā)做技術(shù)上系統(tǒng)儲(chǔ)備。在HSA基金會(huì)中,其中的廠商從服務(wù)器到PC到手機(jī)廠商都會(huì)有,AMD將幫助各個(gè)伙伴更好的去驅(qū)動(dòng)軟件生態(tài)系統(tǒng),促使軟件里面的工具、軟件里面的庫(kù)、軟件里面的開發(fā)環(huán)境讓更多的人更容易的去使用。

“其次,我們將一直致力于降低功耗,這兩年我們會(huì)把生態(tài)鏈去閉環(huán)運(yùn)營(yíng)。在中國(guó)來說,我們有一個(gè)開發(fā)團(tuán)隊(duì)會(huì)幫助國(guó)內(nèi)的開發(fā)人員能夠?qū)W會(huì)如何在GPU上進(jìn)行編程;而在技術(shù)層面上,我們更希望能夠向著平板電腦這個(gè)方向進(jìn)行過度。 最終目的是在低功耗上推出AMD的一系列產(chǎn)品,x86和ARM雙核并行戰(zhàn)略。”

而從市場(chǎng)的直接反饋結(jié)果來看,AMD擁抱開放技術(shù)的策略也受到了開發(fā)者的一致歡迎。

作為軟件開發(fā)人員尤其是學(xué)生開發(fā)人群,是AMD首先取悅的人群,在前不久舉行的異構(gòu)編程大賽上,AMD收到了40多個(gè)作品,從開發(fā)者的關(guān)注點(diǎn)來看,他們也正向著云計(jì)算、多媒體、移動(dòng)互聯(lián)網(wǎng)應(yīng)用這些深層次的產(chǎn)品優(yōu)化的方向,同目前的行業(yè)熱點(diǎn)是有很好的契合點(diǎn)的。并且在相當(dāng)多的參賽作品中,無論是學(xué)生本人,還是在導(dǎo)師的帶領(lǐng)下,這些行業(yè)還是都比較容易產(chǎn)生有創(chuàng)意或者是有深度有質(zhì)量的軟件實(shí)現(xiàn)的算法或者產(chǎn)品的核心技術(shù),而這些注定是未來軟件公司差異化的核心。

從作品的類型來看,有數(shù)據(jù)搜索和數(shù)據(jù)的作品,也有算法優(yōu)化方面的內(nèi)容。而在多媒體、圖形圖像方面,比如損失圖像的修復(fù)、二維圖像的三維化、圖像的拼接以及細(xì)化和分割,這些(技術(shù))在很多領(lǐng)域無論是移動(dòng)還是多媒體領(lǐng)域有著深遠(yuǎn)的意義。

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

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

AMD結(jié)盟ARM, 橫跨x86和ARM架構(gòu)?

目前的芯片市場(chǎng),實(shí)際上是有兩大芯片陣營(yíng),ARM與x86兩大陣營(yíng)在博弈。在智能手機(jī)出現(xiàn)之前,是通用處理器的天下,這種通用處理器包括ARM、x86。實(shí)際上更多領(lǐng)域用的還是通用處理器,通用處理器時(shí)代,CPU的設(shè)計(jì)是個(gè)門檻,決定這個(gè)公司的成敗。但隨著智能手機(jī)和移動(dòng)互聯(lián)的大量實(shí)現(xiàn),決定這個(gè)公司的未來是是否具有設(shè)計(jì)CPU以及設(shè)計(jì)多核CPU的能力。

“通用處理器的設(shè)計(jì)已經(jīng)不再是門檻了,因?yàn)锳RM已經(jīng)把整個(gè)CPU體系幫你設(shè)計(jì)完成了。第二,Intel的x86處理器通用處理器也由于開始受到主機(jī)的云應(yīng)用的影響。用戶會(huì)問,問什么要用通用處理器來做這種非通用的應(yīng)用?給我一個(gè)理由,這會(huì)是一個(gè)很大的問題。”從技術(shù)層面,這背后其實(shí)系統(tǒng)和產(chǎn)品設(shè)計(jì)日益差異化需求的問題。、

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

“AMD對(duì)于GPU的發(fā)展技術(shù)上有很獨(dú)創(chuàng)的見解,在游戲以及圖形圖像處理上非常的專注,所以這就是AMD能夠走SoC和將來走可定制化專用服務(wù)器領(lǐng)域的一個(gè)信號(hào)”,楚含進(jìn)表示。

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

ARM和x86在服務(wù)器市場(chǎng)的爭(zhēng)奪將愈演愈烈

另一個(gè)值得關(guān)注的領(lǐng)域在于服務(wù)器,標(biāo)志性的事件是,以Facebook、百度為首的互聯(lián)網(wǎng)企業(yè)已經(jīng)在服務(wù)器端開始大量采用ARM架構(gòu)作為存儲(chǔ)服務(wù)器。

對(duì)此,楚含進(jìn)認(rèn)為,如果把web接入、存儲(chǔ)服務(wù)器等高并發(fā)但輕量級(jí)應(yīng)用作為當(dāng)前云計(jì)算重要的落地形式,則云計(jì)算反而是ARM服務(wù)器在服務(wù)器的主要切入點(diǎn)。而在大數(shù)據(jù)、科學(xué)計(jì)算等領(lǐng)域,ARM要走的路很長(zhǎng)。畢竟通用處理器在高性能計(jì)算,尤其是密集型計(jì)算中還是占有得天獨(dú)厚的優(yōu)勢(shì),包括其軟件。但這并不妨礙大家看到,在移動(dòng)終端硬件競(jìng)爭(zhēng)和服務(wù)器硬件競(jìng)爭(zhēng)上面,實(shí)際上服務(wù)器還是屬于藍(lán)海。

“百度用ARM不完全是基于價(jià)格的考慮,而是基于未來百度把自己的軟件按照專屬領(lǐng)域的業(yè)務(wù)特點(diǎn)然后來配備相應(yīng)的硬件而做的規(guī)劃,這種規(guī)劃會(huì)使自己從供應(yīng)鏈、軟件、硬件的生態(tài)系統(tǒng)當(dāng)中變得標(biāo)準(zhǔn)化和開放,同時(shí)也會(huì)降低整個(gè)的成本。畢竟百度是以軟件為生存的一個(gè)公司,而ARM的服務(wù)器也只是有限的部署在在百度的某些服務(wù)領(lǐng)域,占很小的一部分。”

那么未來服務(wù)器芯片領(lǐng)域的格局是什么呢?以前服務(wù)器領(lǐng)域傳統(tǒng)的格局只會(huì)是HP、DELL、IBM這些公司,而ARM服務(wù)器的出現(xiàn)會(huì)使得芯片公司有機(jī)會(huì)在設(shè)計(jì)服務(wù)器,或者說是類服務(wù)器的技術(shù)門檻降低。因?yàn)樵瓉碇荒茉趚86服務(wù)器上做的東西現(xiàn)在有可能用低成本的ARM服務(wù)器來替代。而對(duì)于芯片廠商來說,會(huì)使許多原來認(rèn)為“在x86領(lǐng)域做服務(wù)器門檻很高”的企業(yè)進(jìn)入這個(gè)領(lǐng)域。這也對(duì)以前老牌的服務(wù)器廠家提出了巨大的挑戰(zhàn),也就是說他如何去面對(duì)現(xiàn)在終端和云端這種相互的格局下能夠定位自己的產(chǎn)品。第二,在移動(dòng)端,有著很深厚背景的公司,比如某些移動(dòng)芯片制造公司,他們進(jìn)入服務(wù)器領(lǐng)域也是有可能的,因?yàn)樗麄儽旧韺?duì)ARM的技術(shù)并不缺乏,而且對(duì)自己所做的業(yè)務(wù)也很熟悉,軟件能力也很成熟,唯一缺乏的是制造服務(wù)器芯片的一顆芯。其實(shí),很多公司已經(jīng)制造出了具有服務(wù)器功能的ARM架構(gòu)芯片,可是我們要看到,這并不代表他們能夠制造出真正意義上的基于ARM服務(wù)器和打造完整的ARM服務(wù)器軟件生態(tài)系統(tǒng)。

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

從公司的長(zhǎng)遠(yuǎn)技術(shù)趨勢(shì)來看,AMD肯定不會(huì)放棄x86的;ARM短期內(nèi)在科學(xué)計(jì)算等高性能領(lǐng)域可能不大有很好的作為,因?yàn)槠渲噶罴軜?gòu)和應(yīng)用生態(tài)系統(tǒng)不是完全為這方面服務(wù)的。那么AMD基于ARM的異構(gòu)和x86的異構(gòu)在未來會(huì)不會(huì)在高性能領(lǐng)域成為主導(dǎo)呢?

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

而在高性能計(jì)算領(lǐng)域,GPU現(xiàn)在還是作為CPU的協(xié)作處理器存在,通過PCIE傳輸數(shù)據(jù),對(duì)異構(gòu)計(jì)算而言,這似乎是一個(gè)嚴(yán)重的瓶頸。

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

“AMD目前做了兩件事情,公司的大策略是低功耗,包括嵌入式,所做的一切都是為了低功耗。APU實(shí)際上是把CPU和GPU結(jié)合起來做了一個(gè)架構(gòu)叫做Heterogeneous System Architecture(HSA),這是一個(gè)異構(gòu)的架構(gòu)。目前LG、三星、高通都已經(jīng)和AMD在加入HSA基金會(huì)之力于異構(gòu)系統(tǒng)結(jié)構(gòu)的標(biāo)準(zhǔn)化,涵蓋服務(wù)器終端到桌面的領(lǐng)域。這個(gè)架構(gòu)最大的解決了兩個(gè)問題,第一,把CPU與GPU進(jìn)行更緊密的結(jié)合,不僅在實(shí)際上減少了數(shù)據(jù)在CPU和GPU之間傳輸時(shí)產(chǎn)生的功耗,更對(duì)很多程序來說是莫大的幫助;第二,我們?cè)贖SA上為GPU開發(fā)出一套非常容易讓高層的編程語言人員能夠使用的工具,這個(gè)工具不用太多的考慮GPU里專有的編程語言。我們立足于希望這些開發(fā)人員利用這種工具能夠?qū)ψ约旱臉I(yè)務(wù)了解即可,而不用考慮GPU,而最終把GPU變成通用編程的模型。為了做到這一點(diǎn),我們提供了HSA編譯工具、可調(diào)式的工具、基于開源的中間件。”

“在未來,我們真正的基于HSA的APU產(chǎn)品出來之后,你會(huì)看到對(duì)GPU的編程模型會(huì)徹底的改變。因?yàn)樵贑PU和GPU的通訊架構(gòu)上做了很徹底的改變,而使得CPU和GPU的數(shù)據(jù)的傳輸可以不通過內(nèi)存拷貝,這也就達(dá)到了省電和低功耗的目的。AMD把這種技術(shù)作為長(zhǎng)足的發(fā)展,這種技術(shù)會(huì)用在我們的服務(wù)器領(lǐng)域,也會(huì)用在未來的PC機(jī)領(lǐng)域,同時(shí)也會(huì)用到低功耗的產(chǎn)品領(lǐng)域。”同時(shí)不要忘了,當(dāng)我們說異構(gòu),不單單是指GPU和CPU,AMD的APU的SoC內(nèi)同時(shí)集成了如入視頻編碼,解碼,音頻處理,內(nèi)容安全等專用的處理模塊,同時(shí)提供特定的編程接口,這也是異構(gòu)的表現(xiàn)。

給開發(fā)人員的建議:如何避免同質(zhì)化開發(fā)?

在中國(guó),好的開發(fā)人員非常多,這一點(diǎn)從異構(gòu)大賽可以看出,有些產(chǎn)品的創(chuàng)意,性能和應(yīng)用領(lǐng)域都非常有商業(yè)和學(xué)術(shù)價(jià)值;好的產(chǎn)品規(guī)劃師也很多。但是中國(guó)做出來的產(chǎn)品同質(zhì)化非常嚴(yán)重,針對(duì)某一應(yīng)用領(lǐng)域做出自己專屬產(chǎn)品的框架前提的指導(dǎo)下,以前只要掌握編程可能就能開發(fā)出應(yīng)用,但是現(xiàn)在就不一樣了。楚含進(jìn)認(rèn)為,對(duì)目前的中國(guó)軟件開發(fā)人員而言,目前的市場(chǎng)大環(huán)境對(duì)他們提出了幾個(gè)方面的需求:

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

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

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

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

2013年2月17日 #

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

一、    CPU+GPU協(xié)同計(jì)算模式

CPU+GPU異構(gòu)協(xié)同計(jì)算集群如圖1所示,CPU+GPU異構(gòu)集群可以劃分成三個(gè)并行層次:節(jié)點(diǎn)間并行、節(jié)點(diǎn)內(nèi)CPU與GPU異構(gòu)并行、設(shè)備(CPU或GPU)內(nèi)并行。根據(jù)這三個(gè)層次我們可以得到CPU+GPU異構(gòu)協(xié)同計(jì)算模式為:節(jié)點(diǎn)間分布式+節(jié)點(diǎn)內(nèi)異構(gòu)式+設(shè)備內(nèi)共享式。

1           節(jié)點(diǎn)間分布式

CPU+GPU異構(gòu)協(xié)同計(jì)算集群中,各個(gè)節(jié)點(diǎn)之間的連接與傳統(tǒng)CPU集群一樣,采用網(wǎng)絡(luò)連接,因此,節(jié)點(diǎn)間采用了分布式的計(jì)算方式,可以采用MPI消息通信的并行編程語言。

2           節(jié)點(diǎn)內(nèi)異構(gòu)式

CPU+GPU異構(gòu)協(xié)同計(jì)算集群中,每個(gè)節(jié)點(diǎn)上包含多核CPU和一塊或多塊GPU卡,節(jié)點(diǎn)內(nèi)采用了異構(gòu)的架構(gòu),采用主從式的編程模型,即每個(gè)GPU卡需要由CPU進(jìn)程/線程調(diào)用。

由于每個(gè)節(jié)點(diǎn)上,CPU核數(shù)也比較多,計(jì)算能力也很大,因此,在多數(shù)情況下,CPU也會(huì)參與部分并行計(jì)算,根據(jù)CPU是否參與并行計(jì)算,我們可以把CPU+GPU異構(gòu)協(xié)同計(jì)算劃分成兩種計(jì)算模式:

1)       CPU/GPU協(xié)同計(jì)算:CPU只負(fù)責(zé)復(fù)雜邏輯和事務(wù)處理等串行計(jì)算,GPU 進(jìn)行大規(guī)模并行計(jì)算;

2)       CPU+GPU共同計(jì)算:由一個(gè)CPU進(jìn)程/線程負(fù)責(zé)復(fù)雜邏輯和事務(wù)處理等串行計(jì)算,其它CPU進(jìn)程/線程負(fù)責(zé)小部分并行計(jì)算,GPU負(fù)責(zé)大部分并行計(jì)算。

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

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

3           設(shè)備內(nèi)共享式

1)       CPU設(shè)備:每個(gè)節(jié)點(diǎn)內(nèi)的所有多核CPU采用了共享存儲(chǔ)模型,因此,把節(jié)點(diǎn)內(nèi)的所有多核CPU看作一個(gè)設(shè)備, 可以采用MPI進(jìn)程或OpenMP線程、pThread線程控制這些CPU核的并行計(jì)算。

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

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


圖1 CPU+GPU異構(gòu)協(xié)同計(jì)算架構(gòu)

表1 CPU+GPU異構(gòu)協(xié)同計(jì)算編程模型

 

節(jié)點(diǎn)間分布式

節(jié)點(diǎn)內(nèi)異構(gòu)式

設(shè)備內(nèi)共享式

CPU

GPU

模式1

MPI

OpenMP

OpenMP

CUDA/OpenCL

模式2

MPI

MPI

OpenMP

CUDA/OpenCL

模式3

MPI

MPI

MPI

CUDA/OpenCL

二、    CPU+GPU協(xié)同計(jì)算負(fù)載均衡性設(shè)計(jì)

下面以模式2為例簡(jiǎn)單介紹多節(jié)點(diǎn)CPU+GPU協(xié)同計(jì)算任務(wù)劃分和負(fù)載均衡,模式2的進(jìn)程和線程與CPU核和GPU設(shè)備對(duì)應(yīng)關(guān)系如圖2所示。若采用主從式MPI通信機(jī)制,我們?cè)诠?jié)點(diǎn)0上多起一個(gè)進(jìn)程(0號(hào)進(jìn)程)作為主進(jìn)程,控制其它所有進(jìn)程。每個(gè)節(jié)點(diǎn)上啟動(dòng)3個(gè)計(jì)算進(jìn)程,其中兩個(gè)控制GPU設(shè)備,一個(gè)控制其余所有CPU核的并行,在GPU內(nèi)采用CUDA/OpenCL并行,在CPU設(shè)備內(nèi)采用OpenMP多線程并行。

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

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

對(duì)于CPU+GPU協(xié)同計(jì)算,由于CPU和GPU計(jì)算能力相差很大,因此,在對(duì)任務(wù)和數(shù)據(jù)劃分時(shí)不能給CPU設(shè)備和GPU設(shè)備劃分相同的任務(wù)/數(shù)據(jù)量,這就增加了CPU與GPU設(shè)備間負(fù)載均衡的難度。CPU與GPU之間的負(fù)載均衡最好的方式是采用動(dòng)態(tài)負(fù)載均衡的方法,然而有些應(yīng)用無法用動(dòng)態(tài)劃分而只能采用靜態(tài)劃分的方式。下面我們分別介紹動(dòng)態(tài)劃分和靜態(tài)劃分。

1)       動(dòng)態(tài)劃分:對(duì)于一些高性能計(jì)算應(yīng)用程序,在CPU與GPU之間的負(fù)載均衡可以采用動(dòng)態(tài)負(fù)載均衡的優(yōu)化方法,例如有N個(gè)任務(wù)/數(shù)據(jù),一個(gè)節(jié)點(diǎn)內(nèi)有2個(gè)GPU卡,即三個(gè)設(shè)備(CPU和2個(gè)GPU),動(dòng)態(tài)負(fù)載均衡的方法是每個(gè)設(shè)備先獲取一個(gè)任務(wù)/數(shù)據(jù)進(jìn)行計(jì)算,計(jì)算之后立即獲取下一個(gè)任務(wù),不需要等待其他設(shè)備,直到N個(gè)任務(wù)/數(shù)據(jù)計(jì)算完成。這種方式只需要在集群上設(shè)定一個(gè)主進(jìn)程,負(fù)責(zé)給各個(gè)計(jì)算進(jìn)程分配任務(wù)/數(shù)據(jù)。

2)       靜態(tài)劃分:在一些應(yīng)用中,無法采用動(dòng)態(tài)劃分的方式,需要靜態(tài)劃分方法,然而靜態(tài)劃分方法使異構(gòu)設(shè)備間的負(fù)載均衡變得困難,有時(shí)甚至無法實(shí)現(xiàn)。對(duì)于一些迭代應(yīng)用程序,我們可以采用學(xué)習(xí)型的數(shù)據(jù)劃分方法,如先讓CPU和GPU分別做一次相同計(jì)算量的計(jì)算,然后通過各自的運(yùn)行時(shí)間計(jì)算出CPU與GPU的計(jì)算能力比例,然后再對(duì)數(shù)據(jù)進(jìn)行劃分。


圖2 CPU+GPU協(xié)同計(jì)算示意圖(以每個(gè)節(jié)點(diǎn)2個(gè)GPU為例)

三、    CPU+GPU協(xié)同計(jì)算數(shù)據(jù)劃分示例

假設(shè)某一應(yīng)用的數(shù)據(jù)特點(diǎn)如圖3所示,從輸出看,結(jié)果中的每個(gè)值的計(jì)算需要所有輸入數(shù)據(jù)的信息,所有輸出值的計(jì)算之間沒有任何數(shù)據(jù)依賴性,可以表示成outj=;從輸入看,每個(gè)輸入值對(duì)所有的輸出值都產(chǎn)生影響,所有輸入數(shù)據(jù)之間也沒有任何數(shù)據(jù)依賴性。從數(shù)據(jù)特點(diǎn)可以看出,該應(yīng)用既可以對(duì)輸入進(jìn)行并行數(shù)據(jù)劃分也可以對(duì)輸出進(jìn)行數(shù)據(jù)劃分。下面我們分析CPU+GPU協(xié)同計(jì)算時(shí)的數(shù)據(jù)劃分方式。


圖3 并行數(shù)據(jù)示例

1         按輸入數(shù)據(jù)劃分

假設(shè)按輸入數(shù)據(jù)劃分,我們可以采用動(dòng)態(tài)的方式給每個(gè)CPU或GPU設(shè)備分配數(shù)據(jù),做到動(dòng)態(tài)負(fù)載均衡,然而這種劃分方式,使所有的線程向同一個(gè)輸出位置保存結(jié)果,為了正確性,需要使所有的線程對(duì)每個(gè)結(jié)果進(jìn)行原子操作,這樣將會(huì)嚴(yán)重影響性能,極端情況下,所有線程還是按順序執(zhí)行的。因此,這種方式效果很差。

2         按輸出數(shù)據(jù)劃分

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

3         按輸入和輸出同時(shí)劃分

由于按輸入或按輸出劃分都存在不同的缺點(diǎn),我們可以采用輸入和輸出同時(shí)劃分的方式進(jìn)行數(shù)據(jù)劃分,如圖4所示。

從輸出角度,讓所有的計(jì)算進(jìn)程(設(shè)備)都有一份計(jì)算結(jié)果,設(shè)備內(nèi)的線程對(duì)結(jié)果進(jìn)行并行計(jì)算,每個(gè)設(shè)備都有一份局部的計(jì)算結(jié)果,所有設(shè)備都計(jì)算完畢之后,利用MPI進(jìn)程對(duì)所有設(shè)備的計(jì)算結(jié)果進(jìn)行規(guī)約,規(guī)約最后的結(jié)果即是最終的結(jié)果。

從輸入角度,按輸入數(shù)據(jù)動(dòng)態(tài)劃分給不同的計(jì)算進(jìn)程(設(shè)備),這樣可以滿足所有的計(jì)算進(jìn)程負(fù)載均衡。


圖4 CPU+GPU協(xié)同計(jì)算數(shù)據(jù)劃分示例

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

2013年1月9日 #

     摘要: http://devgurus.amd.com/thread/158866VLIW on Cypress and vector addition此問題被 假設(shè)已回答。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 閱讀(512) | 評(píng)論 (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 瀏覽次數(shù)
  • 有用答案Re: Low ALUBusy and low FetchUnitBusy
    peshNewbie
    pesh 2012-3-26 上午7:07 (回復(fù) 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 (回復(fù) 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 (回復(fù) 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 閱讀(454) | 評(píng)論 (0)編輯 收藏

     摘要: http://devgurus.amd.com/thread/159558Understanding performance counters此問題被 假設(shè)已回答。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 閱讀(534) | 評(píng)論 (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 閱讀(370) | 評(píng)論 (0)編輯 收藏

僅列出標(biāo)題  下一頁(yè)
青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            欧美国内亚洲| 欧美高清视频一区二区| 含羞草久久爱69一区| 国产精品影音先锋| 国产精品普通话对白| 国产精品美女久久久免费| 国产精品乱码妇女bbbb| 国产精品一区二区三区乱码| 国产午夜精品一区理论片飘花| 国产婷婷色一区二区三区在线| 国产综合精品| 亚洲人成网站999久久久综合| 99热免费精品在线观看| 亚洲欧美日韩在线| 麻豆精品精品国产自在97香蕉| 欧美激情视频免费观看| 亚洲精品乱码久久久久久久久| 免费高清在线视频一区·| 美女主播一区| 日韩视频免费看| 午夜精品一区二区三区电影天堂| 久久精品一本| 国产精品va在线播放| 国产最新精品精品你懂的| 亚洲三级免费电影| 欧美一级专区| 亚洲人成啪啪网站| 国产欧美另类| 欧美国产亚洲视频| 一区二区三区日韩精品视频| 欧美一区视频在线| 欧美风情在线观看| 国产精品欧美激情| 亚洲国产日韩一区| 欧美一区二区三区四区在线 | 亚洲欧洲精品成人久久奇米网| 亚洲视频香蕉人妖| 久久久久久久久久久久久9999| 欧美色视频日本高清在线观看| 尤物精品在线| 性欧美精品高清| 亚洲人午夜精品| 亚洲人成在线播放网站岛国| 久久福利视频导航| 欧美一级电影久久| 欧美肉体xxxx裸体137大胆| 精品av久久久久电影| 亚洲永久在线观看| 亚洲国产三级网| 久久精品综合一区| 国产视频自拍一区| 欧美影院视频| 亚洲天堂av图片| 欧美日韩国产色视频| 在线观看视频一区二区| 久久精品视频免费播放| 夜夜嗨av色综合久久久综合网| 麻豆精品视频在线观看| 国语自产精品视频在线看抢先版结局| 亚洲一区二区免费| 亚洲毛片av在线| 欧美日韩国产影院| 中文精品视频| 宅男66日本亚洲欧美视频| 欧美欧美天天天天操| 亚洲人在线视频| 国产精品视频男人的天堂| 亚洲综合不卡| 亚洲一区日韩| 国产精品丝袜xxxxxxx| 欧美影片第一页| 久久精品日韩欧美| 亚洲成人原创| 欧美国产日韩一区| 欧美高清影院| 中文有码久久| 亚洲伊人网站| 国产一区二区三区网站 | 美脚丝袜一区二区三区在线观看| 欧美在线日韩精品| 在线免费观看日韩欧美| 亚洲国产高清aⅴ视频| 欧美精品在线观看| 午夜日韩激情| 麻豆成人在线| 亚洲欧美精品一区| 久久人体大胆视频| 99视频超级精品| 亚洲一区二区在线看| 韩国精品久久久999| 亚洲国产精品成人| 国产精品三上| 亚洲电影在线| 国产日产高清欧美一区二区三区| 欧美大片免费观看| 国产精品国产馆在线真实露脸| 久久久精品午夜少妇| 欧美好骚综合网| 久久精品最新地址| 欧美日韩免费在线| 猛男gaygay欧美视频| 欧美亚州韩日在线看免费版国语版| 久久全球大尺度高清视频| 国内精品**久久毛片app| 欧美一级淫片播放口| 久久综合五月| 欧美影院在线播放| 欧美成ee人免费视频| 午夜欧美视频| 欧美日韩国产经典色站一区二区三区| 久久国产88| 欧美日韩伦理在线免费| 久久亚洲私人国产精品va媚药| 欧美日韩国产在线播放| 男女av一区三区二区色多| 国产精品女主播在线观看| 亚洲黄网站在线观看| 黄网站色欧美视频| 亚洲欧美国产精品专区久久| 一本色道久久综合亚洲91| 欧美激情在线观看| 国产欧美日韩视频一区二区| 久久久人成影片一区二区三区 | 国产欧美在线观看| 91久久精品www人人做人人爽| 国产一区二区三区电影在线观看| 亚洲精品免费看| 亚洲日本va午夜在线电影| 久久久精品日韩| 久久狠狠一本精品综合网| 国产精品99免费看 | 国产精品美女| 亚洲精品一区二区三区蜜桃久| 在线观看国产欧美| 香蕉乱码成人久久天堂爱免费| 亚洲专区一区| 国产精品久久久久三级| 日韩西西人体444www| 99伊人成综合| 欧美日韩亚洲不卡| 一区二区日韩伦理片| 中文亚洲字幕| 国产精品久久久久久一区二区三区 | 久久精品国产99精品国产亚洲性色 | 久久精品99无色码中文字幕| 欧美与欧洲交xxxx免费观看| 国产精品永久免费在线| 一区二区三区www| 午夜精品久久久久久久99热浪潮 | 亚洲激情第一页| 欧美一区二区三区的| 中文国产亚洲喷潮| 久久久久国产精品一区二区| 亚洲欧美日韩综合国产aⅴ| 欧美激情按摩| 日韩一级片网址| 亚洲一区二区少妇| 久久乐国产精品| 欧美日韩伦理在线| 欧美先锋影音| 亚洲综合视频一区| 国产精品亚洲一区二区三区在线| 日韩图片一区| 欧美一区二区在线视频| 激情综合色丁香一区二区| 美女福利精品视频| 亚洲精品一区在线观看| 午夜欧美大尺度福利影院在线看 | 亚洲国产精品国自产拍av秋霞| 一区二区三区回区在观看免费视频| 欧美日韩亚洲免费| 午夜精品久久久久久久久| 欧美/亚洲一区| 亚洲视频综合在线| 激情六月婷婷综合| 欧美日韩精品欧美日韩精品| 亚洲一区二区精品视频| 老司机成人在线视频| 一本色道久久综合亚洲精品高清| 国产欧美日韩亚洲| 免费短视频成人日韩| 亚洲男人天堂2024| 亚洲第一成人在线| 久久精品123| 中文成人激情娱乐网| 1024成人网色www| 国产精品手机在线| 欧美高清视频一区二区| 欧美亚洲一区三区| 亚洲免费av片| 欧美成人中文字幕| 欧美在线观看一区| 亚洲性av在线| 亚洲理伦在线| 亚洲第一天堂av| 国产欧美精品久久| 欧美日韩伦理在线| 欧美精品麻豆| 免费观看一区| 久久一区二区精品|