開場
女士們、先生們，ACM 主席 Stuart Feldman。 我很榮幸能介紹圖靈演講。 首先，如果可以的話，請允許我介紹 Intel 的 Andrew Chen。 他是副總裁兼研究部主任。 他們一直是非常慷慨的圖靈獎贊助商。 請他上台先說幾句話。謝謝您，Andrew。 謝謝 Stu。非常高興來到這裡。 我很高興 Intel 能夠贊助圖靈獎。 這已經是我們連續第五年贊助了，所以我們非常自豪。 當然，圖靈獎表彰的是技術卓越、創新和影響力的頂峰， 這不僅是我們 Intel 所有人都嚮往的，也推動著我們的領域向前，推動著產業向前。 因此，我們非常高興能與此聯繫在一起。 特別是今年，我想我們對圖靈獎感到特別高興， 因為，當然，正如我們所知，圖靈獎頒發給了 Fran Allen，她昨晚獲獎了， 以表彰她在程式設計生產力、高階程式語言、 編譯器最佳化，當然還有效能方面的工作，這是我們所有人都依賴、 並賴以推動產業向前發展的東西。 我只想說，她今年獲得這個獎項，我認為特別恰當， 因為她以在 P-Trans 系統（平行翻譯系統）上的工作而聞名， 他們在那裡做了很多關於揭示程式中平行性的工作。 而今天，平行性當然是我們所有計算系統的核心， 從高階到桌上型到行動裝置，甚至微小的行動裝置和嵌入式系統。 因此，我只想說，我們非常高興能與圖靈獎聯繫在一起並能夠支持它。 謝謝。 謝謝。 我很榮幸為大家介紹 Fran Allen 進行這次演講。 我有幸認識她很多年了。 她在職業生涯早期在編譯器、程式分析方面所做的工作， 以及一些非常早期、絕對古怪的超級電腦。 我的意思是，我多年前確實很喜歡閱讀 Stretch 手冊。 那是在我理解你實際上必須編譯某些東西之前，我不知道那是如何做到的。 在我多年的編譯器和程式語言生涯中， Fran 的幾代研究團隊是許多領域的明確領導者，引入了完全必要的概念， 將程式表示為圖形的概念。 嗯，今天很難想像其他的了。 用於最佳化的區間（intervals）、支配關係（dominance），所有這些都是絕對出色的貢獻。 其中許多直接來自 Fran。 當然，所有這些都來自 Fran 的朋友和同事圈子。 所以，讓我簡單地把這個交給 Fran，感謝她，一位偉大的同事，一位真正偉大的電腦科學家。 謝謝。 謝謝 Steve。 謝謝。
無所不在的平行性挑戰
嗯，我對能來到這裡並獲得圖靈獎感到無比興奮。 而且我知道，雖然我看不大清楚你們，但我有很多朋友和同事，他們為我獲得獎項的工作做出了貢獻。 我會盡快進入我的演講，但我確實想說，這改變了我的生活。 我想也許這改變我生活的主要方式是，我可以有很多次的聽眾。 所以今天下午我要做的是，稍微談談被介紹為「處處平行性」、「無所不在的平行性」的時代， 這將是對語言，尤其是編譯器來說，一個引人入勝的挑戰。 這是我的專業領域。 所以我會專注於此。 要能夠富有成效地利用這種平行性並實現它所承諾的效能，這將是一個挑戰。 所以我想談談現在這種平行性從何而來以及它的軌跡。 然後我想回頭，一開始就給你們幾個挑戰，然後再介紹我個人主要與高效能編譯器相關的歷史。 從中，我想我們可以得出一些經驗教訓，無論是正面的還是負面的。 然後在我的演講結束時，我想回到現在應該做什麼。 我相信我們正處於一個巨大的機會點，一個非常大的遊戲改變者，那就是無所不在的平行性。 我將特別挑戰我的領域，思考他們將如何前進。
正如所說，平行性正在走向筆記型電腦和桌上型電腦。 它不再像過去許多年、許多年那樣僅僅用於高效能計算。 現在它將無處不在。 這是由技術的發展所驅動的。 為了維持基礎技術賦予我們的效能曲線，我們將不得不尋求平行性作為繼續沿著這條曲線前進的方法。 所以我們的社群將會面臨一些問題，比如通用計算將如何使用這些新平台，以及我們必須對高階語言、系統和軟體做些什麼？
效能將不會像過去那樣持續增長。 這裡有一些關於這方面的更多資訊。 發生了什麼事？ 密度縮放（density scaling）繼續提供電晶體，但實際上存在一個問題。 電晶體必須是低功耗的。 我們有頻率、散熱的問題。 但是每個處理器將會變得不那麼強大。 那麼我們如何才能保持我們曾經假設的效能呢？
這是左邊 Y 軸表示 gigaops，粉色表示 Moore's law（摩爾定律）中電晶體數量的圖片。 但是我們真正感興趣的實際效能將不會存在，除非我們利用這個。 這是另一種形式的曲線的另一個例子，其中單執行緒效能正偏離直線。 因此，隨著核心數增加，片上處理器增多，我們可以將其用於吞吐量（throughput）。 換句話說，例如，能夠在每個核心上運行多個作業，晶片的效能看起來相同，但這不是單個應用的效能。
據我從技術人員那裡聽到的，摩爾定律將繼續保持每 18 到 24 個月核心數翻倍。 到 2021 年，一個晶片上將有 1000 個核心。 如果我們要將所有這些核心應用於單個應用程式，這就是所謂的「瘋狂程度的平行性」（lunatic level of parallelism）。 那麼我們如何才能繼續下去，這是我們社群面臨的挑戰，這基本上是一個軟體挑戰。 當然還有系統挑戰，這是軟體的一部分。
個人回顧：高效能編譯器的歷史
所以這就是我們正在前進的方向，但現在我想停下來問：我們是怎麼走到今天的？ 不是從技術基礎的角度來看，而是在高效能計算的歷史中，我們學到了很多教訓。 我要回溯，我將按照以下方式進行：我將談論一些關於 Fortran 的內容，然後是硬體並行性（hardware concurrency），然後是平行電腦（parallel computers），然後是大規模平行系統（massively parallel）。 這是一次個人之旅，介紹了我親身經歷的關於並行性、平行系統和大規模平行系統的所有這些系統的歷史。
正如 Jim Gray 所說，我想那是在他的圖靈獎演講中，起初，有 Fortran。 我不是 Fortran 專案的一部分。 我於 1957 年 7 月 15 日作為一名程式設計師加入 IBM 研究部門。 Fortran 專案於當年早些時候，即 1957 年 4 月 15 日完成並成為產品交付。 所以它已經有 50 年歷史了，我們應該慶祝 Fortran 的 50 周年，但我想我們今年似乎錯過了。 我們也懷念 John Backus。 這是 John Backus 的專案，他於今年春天去世，這是我們領域的巨大損失。 但讓我告訴你一些關於 John 如何構思 Fortran 的事情。 在 1954 年，有一個非常粗略的語言大綱，它實際上是數學公式，隨著語言在專案的幾年（實際上是三年）中成熟，儘管他總是告訴他的經理六個月內完成。 所以那個專案的目的是提高使用者生產力，John 制定了一些非常具體的目標，關於使用者在調試和開發程式碼上花費的時間，他實際上想讓使用者更容易使用。 這裡的使用者角色以及他們使用機器的能力，機器是 704，但每個處理器將變得不那麼強大，那麼我們如何才能保持我們曾經假設的效能呢？ 這是左邊 Y 軸表示 gigaops，粉色表示 Moore's law（摩爾定律）中電晶體數量的圖片，但是我們真正感興趣的實際效能將不會存在，除非我們利用這個。 這是另一種形式的曲線的另一個例子，其中單執行緒效能正偏離直線，因此隨著核心數增加，片上處理器增多，我們可以將其用於吞吐量。 換句話說，例如，能夠在每個核心上運行多個作業，晶片的效能看起來相同，但這不是單個應用的效能。 而這將如何展開，據我所知，
Fortran 初期 (IBM 704)
在 Fortran 方面。我在那個夏天獲得的經驗，以及對語言本身、編譯器及其產生的目標程式碼的深刻理解，它確實滿足了這個要求，在幾乎每個作業上都表現得更好，而且是以令人驚訝的方式。他們做了一些今天沒有任何編譯器會做的最佳化。我也不知道有任何編譯器後來做過類似的，這與在某些情況下將陣列線性化有關。他們確實做得非常出色。所以這個專案的目標變成了我的目標。它必須有一個好的使用者介面，一個讓使用者表達他們問題的好方法，並提高他們的生產力，而且它必須在效能和所有其他功能方面利用好這台機器。所以編譯器本身是令人驚嘆的，不僅語言令人驚嘆，編譯器也令人驚嘆。正式解析技術的開端是在其第一階段完成的。這是我一直在研究的，那位做了這個的人的歷史，他在哪裡接受的教育，以及他如何在這個初始系統上做了一個非常正式的語言工作，組建了一個非常正式的語言工作。有一個用於最佳化的中間語言形式。有控制流圖（control flow graphs）。事實上，它們就被稱為控制流圖，它們以圖形方式表達了程式設計師。而最佳化的術語，如「共同子表達式消除」（common sub-expression elimination），被明確地使用。那是他們的措辭，共同子表達式消除。然後為 704 機器上的三個暫存器進行廣義的暫存器分配。如我所說，程式碼確實非常出色。所以，如我所說，這些成為了我的目標。
硬體並行性 (Stretch 與 Harvest)
從那以後，我參與了下一台機器，即 IBM 一台非常先進的機器，Stretch 機器，它於 1956 年啟動。在我剛加入時它正在進行中，並且預期比任何現有機器快 100 倍。這是由公司總裁宣布的，這裡有一張 Fred Brooks 的照片。有許多人參與其中，但 Fred 在塑造專案的建設方式方面發揮了特別重要的作用。現在，可能不為人知的是，為了達到 100 倍的速度，他們在 1955 年就知道主要的效能限制將是記憶體存取時間。我們至今仍在努力解決這個問題。我們有快取（caches），我們有各種各樣的機器設計，你們還會看到更多。但那是必須解決的關鍵問題。這導致了在那個非常早期的時期，一個極其野心勃勃的硬體和一個非常野心勃勃的編譯器，我和許多其他人參與其中。Stretch 的並行性（concurrency），這是我認為並行性變得極其重要並對架構師和編譯器等變得可見的地方，但 Stretch 的並行性實際上是為了解決這個記憶體存取問題而設計的。所以記憶體組織非常有趣，他們能夠同時有六個資料參考在執行中（in flight）。他們建立了一個令人驚嘆的複雜的指令預取單元（instruction look-ahead unit）。那是 John Cox 的工作，他於 1956 年加入，它可以同時執行許多平行指令，我想是 11 個。在預取單元中，它呈現出一個順序機器的外觀，所以實際上是有回退（back-out）機制的。他們可以回退預取。我最近發現了一些手寫資訊，讓我認為它是超純量（super-scalar）的。同一時間可以有多個指令在執行中。那個詞根本沒有被使用。它是管線化的（pipelined），並且是多程式的（multiprogrammed）。它是一個多程式系統，還有 IO 等等。這大部分只是為了克服記憶體延遲（memory latency），這種並行性，但你們應該看看他們在數值方面做了什麼。它是位可定址的（bit addressable），並且可以有各種中斷。這是一台令人驚嘆的機器。
連接到它的是一個加速器，可以是一個加速器，是我們為 NSA（美國國家安全局）用於解碼而建造的，獨一無二。我在 NSA 待了一年，協助安裝、研究安裝一個叫做 Alpha 的東西，這是我協助 NSA 設計的一種解碼語言。它本身就是一種令人驚嘆的語言，你可以指定字母表，比如西里爾字母、希臘字母，或者如果你想的話，母音，然後尋找模式，它是一種模式匹配語言，然後人們可以尋找模式，這基本上就是解碼的內容，就是尋找模式。最後，我寫了一個驗收測試，看看這種語言連同 Harvest Stretch 機器在模式匹配領域是否運行令人滿意，並使用 Alpha 語言自動摘要 Time 雜誌的文章，我當時很害怕做這個驗收測試，這台機器的最終驗收測試，必須自動摘要文章，順帶一提，這在當時是一個非常熱門的話題。但是有了語言本身，有了這台特定的電腦，所有這些作為一個單元設計，我能夠用非常非常少的程式碼行來編寫自動摘要。這確實非常令人驚訝。我最近查看了一下，如果有一樣的機器、一樣的語言，是否可以用於一些基因工作、基因模式匹配，事實上，我認為可能用不到一頁程式碼就能做到。這真的，這裡的訊息是，如果能夠讓架構、語言和問題同步，實際上可以完成很多事情。現在我們做不到這一點，我猜，在將來會在桌上型電腦和筆記型電腦上平行運行的應用程式的情況下，因為它們需要更加通用，我們需要處理更通用的應用程式，但我認為不應該考慮更領域特定的語言，這些語言可以為使用者提供非常簡潔的寫程式碼方式，而不是試圖迫使使用者處理我們今天使用的通用語言，這一點並不清楚。
對於在場對架構感興趣的人來說，我相信，如果情況是這樣，我會很感興趣，我相信 Harvest 附件是唯一一個在時脈層級上完全平衡 I.O.、記憶體和計算速度的系統，因此他們可以從世界各地的監聽站串流收集在磁帶上的資料，那是特殊的磁帶，然後直接通過記憶體進入計算單元，那裡的指令可以持續運行幾個小時，因為它們在分析、尋找資料和各種模式。這是一項完全串流的工作。總之，我認為這個問題以某種形式仍然存在，但這是一個有趣的架構，我知道對於我們今天進行的許多串流資訊來說，它會很有趣，這些資訊不一定與解碼有關。
所以這是我將展示的唯一一張編譯器圖片。這是為 Stretch Harvest 編譯器系統設計的編譯器，有多種原始語言，彼此差異很大，Fortran、Autocoder 2（Gene Samet 可以告訴你更多，而不是我），以及用於 Harvest 的 Alpha 語言，然後以與 Fortran 編譯器非常相似的方式組織，編譯器被分解，組織得非常相似。因此，它將程式碼翻譯成中間形式，一個最佳化器，它獨立於語言，也獨立於目標機器（Stretch 和 Stretch Harvest），然後是一個暫存器分配器，將中間語言在語義上降級為更像暫存器語言的形式，然後可以映射到機器上。
Stretch 專案的成果與教訓
所以這個專案的成果，它在很早的階段就包含了如此多的發明，是它太慢了。公司基本上公開對此道歉，並表示他們會為客戶建造他們承諾的機器，然後就結束了。我的意思是，對我來說最大的尷尬之一是，用 Fortran 編寫的天氣程式（天氣預測程式）需要 18 小時才能完成 24 小時的預測。而且很明顯，我們在能力上過度承諾了，所以我們當時不得不在編譯方面發明幾乎所有東西。我們在專案的幾乎每個方面都過於雄心勃勃，但編譯器本身也過於雄心勃勃，儘管我參與了介面和結構的設計，並負責最佳化器，這是一次令人警醒的經驗。然而，我花了大部分時間的 Harvest 運行得很好，運行了 14 年，但它是最高機密，所以我們不知道到底發生了什麼。
IBM System/360
好的，在這個特定時期，在 IBM，我們從 Stretch 的失敗中走出來，在 1960 年，大約在 60 年代初期，IBM 決定，隨著多台機器的出現，
一個系列用於工程科學，另一個系列用於商業，他們將建立單一架構，即 360，並將兩者合併。當然，Fred Brooks 從 Stretch 轉移過來，帶走了一些優秀的人才，開始致力於 360。這是一個有趣的故事，大家都知道，但我認為其中有一個小部分值得一提的是，Fred 和 John Backus 以有些相似的方式處理這些專案。他們設定了非常具體、非常明確的目標，並且從未動搖過這些目標。這些是高層次的目標。然後 Fred 所做的是，總體目標是設計一種架構，使其能涵蓋從非常便宜的機器到非常高效能、昂貴的機器。然後他意識到要實現這個目標，指令集將會很重要。他實際上舉辦了一場競賽。團隊內部對建立滿足效能成本目標的指令集標準有很多分歧。然後他，這就是讓那個系統成功的原因。那確實是一項「賭上公司」（bet the company）的決策。
進階計算系統 (ACS)
現在，John Cocke 和我，也許還有幾個人，特別是 John Cocke，仍然決心要建造世界上最快的機器，對不起，世界上最快的機器。所以，我們從產品開發部門回來，我們在那裡為 Stretch 系統工作了幾年，然後回到研究部門，建造世界上最快的機器。這次有一些技術進步。再次，並行性（concurrency）極其重要，硬體並行性，仍然是單一指令流。在機器的設計中，有管線化（pipelined）和超純量（superscalar）、分支預測（branch prediction），所有這些都來自那裡，亂序執行（out-of order execution）、指令和資料快取（instruction and data caches），所有這些都是為了主要在這裡，你們會再次注意到，是為了從記憶體或其他地方存取資料。所以，這些都是用於保持計算單元滿載並忙碌，同時存取記憶體的方法。這次，編譯器早期就建立了，以驅動硬體設計，包括應該有多少個暫存器，快取的特性是什麼，所有這些。我們有一個實驗性編譯器，在機器設計之前就已經建好了。事實上，這台機器從未建造過。但這就是為什麼你們可能從未聽說過太多關於它的原因。
由於機器的複雜性，編譯器生成的程式碼有時比最佳的手寫程式碼還要快。我們曾聘請芝加哥大學的一個團隊編寫一些數值分析核心（kernels）。他們在夏天結束時報告，他們來拜訪我們，他們有精確的週期數，可以在機器上用這麼多週期完成。對於每一個，我們只是把它丟進編譯器，寫了一個小小的 Fortran 程式，通過我們的編譯器運行，結果擊敗了那些花了整個夏天努力將每個程式碼的週期數降到最低的學生。原因在於編譯器內建了關於一台非常複雜的機器的大量知識。這台機器理論上可以同時執行 51 個指令，而使用者沒有辦法管理所有資源來實現這一點。所以這是另一個突出的點，我一直銘記在心，那就是你可以擁有，我們常常通過硬體和架構中非常複雜的設計來獲得效能，但越複雜，我們就越迫切需要能夠編碼處理這些複雜性的最佳方法的編譯器。
ACS 專案的成果與教訓
因此，從進階計算系統（ACS）的編譯器最佳化結果中，產生了語言獨立、機器獨立的最佳化方法。我們不知道這台機器如果真的建成會有什麼語言，我們在建造編譯器時也不知道這台機器的特性。這也為程式分析和最佳化提供了理論基礎，當然是建立在早期工作之上的。我的意思是，這些東西不是憑空出現的。然後我們實驗了許多最佳化方法並對其進行了分類，包括深度指令排程（deep instruction scheduling）和暫存器分配（register allocation）。據我所知，我們還沒有真正解決指令排程和暫存器分配之間的相互作用問題，但自那以後，這個領域已經有了許多精彩的工作。
所以在 ACS 被取消之後，那是一段非常悲傷的時期。這是一個很棒的專案，無論是 Stretch 還是 ACS，對我們參與其中的人來說都是很棒的專案。但從一開始就很清楚，這是一個愚蠢的專案，不該啟動、投入工作，因為公司沒有辦法在他們努力推出 360 的時候，允許一台完全不同的高效能電腦存在。所以它被取消了，但就像所有這些極其野心勃勃的專案一樣，它產生了巨大的餘波，我們學到了很多，而且在這樣一個專案的每個層面。它在最基礎的層面上推動了技術，推動了為效能設計架構，也推動了為向使用者提供效能而設計編譯器。
1970 年代的整合與轉向
所以 70 年代成為一個整合時期，這是一個我們在 IBM 仍然在做單一指令流、單執行緒的時期。所以我們在 360 機器上做向量化（vectorization），做全程式分析（whole program analysis），推進最佳化方法，在演算法方面做了很多研究。我多年來觀察到的一點是，做一個專案，建造一台機器或一個編譯器或其他任何東西，會顯示出許多精彩的新解決方案，這些解決方案通常都是半成品，它們並不完全奏效，但你必須把它弄出來並趕上進度。而當有一點時間，或者當有一些學生在身邊時，就可以開始去研究它，並試圖在其背後建立一個理論，試圖更好地組織工作。所有這些都發生在這個時期，但是 John Cocke，他是一位...他實際上以某種非常根本的方式推動了這個高效能領域，他決定不再建造任何高效能電腦，他要去追求成本效能（cost performance），在成本效能中找到最佳點，這最終成就了 IBM 的 PowerPC。
從單執行緒到平行性
現在我想轉向從單執行緒到平行性。這發生在 1980 年代初期，但另一件事也發生了，那是早在 1973 年，我對此非常非常不開心，那就是 C 語言的出現。在我看來，它讓我在編譯器方面預見到的進步脫軌了。你不能讓使用者擺弄位址，使用程序，擺弄指標（pointers），指標指向資料，同時還能理解如何轉換程式以使其運行得更優化。在那段時期的 SIGPLAN 會議上，關於最佳化相對必要性進行了一場有趣的辯論，當時提出的觀點是，不再需要最佳化了。所以，不管怎麼說，你可以有自己的看法，但我知道我對此毫無疑問，它確實是對，在我看來，語言和編譯器以及輕鬆為使用者提供效能的能力造成了巨大的挫折。
PTRAN 專案 (自動平行性)
好的，然後在 80 年代中期，我想是在 1983 年左右，我在 IBM 被要求實際做一些關於編譯平行性的工作。那時我們有點晚了，伊利諾伊大學（University of Illinois）已經有一些很棒的工作，來自 Iliac 和 Dave Cook 在編譯器方面的工作，那真是太棒了，我們在這個工作的基礎上，聘請並組建了一支來自不同大學的人才團隊，包括 Cook 團隊的 Ron Citron，紐約大學（NYU）的，他們在編譯器和平行性方面做了很多工作，還有來自很多地方的人。這是一支很棒的團隊，我們當時正在研究兩件事。一個是關於自動平行性的一些研究，伊利諾伊大學已經有了一個好的開端，另一件事是我們工作的方式是建造、針對一些真正的機器，其中之一是研究平行處理原型機（Research Parallel Processor Prototype），它是紐約大學 Ultracomputer 的衍生品，一台真正的平行處理器，有，嗯，我想原本應該有 112 個，最終有 64 個獨立處理器，配備一個迷人的記憶體系統，可以是共用記憶體，也可以做向量化。但這裡的重點是，我們當時，這個專案同時進行理論研究和實際建造程式碼在真實機器上運行。
PTRAN 的主要成果
因此，這也導致了對平行程式碼的新執行時技術的研究，包括調試、視覺化等等。這些是完整的系統，而不僅僅是一個編譯器，因為我們當時與 IBM 的一些程式一起工作。因此，從中產生了相當多的成果。我已經把它們列在這裡了，在場的人也為這些成果做出了貢獻。事實上，昨晚精彩的宴會上，PTRAN 團隊的許多人都來了並參加了宴會。所以昨晚在另一家飯店是 PTRAN 團隊的一次真正的重聚，太棒了。
所以這真正建立了 IBM 在平行編譯和執行時系統方面的基礎，不是靠我們自己。我的意思是，我們從很多地方吸取了經驗。我們是第一批進入這個領域的團隊，但我們對此有著強烈的關注。
然後是程式依賴圖（program dependence graphs），那是 Gene Ferranti 的工作，他將先前的資料依賴和控制依賴整合在一起。
然後是一些關於建構有用平行性的工作。轉換（Transformations）實際上就像最佳化一樣，轉換涉及分析，然後進行轉換，並使轉換後產生的程式碼實際上比沒有轉換時更好。但是你必須讓分析同時進行，或者在編譯器建構方式方面預先開發。這項工作，這項令人著迷的工作，一旦知道什麼可以平行執行，然後如何從中建構出有用的平行性？因為機器有很多種平行性。有單執行緒平行性，這是機器中自然存在的並行性。但是處理器之間也有平行性，我們有許多許多描述平行性模型的方法。但如今，平行性也跨越網路和互連。所以一旦你知道你可以擁有的最大平行性，如何將其捆綁起來，使其有用並提供良好的效能？這是我們在史丹佛大學一些工作基礎上進行的一項工作。然後 Vivek Sarkar 擴展了這項工作，現在它已經在 IBM 的產品編譯器中了。
全程式分析（whole program analysis），你需要跨越所有的計算邊界。我們當然具備這個能力。
動態處理程序排程演算法（dynamic process scheduling algorithms），這是執行時方面的工作，我們在這方面有非常一流的成果。許多全程式分析是 Mike Burke 的工作。
靜態單一賦值（static single assignment）是程式內部一種有趣的重塑，它有點傾向於更接近函式式語言。這就是為什麼它被稱為單一賦值，但你不能完全將 Fortran 轉化為函式式。它在平行性中的價值在於，你能夠混合程式碼的分析和轉換，而無需在每次更改時重建整個分析事實庫。這項工作涉及 Ron Citrin、Mark Wegman、Gene Ferranti 和 Kenzedic。Kenzedic，對。謝謝。Jung Choi。Jung Choi，對。我應該說，Jung Choi 在實際上使其變得實用。他詳細說明了如何做到。這是我當時很擔心的一點，但他就是做了那部分工作的人。
我或許還應該說，我腦海中閃過的最大靈感之一是，有一次我從旅行回來，發現我的辦公桌上放著一張黃色紙片，那是在我們有靜態單一賦值之前，紙片上是關於它的第一個想法，來自 Gene Ferranti，它只是概述了轉向函式式的可能性。那時我一直在尋找某種方法可以稍微傾向於函式式，擺脫我們語言中名稱的雙重用途，即既代表值又代表位置。我就是找不到方法，它就放在我的辦公桌上，我說，就是它了。總之，那也是一個很棒的專案，我們取得了相當多的進展。
自動平行性的挑戰
所以關於自動平行性的一些小見解，更深入的要點是，其中一個非常困難的事情當然是消除資料參考的歧義（disambiguating data references）。當你有兩個資料參考，並且你試圖決定是否可以同時平行執行這兩件事時，你怎麼知道呢？你必須確切地知道記憶體中資料的狀態。而且你必須跨越程序邊界和指標，別提了，我已經對指標感到不滿了，表達了這一點。快取（Caches）是一個問題，因為東西可能根本不在記憶體中，而且有很多延遲。另一件事是形成有用的平行性需要，再次，對資料有深入的了解。
大規模平行系統 (BlueGene)
這是 BlueGene，當然 BlueGene 專案是一個大規模、大規模的平行系統，還有其他的。但現實是，對於其中一些機器，試圖自動將整個應用程式映射到這種規模和程度的平行性機器上是沒有希望的。所以這實際上是應用程式本身以適合機器的方式結構化。因此，沒有太多自動活動在進行。將應用程式與機器匹配的使用通常由應用程式使用者完成。當然，這裡也有一些角落，會有程式最佳化。
未來的挑戰：利用多核架構
所以讓我在這裡回到我開始時的真正問題。我們將如何利用多核心、多功能晶片，並使平行性有用？當然，你可以將平行性用於多個作業，但這部分不是我要談的。將平行性用於單個作業，或對機器進行分區，以便你可以利用硬體上存在的平行性。
這裡有兩個極端。一個是，在你左邊，不改變程式碼。只需，假設它是一個單執行緒程式，讓它通過傳統編譯器運行，然後有很多硬體上的東西來做推測等等。我真的不認為這會讓你走得很遠，特別是對於我們擁有的一些語言，我就不點名了。所以另一邊是完全重寫程式，可能使用一些平行語言，然後通過平行語言編譯器運行。但我認為，最有潛力的事情之一將是提高語言的層次。我們不能再像以前那樣繼續下去了。
關鍵問題與未來方向
這是我的最後一張圖表。我對這些問題中的一些答案有自己的看法。這些問題是，如果你能看清楚的話，我想，執行緒級別（thread level）。編譯器是否可以建構來從今天的順序語言中提取執行緒級別平行性和資料級別平行性？我認為會是，嗯，你知道我對那個問題的看法。我們需要新的程式語言嗎？絕對需要。而且它們必須非常非常高階。資料平行性是低垂的果實嗎？我願意把它提出來作為一個非常有趣的可能方向來研究。
語言層次的提升與資料中心語言
如果我們回顧我為 Stretch 機器提出的觀點，那就是將資料送到計算單元是一個挑戰，現在仍然是一個挑戰。而且我們處理得不對。那就是效能所在，在管理資料。那就是我們 везде 都失去效能的地方。我們知道如何進行計算，我們只是無法將資料送到計算單元。而且我們大多數時候談論的是資料，一次一個元素，一小塊。我認為有一個巨大的機會可以表達「資料在大型」（data in the large），並且能夠擁有一個系統，當資料是一級物件時，當它是以資料為中心時，當語言是以資料為中心時，那麼使用一個系統，這個系統可以對資料進行分區、移動資料、重新組織資料，並自然地消除歧義，如果它在語言層面做得對的話。
這就是我認為我們必須尋找巨大機會來實現平行性的地方。我將大力鼓勵這個團隊，特別是在座的 SIGPLAN 成員，來看看這個整體機會。這將是一個遊戲改變者，無論我們將如何，誰能把語言及其配套編譯器弄好，將對市場產生巨大影響，對在這些機器上編寫應用程式的容易程度產生巨大影響。它們將具有巨大的效能潛力。所以我希望人們會重視這一點並思考它，因為這是一個遊戲改變者。這可能是一個巨大的遊戲改變者，如果我們不做，我們就會錯過它，錯過這個機會，並且可能錯過許多年。我們現在就應該投入進去，並幫助指導硬體架構的發展，指導他們在機器上建立怎樣的程式設計模型。有很多可能性，因為隨著核心數的增長以及記憶體如何共享，快取是否有作用？它們如何，
處理器之間如何互相通信等等。所有這些目前都在很大程度上，或者部分地，或者以任何方式進行。但據我所知，它並非由編譯器可行地能做的事情，或由語言驅動，特別是如果他們擁有能夠理解並轉換以匹配硬體的語言。關於以資料為中心的語言，稍微補充一下。我參與了 HOPL 會議，剛剛結束，不幸的是我未能參加。但在 HOPL 會議上，有一種語言，ZPL，來自華盛頓大學（University of Washington），在審查時，我知道這種語言，並多年來一直與 Larry Snyder 討論，但在審查初稿時，我突然，大約翻了 40 頁後，意識到這是一種以資料為中心的語言，我們最好開始朝這個方向思考。所以這是一種方向。還有其他方向可以尋找，但我們必須做出改變。我們的社群必須抓住這個機會。
結論
好的，非常感謝各位，我希望你們的職業生涯也能像我的一樣充滿樂趣和回報。非常感謝。謝謝 Fran，帶來了精彩的故事。非常感謝，Fran。