Tại sao bộ xử lý Itanium khó viết trình biên dịch?

Người ta thường nói rằng kiến ​​trúc bộ xử lý 64 bit Itanium của Intel đã thất bại vì tập lệnh EPIC mang tính cách mạng rất khó để viết một trình biên dịch tốt, điều đó có nghĩa là thiếu công cụ phát triển tốt cho IA64, điều đó có nghĩa là thiếu nhà phát triển tạo chương trình cho kiến ​​trúc và vì vậy, không ai muốn sử dụng phần cứng mà không có nhiều phần mềm cho nó, và vì vậy nền tảng đã thất bại, và tất cả chỉ vì muốnmột móng tay móng ngựa trình biên dịch tốt.

Nhưng tại sao trình biên dịch lại là một vấn đề kỹ thuật khó khăn như vậy? Dường như với tôi rằng nếu tính song song rõ ràng trong EPIC khiến các nhà cung cấp trình biên dịch khó thực hiện ... tại sao lại đặt gánh nặng đó lên họ ngay từ đầu? Nó không giống như một giải pháp tốt, được hiểu rõ cho vấn đề này đã không tồn tại: thay vào đó hãy đặt gánh nặng đó lên Intel và trao cho người viết trình biên dịch một mục tiêu đơn giản hơn.

Itanium ra đời vào năm 1997. Đến thời điểm này, hệ thống mã byte P-Code của UCSD đã gần 20 năm, máy Z chỉ trẻ hơn một chút và JVM là ngôi sao mới nổi nóng trong thế giới ngôn ngữ lập trình. Có bất kỳ lý do nào khiến Intel không chỉ định ngôn ngữ "mã hóa đơn giản Itanium" và cung cấp một công cụ chuyển đổi mã byte này thành mã EPIC được tối ưu hóa, tận dụng chuyên môn của họ như những người thiết kế hệ thống ngay từ đầu?

Như tôi nhớ lại vào thời điểm đó, vấn đề không chỉ là chi tiết của IA64, đó là sự cạnh tranh với tập lệnh x86-64 của AMD. Bằng cách làm cho kiến ​​trúc của chúng tương thích ngược với tập lệnh x86, AMD đã có thể tận dụng các công cụ và bộ kỹ năng dành cho nhà phát triển hiện có. Động thái của AMD thành công đến nỗi Intel (và Via) về cơ bản buộc phải áp dụng kiến ​​trúc x86-64.

Rào cản lớn tại thời điểm đó là RAM 4 GB trên máy tính để bàn (thực tế hơn ~ 3,4 GB có thể sử dụng trên Windows). x86-64 đã phá vỡ rào cản đó và mở ra tính toán năng lượng cao hơn cho mọi người. Nếu AMD không bao giờ đưa ra x86-64, tôi chắc chắn rằng Intel sẽ rất vui khi mọi người muốn nhảy lên 4GB + RAM phải trả một khoản tiền bảo hiểm khổng lồ trong nhiều năm cho đặc quyền đó. Chứng minh thị trường di chuyển chậm như thế nào, phải mất nhiều năm để các ứng dụng bắt kịp chương trình đa luồng 64 bit và thậm chí bây giờ RAM 4GB là tiêu chuẩn trên các PC cấp thấp.

Nói tóm lại, Intel đã cố gắng tạo ra một bước nhảy vọt mang tính cách mạng với kiến ​​trúc IA64 và AMD đã thực hiện một bước tiến hóa với x86-64. Trong một thị trường được thiết lập, các bước tiến hóa cho phép những người lao động tri thức tận dụng các kỹ năng hiện có sẽ chiến thắng các bước cách mạng đòi hỏi mọi người phải học các kỹ năng mới. Bất kể sự khác biệt về chất giữa các kiến ​​trúc, IA64 không thể vượt qua động lực của nền tảng x86 của riêng mình một khi AMD thêm các phần mở rộng x86-64.

Tôi không mua lời giải thích rằng IA64 quá khó để lập trình. Nó chỉ khó khăn liên quan đến các lựa chọn thay thế. Quan điểm của @ delnan về IR cấp thấp bị ảnh hưởng, tôi chỉ không nghĩ rằng nó sẽ tạo ra sự khác biệt.

Vì sao Intel không cố gắng tự gánh vác gánh nặng đó, ai biết? Họ là sức mạnh thị trường tại thời điểm đó. AMD là một mối đe dọa nhưng Intel là vua của ngọn đồi. Có lẽ họ nghĩ rằng IA64 sẽ tốt hơn nhiều so với bất kỳ thứ gì khác mà họ có thể di chuyển toàn bộ thị trường. Có lẽ họ đã cố gắng tạo ra một tầng cao cấp và rời AMD, VIA, v.v. trong tầng thứ hai chiến đấu với phần cứng hàng hóa có lợi nhuận thấp - một chiến lược mà cả Intel và Apple đã sử dụng khá thành công.

Có phải Itanium là một nỗ lực cố ý để tạo ra một nền tảng cao cấp và kéo tấm thảm ra khỏi AMD, VIA, v.v.? Tất nhiên, đó là cách kinh doanh hoạt động.

Các bài viết trên Wikipedia về EPIC đã vạch ra những nguy hiểm nhiều chung cho VLIW và EPIC.

Nếu bất cứ ai không nắm bắt được ý nghĩa của chủ nghĩa chí mạng từ bài viết đó, hãy để tôi nhấn mạnh điều này:

Tải các phản hồi từ hệ thống phân cấp bộ nhớ bao gồm bộ đệm CPU và DRAM không có độ trễ xác định.

Nói cách khác, bất kỳ thiết kế phần cứng nào không đối phó với (*) độ trễ không xác định từ truy cập bộ nhớ sẽ chỉ trở thành một thất bại ngoạn mục.

(*) Bằng cách "đối phó", cần phải đạt được hiệu suất thực thi hợp lý (nói cách khác là "cạnh tranh về chi phí"), điều này đòi hỏi không để CPU rơi vào tình trạng nhàn rỗi trong hàng chục đến hàng trăm chu kỳ thường xuyên.

Lưu ý rằng chiến lược đối phó được sử dụng bởi EPIC (được đề cập trong bài viết Wikipedia được liên kết ở trên) không thực sự giải quyết được vấn đề. Nó chỉ nói rằng gánh nặng biểu thị sự phụ thuộc dữ liệu giờ rơi vào trình biên dịch. Tốt rồi; trình biên dịch đã có thông tin đó, vì vậy thật đơn giản để trình biên dịch tuân thủ. Vấn đề là CPU vẫn không hoạt động trong hàng chục đến hàng trăm chu kỳ trên một truy cập bộ nhớ. Nói cách khác, nó bên ngoài một trách nhiệm phụ, trong khi vẫn không đối phó với trách nhiệm chính.

Câu hỏi có thể được đặt lại là: "Với một nền tảng phần cứng được coi là thất bại, tại sao (1) không (2) các nhà văn biên dịch có thể nỗ lực anh hùng để chuộc lại nó?"

Tôi hy vọng việc đọc lại của tôi sẽ làm cho câu trả lời cho câu hỏi đó rõ ràng.

Có một khía cạnh thứ hai của sự thất bại cũng gây tử vong.

Các chiến lược đối phó (được đề cập trong cùng một bài viết) giả định rằng việc tìm nạp trước dựa trên phần mềm có thể được sử dụng để khôi phục ít nhất một phần tổn thất hiệu năng do độ trễ không xác định từ truy cập bộ nhớ.

Trong thực tế, tìm nạp trước chỉ có lợi nhuận nếu bạn đang thực hiện các hoạt động phát trực tuyến (đọc bộ nhớ theo cách liên tục hoặc có thể dự đoán cao).

(Điều đó nói rằng, nếu mã của bạn giúp truy cập thường xuyên vào một số vùng nhớ cục bộ, bộ nhớ đệm sẽ giúp ích.)

Tuy nhiên, hầu hết các phần mềm đa năng phải thực hiện nhiều truy cập bộ nhớ ngẫu nhiên. Nếu chúng tôi xem xét các bước sau:

• Tính địa chỉ, và sau đó
• Đọc giá trị, và sau đó
• Sử dụng nó trong một số tính toán

Đối với hầu hết các phần mềm đa năng, ba phần mềm này phải được thực hiện liên tiếp. Nói cách khác, không phải lúc nào cũng có thể (trong giới hạn của logic phần mềm) để tính toán địa chỉ trước hoặc tìm đủ công việc cần làm để lấp đầy các gian hàng giữa ba bước này.

Để giúp giải thích lý do tại sao không phải lúc nào cũng có thể tìm đủ công việc để lấp đầy các quầy hàng, đây là cách người ta có thể hình dung nó.

• Giả sử, để ẩn hiệu quả các quầy hàng, chúng ta cần điền vào 100 hướng dẫn không phụ thuộc vào bộ nhớ (vì vậy sẽ không phải chịu độ trễ bổ sung).
• Bây giờ, với tư cách là một lập trình viên, vui lòng tải lên bất kỳ phần mềm nào bạn chọn vào trình dịch ngược. Chọn một hàm ngẫu nhiên để phân tích.
• Bạn có thể xác định bất cứ nơi nào một chuỗi gồm 100 hướng dẫn (*) không có quyền truy cập bộ nhớ không?

(*) Nếu chúng ta có thể thực NOPhiện công việc hữu ích ...

Các CPU hiện đại cố gắng đối phó với điều tương tự bằng cách sử dụng thông tin động - bằng cách theo dõi đồng thời tiến trình của từng lệnh khi chúng lưu thông qua các đường ống. Như tôi đã đề cập ở trên, một phần của thông tin động đó là do độ trễ bộ nhớ không xác định, do đó nó không thể được dự đoán ở bất kỳ mức độ chính xác nào của trình biên dịch. Nói chung, đơn giản là không có đủ thông tin có sẵn tại thời điểm biên dịch để đưa ra quyết định có thể lấp đầy các quầy hàng đó.

Đáp lại câu trả lời của AProgrammer

Nó không phải là "trình biên dịch ... trích xuất song song là khó".

Sắp xếp lại bộ nhớ và hướng dẫn số học của các trình biên dịch hiện đại là bằng chứng cho thấy nó không có vấn đề gì trong việc xác định các hoạt động độc lập và do đó có thể thực hiện đồng thời.

Vấn đề chính là độ trễ bộ nhớ không xác định có nghĩa là bất kỳ "ghép lệnh" nào được mã hóa cho bộ xử lý VLIW / EPIC cuối cùng sẽ bị đình trệ khi truy cập bộ nhớ.

Tối ưu hóa các hướng dẫn không bị đình trệ (chỉ đăng ký, số học) sẽ không giúp ích cho các vấn đề về hiệu suất gây ra bởi các hướng dẫn rất có khả năng bị đình trệ (truy cập bộ nhớ).

Đó là một ví dụ về việc không áp dụng quy tắc tối ưu hóa 80-20: Tối ưu hóa những thứ đã nhanh sẽ không cải thiện hiệu suất tổng thể một cách có ý nghĩa, trừ khi những thứ chậm hơn cũng đang được tối ưu hóa.

Đáp lại câu trả lời của Basile Starynkevitch

Nó không phải là "... (bất cứ điều gì) là khó", đó là EPIC không phù hợp với bất kỳ nền tảng nào phải đối phó với tính năng động cao trong độ trễ.

Ví dụ: nếu bộ xử lý có tất cả những điều sau đây:

• Không truy cập bộ nhớ trực tiếp;
  • Bất kỳ truy cập bộ nhớ (đọc hoặc ghi) phải được lên lịch bằng cách chuyển DMA;
• Mỗi hướng dẫn có độ trễ thực hiện như nhau;
• Thực hiện theo thứ tự;
• Đơn vị thực hiện rộng / véc tơ;

Sau đó, VLIW / EPIC sẽ phù hợp.

Trường hợp nào người ta tìm thấy bộ xử lý như vậy? DSP. Và đây là lúc VLIW phát triển mạnh mẽ.

Nhìn nhận lại, sự thất bại của Itanium (và tiếp tục đổ nỗ lực R & D vào một thất bại, mặc dù có bằng chứng rõ ràng) là một ví dụ về sự thất bại của tổ chức và xứng đáng được nghiên cứu sâu.

Cấp, các liên doanh khác của nhà cung cấp, chẳng hạn như siêu phân luồng, SIMD, vv, dường như rất thành công. Có thể việc đầu tư vào Itanium có thể đã có tác động phong phú đến các kỹ năng của các kỹ sư của họ, điều này có thể cho phép họ tạo ra thế hệ công nghệ thành công tiếp theo.

TL; DR: 1 / có những khía cạnh khác trong sự thất bại của Itanium so với các vấn đề của trình biên dịch và chúng rất có thể đủ để giải thích nó; 2 / một mã byte sẽ không giải quyết được các vấn đề về trình biên dịch.

Người ta thường nói rằng kiến ​​trúc bộ xử lý 64 bit Itanium của Intel đã thất bại vì tập lệnh EPIC mang tính cách mạng rất khó để viết một trình biên dịch tốt cho

Chà, họ cũng bị trễ (dự định là 98, lô hàng đầu tiên vào năm 2001) và khi cuối cùng họ giao phần cứng, tôi thậm chí không chắc chắn rằng nó đã giao những gì đã hứa cho ngày trước đó (IIRC, ít nhất họ đã bỏ một phần Mô phỏng x86 đã được lên kế hoạch ban đầu), vì vậy tôi không chắc rằng ngay cả khi các vấn đề biên dịch đã được giải quyết (và AFAIK, thì vẫn chưa), họ đã thành công. Khía cạnh trình biên dịch không phải là khía cạnh duy nhất quá tham vọng.

Có bất kỳ lý do nào khiến Intel không chỉ định ngôn ngữ "mã hóa đơn giản Itanium" và cung cấp một công cụ chuyển đổi mã byte này thành mã EPIC được tối ưu hóa, tận dụng chuyên môn của họ như những người thiết kế hệ thống ngay từ đầu?

Tôi không chắc chắn nơi bạn đặt công cụ.

Nếu nó nằm trong bộ xử lý, bạn chỉ có một kiến ​​trúc vi mô khác và không có lý do gì để không sử dụng x86 làm ISA công cộng (ít nhất là đối với Intel, tính không tương thích có chi phí cao hơn bất cứ thứ gì có thể mang lại một ISA công cộng sạch hơn).

Nếu nó ở bên ngoài, bắt đầu từ một mã byte làm cho nó thậm chí còn khó hơn bắt đầu từ một ngôn ngữ cấp cao hơn. Vấn đề với EPIC là nó chỉ có thể sử dụng song song mà trình biên dịch có thể tìm thấy và trích xuất sự song song đó là khó khăn. Biết các quy tắc ngôn ngữ cung cấp cho bạn nhiều khả năng hơn nếu bạn bị hạn chế bởi một cái gì đó đã được lên lịch. Điều tôi (thừa nhận không đáng tin cậy và từ một người theo dõi từ hồi ức đó) là điều mà HP (*) và Intel không đạt được ở mặt trước trình biên dịch là trích xuất song song mức độ ngôn ngữ, chứ không phải mức thấp sẽ xuất hiện trong một byte mã.

Có lẽ bạn đang đánh giá thấp chi phí mà bộ xử lý hiện tại đạt được hiệu năng của chúng. OOO hiệu quả hơn các khả năng khác, nhưng chắc chắn là không hiệu quả. EPIC muốn sử dụng ngân sách khu vực được sử dụng bởi việc triển khai OOO để cung cấp thêm tính toán thô, hy vọng rằng các trình biên dịch sẽ có thể sử dụng nó. Như đã viết ở trên, không chỉ chúng tôi vẫn không thể - như AFAIK, thậm chí trên lý thuyết - viết các trình biên dịch có khả năng đó, nhưng Itanium có đủ các tính năng khó thực hiện khác mà nó đã bị trễ và sức mạnh thô của nó không phải là thậm chí cạnh tranh (ngoại trừ có lẽ ở một số thị trường thích hợp với nhiều tính toán của FP) với bộ xử lý cao cấp khác khi nó ra khỏi fab.

(*) Bạn dường như cũng đánh giá thấp vai trò của HP trong EPIC.

Một vài thứ.

IPF là theo thứ tự, cho một. Điều này có nghĩa là bạn không thể dựa vào việc sắp xếp lại để cứu bạn trong trường hợp mất bộ nhớ cache hoặc sự kiện kéo dài khác. Do đó, cuối cùng bạn cần phải dựa vào các tính năng đầu cơ - cụ thể là tải đầu cơ (tải được phép không thành công - hữu ích nếu bạn không biết nếu bạn cần kết quả tải) và tải nâng cao (tải có thể chạy lại, sử dụng mã khôi phục, nếu có nguy cơ xảy ra.) Nhận được các quyền này rất khó, đặc biệt là tải nâng cao! Ngoài ra còn có các gợi ý tìm nạp trước nhánh và bộ đệm mà thực sự chỉ có thể được sử dụng thông minh bởi một lập trình viên lắp ráp hoặc sử dụng tối ưu hóa theo hướng dẫn hồ sơ, thường không phải với trình biên dịch truyền thống.

Các máy khác tại thời điểm đó - cụ thể là UltraSPARC - theo thứ tự, nhưng IPF cũng có những cân nhắc khác. Một là không gian mã hóa. Về bản chất, các hướng dẫn của Itanium không đặc biệt dày đặc - một gói 128 bit chứa ba thao tác và trường mẫu 5 bit, mô tả các hoạt động trong gói và liệu tất cả chúng có thể phát hành cùng nhau hay không. Điều này tạo ra kích thước hoạt động 42,6 bit hiệu quả - so với 32 bit cho hầu hết các hoạt động của RISC thương mại tại thời điểm đó. (Điều này có trước Thumb2, et al - RISC vẫn có nghĩa là độ cứng cố định.) Thậm chí tệ hơn, bạn không phải lúc nào cũng có đủ ILP để phù hợp với mẫu bạn đang sử dụng - vì vậy bạn phải NOP-pad để điền vào mẫu hoặc các gói. Điều này, kết hợp với mật độ thấp tương đối hiện có, có nghĩa là việc có được tỷ lệ truy cập i-cache khá là một) thực sự quan trọng,

Mặc dù tôi luôn cảm thấy rằng đối số "trình biên dịch là vấn đề duy nhất và duy nhất" đã bị thổi phồng - có những vấn đề vi kiến ​​trúc hợp pháp thực sự khiến I2 không ủng hộ mã mục đích chung - thật không thú vị khi tạo mã để so sánh cho các máy OoO hẹp hơn, đồng hồ cao hơn trong ngày. Khi bạn thực sự có thể điền đúng, thường liên quan đến PGO hoặc mã hóa bằng tay, nó đã làm rất tốt - nhưng rất nhiều thời gian, hiệu suất từ ​​trình biên dịch thực sự chỉ là không mệt mỏi. IPF đã không làm cho nó dễ dàng tạo ra mã tuyệt vời và thật không thể tha thứ khi mã không tuyệt vời.

Nhưng tại sao trình biên dịch lại là một vấn đề kỹ thuật khó khăn như vậy? Dường như với tôi rằng nếu tính song song rõ ràng trong EPIC khiến các nhà cung cấp trình biên dịch khó thực hiện ... tại sao lại đặt gánh nặng đó lên họ ngay từ đầu? Nó không giống như một giải pháp tốt, được hiểu rõ cho vấn đề này đã không tồn tại: thay vào đó hãy đặt gánh nặng đó lên Intel và trao cho người viết trình biên dịch một mục tiêu đơn giản hơn.

Những gì bạn mô tả là một chút những gì Transmeta đã cố gắng thực hiện với phần mềm biến đổi mã của họ (đã được dịch động x86 "mã byte" sang mã máy nội bộ của Transmeta).

Là tại sao đã Intel thất bại trong việc tạo ra một trình biên dịch tốt, đủ cho IA64 ... Tôi đoán là họ không có đủ chuyên môn trình biên dịch trong nhà (thậm chí nếu tất nhiên họ đã có một số chuyên gia biên dịch rất tốt bên trong, nhưng có lẽ không đủ để làm cho một khối quan trọng). Tôi đoán rằng quản lý của họ đã đánh giá thấp những nỗ lực cần thiết để tạo ra một trình biên dịch.

AFAIK, Intel EPIC đã thất bại vì quá trình biên dịch cho EPIC thực sự khó khăn và cũng vì khi công nghệ trình biên dịch chậm và dần cải thiện, các đối thủ khác cũng có thể cải thiện trình biên dịch của họ (ví dụ như AMD64), chia sẻ một số bí quyết về trình biên dịch.

BTW, tôi ước rằng AMD64 sẽ có thêm một bộ hướng dẫn RISCy. Nó có thể là một số POWERPC64 (nhưng có lẽ không phải vì vấn đề bằng sáng chế, vì nhu cầu của Microsoft tại thời điểm đó, v.v ...). Kiến trúc tập lệnh x86-64 thực sự không phải là kiến ​​trúc "rất tốt" cho trình soạn thảo trình biên dịch (nhưng bằng cách nào đó nó "đủ tốt").

Ngoài ra, kiến ​​trúc IA64 đã tạo ra một số hạn chế mạnh, ví dụ 3 hướng dẫn / từ vẫn tốt miễn là bộ xử lý có 3 đơn vị chức năng để xử lý chúng, nhưng một khi Intel chuyển sang chip IA64 mới hơn, họ đã thêm các đơn vị chức năng và hướng dẫn- song song cấp độ một lần nữa khó đạt được.

Có lẽ RISC-V (là một mã nguồn mở) sẽ dần thành công đủ để khiến nó cạnh tranh với các bộ xử lý khác.

Như Robert Munn đã chỉ ra - chính sự thiếu khả năng tương thích ngược đã giết chết Itanium (và nhiều công nghệ "mới" khác).

Trong khi viết một trình biên dịch mới có thể khó, bạn chỉ cần một vài trong số chúng. Trình biên dịch AC tạo mã được tối ưu hóa là bắt buộc - nếu không, bạn sẽ không có Hệ điều hành có thể sử dụng được. Bạn cần một trình biên dịch C ++, Java và được cho rằng cơ sở người dùng chính sẽ là Windows một số loại Visual Basic. Vì vậy, đây không thực sự là một vấn đề. Có một hệ điều hành tốt (NT) và một trình biên dịch C tốt.

Điều có vẻ như là một nỗ lực tầm thường đối với một công ty cung cấp một sản phẩm phần mềm - biên dịch lại và kiểm tra lại cơ sở mã C của bạn (và tại thời điểm đó hầu hết sẽ được viết bằng C!) Không đơn giản; chuyển đổi một tập hợp lớn các chương trình C giả định số nguyên 32 bit và giả định địa chỉ 32 bit thành kiến ​​trúc 64 bit nguyên gốc đầy cạm bẫy. Nếu IA64 trở thành một con chip thống trị (hoặc thậm chí là một con chip phổ biến!), Hầu hết các công ty phần mềm sẽ cắn viên đạn và nỗ lực.

Vì vậy, chip nhanh với hệ điều hành hợp lý nhưng có sẵn một bộ phần mềm rất hạn chế, do đó không có nhiều người mua nó, do đó không có nhiều công ty phần mềm cung cấp sản phẩm cho nó.

Điều đã giết chết Itanium là sự chậm trễ vận chuyển đã mở ra cơ hội cho AMD64 bước vào trước khi các nhà cung cấp phần mềm cam kết chuyển sang IA64 cho các ứng dụng 64 bit.

Để tối ưu hóa cho trình biên dịch là một ý tưởng tốt. Rất nhiều thứ có thể được thực hiện tĩnh mà nếu không thì không hiệu quả trong phần cứng. Các trình biên dịch trở nên khá tốt về nó, đặc biệt là khi sử dụng hồ sơ PGO (Tôi đã làm việc tại HP và trình biên dịch của HP có xu hướng vượt trội hơn so với Intel). PGO là một khó bán, tuy nhiên, đó là một quá trình khó khăn cho mã sản xuất.

IPF có nghĩa là tương thích ngược, nhưng một khi AMD64 ra mắt, nó đã bị mất và trận chiến đã bị mất và tôi tin rằng phần cứng X86 trong CPU đã bị tước để nhắm mục tiêu lại là CPU máy chủ. Itanium là một kiến ​​trúc không tệ, 3 hướng dẫn cho mỗi từ không phải là vấn đề. Vấn đề là việc triển khai siêu phân luồng bằng cách hoán đổi các ngăn xếp trong bộ nhớ IO quá chậm (để trống và tải lại đường ống) cho đến khi Montecito, v.v ... khiến nó không thể cạnh tranh với các CPU PowerPC không theo thứ tự. Các trình biên dịch đã phải vá các lỗi phát hiện muộn của việc triển khai CPU và một số cạnh hiệu năng đã bị mất để khó dự đoán lỗi.

Kiến trúc cho phép Itanium tương đối đơn giản trong khi cung cấp các công cụ cho trình biên dịch để tăng hiệu suất từ ​​nó. Nếu nền tảng đã hoạt động, các CPU sẽ trở nên phức tạp hơn và cuối cùng trở thành luồng, không theo thứ tự, v.v. như x86. Tuy nhiên, các bóng bán dẫn đầu tiên tập trung vào các sơ đồ hiệu suất khác kể từ khi trình biên dịch xử lý rất nhiều thứ cứng.

Nền tảng IPF đặt cược vào trình biên dịch và các công cụ, và đó là kiến ​​trúc đầu tiên để lộ một thiết kế Đơn vị giám sát hiệu suất (PMU) cực kỳ hoàn chỉnh và mạnh mẽ, sau đó được chuyển lại cho Intel x86. Vì vậy, các nhà phát triển công cụ mạnh mẽ vẫn không sử dụng hết khả năng của nó để mã hồ sơ.

Nếu bạn nhìn vào thành công của ISA, đó thường không phải là khía cạnh kỹ thuật để gieo xúc xắc. Đó là vị trí của nó trong thời gian và lực lượng thị trường. Hãy nhìn vào SGI Mips, DEC Alpha ... Itanium chỉ được hỗ trợ bởi những người lỏng lẻo, máy chủ SGI & HP, các công ty quản lý chồng chất lên những sai lầm kinh doanh chiến lược. Microsoft chưa bao giờ tham gia đầy đủ và chấp nhận AMD64 để không tham gia vào Intel với tư cách là một người chơi và Intel đã không chơi đúng với AMD để cho họ sống trong hệ sinh thái, vì họ có ý định bóp nghẹt AMD.

Nếu bạn nhìn vào vị trí của chúng ta ngày nay, phần cứng phức tạp của X86 đã dẫn nó đến một ngõ cụt tiến hóa cho đến nay. Chúng tôi bị kẹt ở tốc độ 3 + GHz và không sử dụng hết lõi. Thiết kế đơn giản hơn của Itanium sẽ đẩy nhiều thứ hơn vào trình biên dịch (phòng cho sự tăng trưởng), cho phép xây dựng các đường ống mỏng hơn, nhanh hơn. Ở cùng một thế hệ và công nghệ fab, nó sẽ chạy nhanh hơn và giới hạn tất cả giống nhau nhưng cao hơn một chút, có thể các cánh cửa khác sẽ mở ra để đẩy luật của Moore.

Vâng ít nhất ở trên là niềm tin của tôi :)

Bộ nhớ đang trở nên mơ hồ ... Itanium có một số ý tưởng tuyệt vời cần được hỗ trợ trình biên dịch tuyệt vời. Vấn đề là nó không phải là một tính năng, nó là rất nhiều. Mỗi người không phải là một vấn đề lớn, tất cả cùng nhau.

Ví dụ, có một tính năng lặp trong đó một lần lặp của vòng lặp sẽ hoạt động trên các thanh ghi từ các lần lặp khác nhau. x86 xử lý vấn đề tương tự thông qua khả năng không theo thứ tự lớn.

Vào thời điểm đó, Java và JVM là thời trang. Điều IBM nói là với PowerPC, bạn có thể biên dịch mã byte nhanh chóng và CPU sẽ làm cho nó nhanh. Không phải trên Itanium.