“Kết quả thực nghiệm chỉ để xuất bản, động cơ thực sự của tác phẩm là mang tính thẩm mỹ.” Cuộc phỏng vấn tuyệt vời với Michael Scott

“Kết quả thực nghiệm chỉ để xuất bản, động cơ thực sự của tác phẩm là mang tính thẩm mỹ.” Cuộc phỏng vấn tuyệt vời với Michael Scott Micheal Scott - trong 34 năm với tư cách là giáo sư Khoa học Máy tính tại Đại học Rochester, và tại Đại học Wisconsin–Madison quê hương ông, ông đã giữ chức vụ trưởng khoa trong 5 năm. Ông nghiên cứu và giảng dạy sinh viên về lập trình song song và phân tán cũng như thiết kế ngôn ngữ.

Thế giới biết đến Michael từ sách giáo khoa "Ngôn ngữ lập trình thực dụng", những gì về công việc "Thuật toán đồng bộ hóa có thể mở rộng trên bộ đa xử lý bộ nhớ dùng chung" đã nhận được Giải thưởng Dijkstra là một trong những giải thưởng nổi tiếng nhất trong lĩnh vực điện toán phân tán. Bạn cũng có thể biết anh ấy là tác giả của chính thuật toán đó Michael-Scott.

Cùng với Doug Lee, anh đã phát triển các thuật toán không chặn và hàng đợi đồng bộ hỗ trợ các thư viện Java. Thực hiện "cấu trúc dữ liệu kép" trong JavaSE 6 đã cải thiện hiệu suất lên 10 lần ThreadPoolExecutor.

Содержание:

  • Sự nghiệp ban đầu, Đại học Rochester. Dự án Charlotte, ngôn ngữ Lynx;
  • Giao diện mạch lạc có thể mở rộng của IEEE, khóa MCS;
  • Sống sót trong một thế giới luôn thay đổi;
  • Học sinh ngày càng ngu ngốc? Xu hướng toàn cầu hóa, quốc tế hóa;
  • Làm việc hiệu quả với sinh viên;
  • Làm thế nào để theo kịp việc chuẩn bị các khóa học và sách mới;
  • Liên kết giữa doanh nghiệp và học viện;
  • Thực tế triển khai ý tưởng. MCS, MS, CLH, JSR 166, làm việc với Doug Lee và hơn thế nữa;
  • Bộ nhớ giao dịch;
  • Những kiến ​​trúc mới. Chiến thắng của ký ức giao dịch đã gần kề;
  • Bộ nhớ ổn định, Optane DIMM, thiết bị cực nhanh;
  • Xu hướng lớn tiếp theo. Cấu trúc dữ liệu kép. Hydra.

Cuộc phỏng vấn được thực hiện bởi:

Vitaly Aksenov — hiện là nghiên cứu sinh sau tiến sĩ tại IST Austria và là thành viên Khoa Công nghệ Máy tính tại Đại học ITMO. Tiến hành nghiên cứu trong lĩnh vực lý thuyết và thực hành cấu trúc dữ liệu cạnh tranh. Trước khi làm việc tại IST, ông nhận bằng Tiến sĩ tại Đại học Paris Diderot và Đại học ITMO dưới sự hướng dẫn của Giáo sư Peter Kuznetsov.

Alexey Fedorov - Nhà sản xuất tại JUG Ru Group, một công ty của Nga chuyên tổ chức hội nghị cho các nhà phát triển. Alexey đã tham gia chuẩn bị cho hơn 50 hội nghị và lý lịch của anh ấy bao gồm mọi thứ từ vị trí kỹ sư phát triển tại Oracle (JCK, Nhóm nền tảng Java) đến vị trí nhà phát triển tại Odnoklassniki.

Vladimir Sitnikov - Kỹ sư tại Netcracker. Mười năm làm việc về hiệu suất và khả năng mở rộng của NetCracker OS, phần mềm được các nhà khai thác viễn thông sử dụng để tự động hóa các quy trình quản lý mạng và thiết bị mạng. Quan tâm đến các vấn đề về hiệu suất của Cơ sở dữ liệu Java và Oracle. Tác giả của hơn chục cải tiến hiệu suất trong trình điều khiển JDBC PostgreSQL chính thức.

Sự nghiệp ban đầu, Đại học Rochester. Dự án Charlotte, ngôn ngữ Lynx.

Alexey: Để bắt đầu, tôi muốn nói với bạn rằng ở Nga tất cả chúng tôi đều thực sự yêu thích Khoa học Máy tính, Khoa học Dữ liệu và thuật toán. Thật là tục tĩu. Chúng tôi đã đọc mọi thứ sách của Cormen, Leiserson và Rivest. Vì vậy, hội nghị, trường học và cuộc phỏng vấn sắp tới sẽ rất phổ biến. Chúng tôi đã nhận được nhiều câu hỏi cho cuộc phỏng vấn này từ các sinh viên, lập trình viên và thành viên cộng đồng, vì vậy chúng tôi rất biết ơn cơ hội này. Khoa học Máy tính có nhận được sự yêu thích tương tự ở Mỹ không?

Michael: Lĩnh vực của chúng tôi rất đa dạng, có rất nhiều hướng và nó ảnh hưởng đến xã hội theo nhiều cách khác nhau nên tôi khó có thể đưa ra câu trả lời dứt khoát cho bạn. Nhưng sự thật là nó đã mang lại những thay đổi to lớn trong kinh doanh, công nghiệp, nghệ thuật và xã hội nói chung trong hơn 30 năm qua.

Виталий: Hãy bắt đầu với một cái gì đó xa vời. Ở nhiều trường đại học có một cái gì đó giống như chuyên môn hóa trong một lĩnh vực cụ thể. Đối với Đại học Carnegie Mellon đây là tính toán song song, đối với MIT đó là mật mã, robot và đa luồng. Có chuyên ngành như vậy ở Đại học Rochester không?

Michael: Thành thật mà nói, tôi có thể nói rằng CMU và MIT chuyên về mọi lĩnh vực. Bộ phận của chúng tôi luôn chú trọng nhất đến trí tuệ nhân tạo. Một nửa số người làm việc cho chúng tôi tham gia vào lĩnh vực AI hoặc tương tác giữa con người với máy tính - tỷ lệ này cao hơn so với các bộ phận khác và luôn như vậy. Nhưng khi còn học đại học, tôi không có khóa học nào về AI và cũng chưa từng làm việc trong lĩnh vực này. Vì vậy bộ phận của tôi chuyên về một vấn đề mà tôi không liên quan gì cả. Điều an ủi là vấn đề quan trọng thứ hai đối với bộ phận của chúng tôi là lập trình song song và đa luồng, đó là chuyên môn của tôi.

Виталий: Bạn bắt đầu làm việc trong lĩnh vực Khoa học Máy tính khi lĩnh vực lập trình đa luồng mới nổi. Danh sách các ấn phẩm của bạn cho thấy các tác phẩm đầu tiên của bạn đề cập đến khá nhiều vấn đề: quản lý bộ nhớ trong hệ thống đa luồng, hệ thống tệp phân tán, hệ điều hành. Tại sao lại linh hoạt như vậy? Bạn đã cố gắng tìm vị trí của mình trong cộng đồng nghiên cứu chưa?

Michael: Khi còn là sinh viên, tôi đã tham gia Dự án Charlotte tại Đại học Wisconsin, nơi một trong những hệ điều hành phân tán đầu tiên được phát triển. Ở đó tôi đã làm việc cùng với Rafael Finkel (Raphael Finkel) và Marvin Solomon (Marvin Solomon). Luận án của tôi tập trung vào việc phát triển ngôn ngữ phần mềm hệ thống cho các hệ thống phân tán - bây giờ mọi người đã quên nó và cảm ơn Chúa. Tôi đã tạo ngôn ngữ lập trình Lynx nhằm giúp việc tạo máy chủ cho hệ điều hành phân tán được liên kết lỏng lẻo trở nên dễ dàng hơn. Vì lúc đó tôi chủ yếu tham gia vào hệ điều hành nên tôi cho rằng sự nghiệp của mình sẽ chủ yếu gắn liền với chúng. Nhưng Rochester là một trường đại học rất nhỏ, và vì điều này, các nhóm khác nhau ở đó tương tác rất chặt chẽ với nhau. Không có hàng tá người làm hệ điều hành khác ở đó để tôi nói chuyện, vì vậy tất cả các mối liên hệ của tôi đều là với những người làm việc ở các lĩnh vực hoàn toàn khác nhau. Tôi thực sự thích nó, trở thành một người toàn diện là một lợi thế lớn đối với tôi. Nếu chúng ta nói cụ thể về cấu trúc dữ liệu đa luồng và thuật toán đồng bộ hóa, thì tôi bắt đầu làm việc với chúng hoàn toàn một cách tình cờ.

Giao diện mạch lạc có thể mở rộng của IEEE, khóa MCS.

Виталий: Bạn có thể cho chúng tôi biết thêm một chút về điều này?

Michael: Đây là một câu chuyện vui mà tôi không bao giờ chán kể cho mọi người nghe. Chuyện xảy ra tại một hội nghị ASPLOS ở Boston - đó là vào cuối những năm 80 hoặc đầu những năm 90. John Mellor-Crummey (John Mellor-Crummey), tốt nghiệp khoa của chúng tôi. Tôi biết anh ấy, nhưng trước đây chúng tôi chưa từng tiến hành nghiên cứu chung. Mary Vernon (Mary Vernon) từ Wisconsin đã có buổi nói chuyện về hệ thống đa bộ xử lý mà họ đang phát triển ở Wisconsin: Wisconsin Multicube. Multicube này có cơ chế đồng bộ hóa ở cấp độ phần cứng được gọi là Q trên Sync Bit, và sau đó nó được đổi tên thành Q trên Lock Bit vì nó nghe giống phô mai Colby, một cách chơi chữ. Nếu quan tâm đến cơ chế đa luồng, có thể bạn biết rằng Colby cuối cùng đã trở thành công cụ đồng bộ hóa cho tiêu chuẩn Giao diện mạch lạc có thể mở rộng của IEEE. Đây là một cơ chế khóa tạo ra các con trỏ từ bộ đệm này sang bộ đệm khác ở cấp độ phần cứng để mỗi người giữ khóa biết đến lượt của ai. Khi John và tôi nghe về điều này, chúng tôi nhìn nhau và nói: tại sao lại làm điều này ở cấp độ phần cứng? Không thể đạt được điều tương tự bằng cách sử dụng so sánh và trao đổi? Chúng tôi lấy một trong những cuốn vở nằm trong lớp và viết nguệch ngoạc lên đó Chặn MCS, trong khi Mary tiếp tục báo cáo của mình. Sau đó, chúng tôi triển khai, thử nghiệm, ý tưởng thành công và chúng tôi xuất bản bài báo. Vào thời điểm đó, đối với tôi, chủ đề này dường như chỉ là một trò giải trí vui vẻ, sau đó tôi định quay lại với hệ điều hành. Nhưng sau đó, một vấn đề khác cũng nảy sinh, và cuối cùng đồng bộ hóa, đa luồng và cấu trúc dữ liệu đã trở thành chuyên môn của tôi. Như bạn có thể thấy, tất cả điều này xảy ra một cách tình cờ.

Виталий: Tôi quen với việc chặn MCS đã lâu nhưng đến bây giờ tôi mới biết đó là tác phẩm của bạn và cũng không hiểu rằng đó là từ viết tắt của họ của bạn.

Làm thế nào để tồn tại trong một thế giới luôn thay đổi?

Alexey: Tôi có một câu hỏi về một chủ đề liên quan. 30 hoặc 40 năm trước có nhiều tự do hơn trong các chuyên ngành khác nhau. Nếu bạn muốn bắt đầu sự nghiệp trong lĩnh vực đa luồng hoặc hệ thống phân tán, thì không sao, nếu bạn muốn tham gia vào hệ điều hành thì không vấn đề gì. Trong mỗi lĩnh vực đều có nhiều câu hỏi mở và ít chuyên gia. Các chuyên ngành hẹp hiện đã xuất hiện: không chỉ có các chuyên gia về hệ điều hành nói chung mà còn có các chuyên gia về các hệ thống riêng lẻ. Điều này cũng tương tự với các hệ thống đa luồng và phân tán. Nhưng vấn đề là cuộc sống của chúng ta không phải là vô tận; mỗi người chỉ có thể cống hiến vài chục năm cho việc nghiên cứu. Làm thế nào để sống sót trong thế giới mới này?

Michael: Chúng tôi không đặc biệt về mặt này; điều tương tự đã từng xảy ra ở các khu vực khác. Tôi thật may mắn khi bắt đầu làm việc trong lĩnh vực Khoa học Máy tính khi lĩnh vực này còn ở độ tuổi “tuổi thiếu niên”. Một số nền móng đã được đặt sẵn nhưng mọi thứ vẫn còn rất non nớt. Cơ hội này không đến thường xuyên. Kỹ thuật điện đã có từ rất lâu, vật lý thậm chí còn lâu hơn, toán học gần như đã có từ xa xưa. Nhưng điều này không có nghĩa là không còn ai có những khám phá thú vị về toán học nữa. Vẫn còn nhiều vấn đề bỏ ngỏ nhưng đồng thời cũng cần phải học hỏi thêm. Bạn có quyền lưu ý rằng hiện nay có nhiều chuyên môn hơn trước đây, nhưng điều này chỉ có nghĩa là chúng ta đang ở trong tình trạng tương tự như hầu hết các lĩnh vực hoạt động khác của con người.

Alexey: Tôi quan tâm đến khía cạnh thực tế hơn của vấn đề ở đây. Tôi có nền tảng về toán học và trong quá trình học, tôi thường tham dự các hội nghị và làm việc về nhiều chủ đề khoa học khác nhau. Tôi phát hiện ra rằng không ai trong số khán giả hiểu báo cáo của tôi, và tương tự như vậy, báo cáo của người khác chỉ có họ mới hiểu được. Điều này không xảy ra ở các chủ đề cấp cao, nhưng ngay khi bạn bắt đầu tìm hiểu sâu về điều gì đó, khán giả sẽ không thể theo kịp bạn được nữa. Làm thế nào để bạn đối phó với điều này?

Michael: Không phải lúc nào cũng thành công. Gần đây tôi đã chuẩn bị một báo cáo trong đó tôi đi quá sâu vào các chi tiết kỹ thuật. Khi cuộc nói chuyện diễn ra, rõ ràng là hầu hết khán giả không hiểu tôi nên tôi phải nhanh chóng thích nghi với tình huống đó. Không thể thay đổi các slide, vì vậy nó diễn ra không được tốt lắm - vì vậy, nói chung, tôi cố gắng không sử dụng các slide. Nhìn chung, lời khuyên của tôi là hãy xem xét khán giả của bạn. Bạn cần biết bạn đang nói chuyện với ai, trình độ kiến ​​thức của họ như thế nào và họ cần nghe những gì để đánh giá cao công việc của bạn.

Виталий: Bạn có thể cho chúng tôi gợi ý về nội dung bài giảng này không?

Michael: Thành thật mà nói, tôi không muốn mở rộng chủ đề này để giấu tên những người được đề cập. Vấn đề là chúng ta thường đi quá sâu vào sự phức tạp của vấn đề mà chúng ta đang giải quyết, do đó chúng ta khó có thể giải thích ngay từ đầu bài nói tại sao vấn đề đó lại thú vị và quan trọng cũng như nó liên quan như thế nào đến các vấn đề mà chúng ta đang giải quyết. khán giả đã biết rồi. Theo quan sát của tôi, học sinh gặp khó khăn nhất khi học kỹ năng này. Và đây cũng chính là điểm yếu trong báo cáo gần đây của tôi. Ngay từ đầu, một báo cáo có cấu trúc phù hợp phải tìm cách liên hệ với khán giả, giải thích cho họ chính xác vấn đề là gì và vấn đề đó liên quan như thế nào đến các chủ đề đã được biết đến. Phần giới thiệu này mang tính kỹ thuật như thế nào tùy thuộc vào khán giả. Nếu nó hoàn toàn hỗn tạp, thì báo cáo có thể có nhiều giai đoạn. Phần giới thiệu phải có sẵn cho tất cả mọi người và đến cuối phần này có thể không theo kịp bạn, nhưng những người tương đối quen thuộc với lĩnh vực của bạn sẽ có thể hiểu được phần đó.

Học sinh ngày càng ngu ngốc? Xu hướng toàn cầu hóa, quốc tế hóa.

Alexey: Bạn đã quan sát học sinh trong nhiều thập kỷ. Học sinh ngày càng ngu hơn hay thông minh hơn từ thập kỷ này sang thập kỷ khác hoặc từ năm này sang năm khác? Ở Nga, các giáo sư liên tục phàn nàn rằng học sinh ngày càng ngu hơn mỗi năm và thực sự không rõ phải làm gì với điều đó.

Michael: Bạn thực sự có thể nghe thấy rất nhiều điều tiêu cực từ những người già chúng tôi. Trong tiềm thức, chúng ta có xu hướng mong đợi học sinh tiếp thu tất cả 30 năm kinh nghiệm mà chúng ta đã có. Nếu tôi hiểu biết sâu sắc hơn năm 1985 thì tại sao học sinh lại không có? Có lẽ vì họ đã 20 tuổi nên bạn nghĩ sao? Tôi nghĩ những thay đổi quan trọng nhất trong những thập kỷ gần đây là về thành phần nhân khẩu học: hiện nay chúng ta có nhiều sinh viên quốc tế hơn, ngoại trừ người Canada. Trước đây có rất nhiều người Canada vì chúng tôi rất gần biên giới Canada và sinh viên từ đó có thể về nhà vào cuối tuần. Nhưng hiện nay có nhiều trường đại học tốt ở Canada và người Canada thích học ở đây hơn; trong số đó có rất ít người đến Mỹ.

Alexey: Bạn nghĩ đây là xu hướng địa phương hay toàn cầu?

Michael: Tôi không nhớ chính xác là ai, nhưng có người đã nói rằng thế giới phẳng. Lĩnh vực của chúng tôi đã trở nên quốc tế hơn nhiều. Hội nghị ACM Trước đây, chúng được tổ chức độc quyền tại Hoa Kỳ, sau đó họ quyết định tổ chức 4 năm một lần ở các quốc gia khác, và bây giờ chúng được tổ chức trên toàn thế giới. Những thay đổi này thậm chí còn ảnh hưởng nhiều hơn IEEE, vì nó luôn là một tổ chức mang tính quốc tế hơn ACM. Và có những người chủ trì chương trình từ Trung Quốc, Ấn Độ, Nga, Đức và nhiều nước khác, bởi vì hiện nay có rất nhiều điều đang diễn ra ở khắp mọi nơi.

Alexey: Nhưng có lẽ có một số khía cạnh tiêu cực của quá trình quốc tế hóa như vậy?

Michael: Tôi muốn nói rằng tất cả các khía cạnh tiêu cực không liên quan đến công nghệ mà liên quan đến chính trị. Ngày xửa ngày xưa, vấn đề chính là việc Mỹ đã đánh cắp những người thông minh và tài năng nhất từ ​​​​các nước trên thế giới. Và bây giờ vấn đề chính là các trò chơi chính trị giữa các quốc gia khác nhau xung quanh vấn đề thị thực và nhập cư.

Alexey: Đó là, những rào cản và những thứ tương tự. Rõ ràng.

Vladimir: Cá nhân tôi quan tâm đến cách bạn thực hiện khi dạy một môn học mới cho học sinh. Có nhiều lựa chọn khác nhau: trước hết bạn có thể thử truyền cảm hứng cho họ thử điều gì đó mới hoặc bạn có thể chú ý hơn đến các chi tiết về cách thức hoạt động của một công nghệ nhất định. Bạn thích cái nào hơn?

Làm việc hiệu quả với sinh viên

Alexey: Và làm thế nào để tìm được sự cân bằng chết tiệt giữa thứ nhất và thứ hai?

Michael: Vấn đề là các lớp học không phải lúc nào cũng diễn ra như tôi mong muốn. Tôi thường cho học sinh đọc trước tài liệu để các em đi sâu tìm hiểu, hiểu hết khả năng của mình và đặt câu hỏi về những phần mà các em chưa hiểu. Sau đó, trong lớp, bạn có thể tập trung vào những khoảnh khắc khó khăn nhất và cùng nhau khám phá chúng. Đây là cách tôi thích dạy các lớp học nhất. Nhưng với gánh nặng hiện nay đè nặng lên học sinh, không phải lúc nào tôi cũng có thể đảm bảo rằng các em đã chuẩn bị trước. Kết quả là, bạn phải dành nhiều thời gian hơn cho việc kể lại tài liệu nói chung hơn mức bạn muốn. Mặc dù vậy, tôi cố gắng giữ cho lớp học của chúng tôi có tính tương tác. Nếu không, việc quay video để học sinh có thể xem ở nhà sẽ dễ dàng hơn. Mục đích của các lớp học trực tiếp là sự tương tác giữa con người với nhau. Trong lớp, tôi thích sử dụng phấn và bảng đen hơn là slide, ngoại trừ một số trường hợp khi sơ đồ quá phức tạp để mô tả trên bảng. Nhờ vậy, tôi không phải tuân theo một giáo án cứng nhắc nào cả. Vì không có thứ tự nghiêm ngặt nào về việc tôi cung cấp tài liệu nên điều này cho phép tôi điều chỉnh nó cho phù hợp với khán giả tùy thuộc vào câu hỏi tôi nhận được. Nói chung, tôi cố gắng làm cho các lớp học có tính tương tác cao nhất có thể để tài liệu tôi trình bày phụ thuộc vào các câu hỏi được đặt ra cho tôi.

Vladimir: Thật tuyệt vời. Theo kinh nghiệm của tôi, rất khó để người nghe đặt câu hỏi. Dù bạn có hỏi trước để hỏi bất kỳ câu hỏi nào thì dù ngu hay thông minh đến đâu họ vẫn im lặng. Làm thế nào để bạn đối phó với điều này?

Michael: Bạn sẽ cười, nhưng nếu bạn đứng im lặng đủ lâu, sớm muộn gì mọi người cũng sẽ khó chịu và sẽ có người đặt câu hỏi. Hoặc bạn có thể hỏi một câu hỏi kỹ thuật đơn giản với câu trả lời có hoặc không để xác định xem mọi người có hiểu những gì vừa nói hay không. Ví dụ: có cuộc đua dữ liệu trong ví dụ trên không? Ai nghĩ vậy? Ai nghĩ là không? Ai chẳng hiểu gì cả, vì tổng cộng chỉ có một nửa số cánh tay giơ lên?

Виталий: Và nếu bạn trả lời sai, bạn sẽ bị đuổi khỏi lớp :)

Michael: Nếu bạn chưa trả lời bất cứ điều gì, thì bạn nên đặt một câu hỏi. Tôi cần hiểu chính xác học sinh cần biết gì để trả lời câu hỏi tôi vừa hỏi. Tôi cần họ giúp tôi giúp họ. Tôi sẵn sàng thích nghi với họ để họ hiểu được vấn đề. Nhưng nếu tôi không biết điều gì đang diễn ra trong đầu họ thì tôi không thể làm được. Và nếu bạn không để học sinh yên tĩnh trong một thời gian đủ dài, đôi khi cuối cùng họ sẽ hỏi những câu hỏi phù hợp, tức là những câu hỏi cho phép tôi biết chính xác điều gì đang diễn ra trong đầu học sinh. 

Alexey: Những câu hỏi này đôi khi có dẫn đến những ý tưởng mà trước đây bạn chưa từng nghĩ đến không? Họ có bất ngờ không? Họ có cho phép bạn nhìn vấn đề dưới một góc nhìn mới không?

Michael: Có những câu hỏi mở ra một cách trình bày tài liệu mới. Thường có những câu hỏi dẫn đến những vấn đề thú vị mà tôi không định nói đến. Học sinh thường nói với tôi rằng tôi có xu hướng lạc đề khi điều này xảy ra. Và theo họ, đây thường là phần thú vị nhất của bài học. Rất hiếm khi, chỉ một vài lần, sinh viên đặt ra những câu hỏi khơi gợi một hướng nghiên cứu mới và phát triển thành một bài báo. Điều này xảy ra thường xuyên hơn trong các cuộc trò chuyện với học sinh hơn là trong giờ học, nhưng đôi khi nó cũng xảy ra trong giờ học. 

Alexey: Vậy các sinh viên đã hỏi bạn những câu hỏi trên cơ sở đó mới có thể xuất bản một bài báo?

Michael: Đúng. 

Виталий: Bạn có thường xuyên nói chuyện như vậy với học sinh không? Khi nào họ muốn học nhiều hơn những gì được dạy trong bài học?

Michael: Với các sinh viên tốt nghiệp của tôi - mọi lúc. Tôi có khoảng 5 hoặc 6 người trong số họ và chúng tôi luôn thảo luận điều gì đó với họ. Và những cuộc trò chuyện kiểu này với những sinh viên chỉ tham gia lớp học của tôi không phổ biến lắm. Mặc dù tôi ước điều này xảy ra thường xuyên hơn. Tôi nghi ngờ rằng họ chỉ sợ đến khoa trong giờ hành chính. Mỗi học kỳ, một số sinh viên cố gắng vượt qua rào cản tâm lý này và việc nói chuyện với họ sau giờ học luôn rất thú vị. Đúng vậy, nếu tất cả học sinh đều dũng cảm như vậy thì đơn giản là tôi sẽ không có đủ thời gian. Vì vậy, có lẽ mọi thứ đang hoạt động như bình thường. 

Виталий: Làm thế nào bạn có thể sắp xếp thời gian để giao tiếp với sinh viên? Theo những gì tôi biết, ở Mỹ, giáo viên có rất nhiều công việc - xin trợ cấp và những thứ tương tự. 

Michael: Thành thật mà nói, làm việc với sinh viên là khía cạnh công việc mà tôi thích nhất. Vì vậy, tôi có đủ động lực cho việc này. Phần lớn thời gian tôi ở trong văn phòng là dành cho các cuộc họp đủ loại. Bây giờ đang là mùa hè nên lịch trình của tôi cũng bớt bận rộn hơn nhưng trong năm học, ngày nào từ 9 giờ đến 17 giờ tôi đều gói ghém mọi thứ. Công việc nghiên cứu, đánh giá, tài trợ - đối với tất cả những điều này chỉ có buổi tối và cuối tuần. 

Làm thế nào để theo kịp việc chuẩn bị các khóa học và sách mới.

Alexey: Hiện tại bạn có tiếp tục giảng dạy bất kỳ khóa học nào mà bạn đã giảng dạy trong một thời gian dài không? Một cái gì đó giống như phần giới thiệu về Khoa học Máy tính.

Michael: Điều đầu tiên bạn nghĩ đến ở đây là một khóa học về ngôn ngữ lập trình. 

Alexey: Phiên bản ngày nay của khóa học này khác với phiên bản 10, 20, 30 năm trước như thế nào? Có lẽ điều thú vị hơn ở đây không phải là chi tiết của một khóa học cụ thể mà là xu hướng chung.

Michael: Khóa học về ngôn ngữ lập trình của tôi hơi khác thường vào thời điểm tôi tạo nó. Tôi bắt đầu đọc nó vào cuối những năm 1980, thay thế cho đồng nghiệp của tôi, Doug Baldwin (Doug Baldwin). Chủ đề của khóa học chỉ liên quan trực tiếp đến chuyên ngành của tôi nhưng khi anh ấy rời đi, tôi là ứng viên sáng giá nhất để giảng dạy khóa học. Tôi không thích bất kỳ cuốn sách giáo khoa nào tồn tại vào thời điểm đó, vì vậy cuối cùng tôi đã tự mình viết sách giáo khoa cho khóa học này. (Ghi chú của biên tập viên: chúng ta đang nói về cuốn sách "Ngôn ngữ lập trình thực dụng") Nó hiện được sử dụng ở hơn 200 trường đại học trên khắp thế giới. Cách tiếp cận của tôi khác thường ở chỗ nó cố tình kết hợp các vấn đề về thiết kế và triển khai ngôn ngữ, đồng thời rất chú ý đến sự tương tác giữa các khía cạnh này trong tất cả các lĩnh vực có thể có. Cách tiếp cận cơ bản vẫn không thay đổi, cũng như nhiều khái niệm cơ bản: trừu tượng, không gian tên, tính mô đun, kiểu. Nhưng tập hợp ngôn ngữ mà các khái niệm này được thể hiện đã thay đổi hoàn toàn. Khi khóa học lần đầu tiên được tạo ra, có rất nhiều ví dụ về Pascal, nhưng ngày nay nhiều học viên của tôi thậm chí còn chưa từng nghe đến ngôn ngữ này. Nhưng họ biết Swift, Go, Rust nên tôi phải nói về những ngôn ngữ đang được sử dụng hiện nay. Ngoài ra, sinh viên hiện đã thành thạo các ngôn ngữ viết kịch bản, nhưng khi tôi bắt đầu dạy khóa học này, tất cả đều là về các ngôn ngữ biên dịch. Bây giờ chúng ta cần rất nhiều tài liệu về Python, Ruby và thậm chí cả Perl, bởi vì đây là loại mã được viết ngày nay và có rất nhiều điều thú vị xảy ra trong các ngôn ngữ này, kể cả trong lĩnh vực thiết kế ngôn ngữ. 

Виталий: Vậy thì câu hỏi tiếp theo của tôi sẽ liên quan đến câu hỏi trước. Làm thế nào để theo kịp trong lĩnh vực này? Tôi nghi ngờ rằng việc cập nhật một khóa học như thế này đòi hỏi rất nhiều công sức - bạn cần hiểu các ngôn ngữ mới, hiểu các ý chính. Làm thế nào để bạn làm điều này?

Michael: Tôi không thể tự hào rằng mình luôn thành công 100%. Nhưng hầu hết thời gian tôi chỉ làm những gì người khác làm - đọc Internet. Nếu tôi muốn hiểu Rust, tôi dùng Google, truy cập trang Mozilla và đọc hướng dẫn được đăng ở đó. Đây là một phần của những điều xảy ra trong phát triển thương mại. Nếu chúng ta nói về khoa học thì bạn cần theo dõi các báo cáo tại các hội nghị chính. 

Cầu nối giữa doanh nghiệp và học viện

Виталий: Hãy nói về mối liên hệ giữa kinh doanh và nghiên cứu khoa học. Trong danh sách tác phẩm của bạn, tôi tìm thấy một số bài viết về tính liên kết của bộ đệm. Tôi hiểu rằng thuật toán nhất quán bộ đệm không ổn định tại thời điểm chúng được xuất bản? Hoặc không đủ phổ biến. Ý tưởng của bạn phổ biến như thế nào trong thực tế?

Michael: Tôi không chắc chắn chính xác bạn đang nói về ấn phẩm nào. Tôi đã làm khá nhiều việc với học trò của mình là Bill Bolosky (William Bolosky) và Leonidas Kontotanassis (Leonidas Kontothanassis) vào đầu những năm 1990 về quản lý bộ nhớ của máy Neumann. Vào thời điểm đó, doanh nghiệp vẫn chưa hiểu cách tạo một hệ thống đa bộ xử lý một cách chính xác: có đáng tạo hỗ trợ truy cập bộ nhớ từ xa ở cấp độ phần cứng không, có đáng để phân phối bộ nhớ hay không, có thể tải bộ nhớ đệm từ đó không? bộ nhớ từ xa, hay cần phải di chuyển các trang trong hệ điều hành? Bill và Leonidas đều làm việc trong lĩnh vực này và khám phá các phương pháp tiếp cận mà không cần tải bộ đệm từ xa. Điều này không liên quan trực tiếp đến tính nhất quán của bộ đệm, nhưng nó vẫn hoạt động trên quản lý bộ nhớ NUMA và sau đó là các phương pháp hiện đại để sắp xếp trang trong các hệ điều hành hiện đại đã phát triển từ điều này. Nhìn chung, Bill và Leonidas đã làm được những công việc quan trọng, mặc dù không phải là người có ảnh hưởng nhất trong lĩnh vực này - có rất nhiều người khác đang làm công việc tương tự vào thời điểm đó. Sau đó, tôi nghiên cứu một chủ đề liên quan đến sự gắn kết của bộ đệm trong bối cảnh bộ nhớ giao dịch phần cứng. Nhóm tôi làm việc cùng về vấn đề này cuối cùng đã nhận được một số bằng sáng chế. Có một số ý tưởng khá thú vị đằng sau chúng, nhưng tôi không nghĩ chúng sẽ được áp dụng vào thực tế. Bằng cách này hay cách khác, thật khó để tôi đánh giá khả năng sinh lời của họ. 

Alexey: Về vấn đề này, một câu hỏi mang tính cá nhân hơn: việc áp dụng ý tưởng của bạn vào thực tế quan trọng như thế nào đối với bạn? Hay bạn không nghĩ về nó?

Michael: Tôi thích đặt câu hỏi này trong các cuộc phỏng vấn với người khác, những ứng viên hoặc những ứng viên muốn gia nhập khoa. Tôi không nghĩ có câu trả lời chính xác cho câu hỏi này. Những người làm những điều thú vị có thể có những động cơ rất khác nhau. Tôi bị thu hút bởi các vấn đề vì cá nhân tôi thấy chúng thú vị chứ không phải vì lợi ích thiết thực của chúng. Nhưng mặt khác, khi một điều thú vị nào đó vẫn tìm được ứng dụng thì tôi lại rất thích. Vì vậy, ở đây không dễ dàng. Nhưng khi bắt đầu công việc của mình, tôi vẫn bị thúc đẩy không phải bởi ý tưởng về mục đích sử dụng cuối cùng trên thế giới mà bởi sự hài hòa giữa ý tưởng và mong muốn khám phá nó cũng như xem điều gì sẽ xảy ra từ nó. Nếu cuối cùng nó mang lại kết quả thiết thực thì thật tuyệt. 

Alexey: Nhờ trình độ học vấn và kinh nghiệm của mình, bạn có khả năng đánh giá giá trị ý tưởng của người khác tốt hơn hầu hết mọi người. Bạn có thể so sánh chúng và xác định cái nào hoạt động tốt hơn với cái nào. Tôi chắc rằng bạn có ý kiến ​​​​về những thứ hiện đang được các nhà sản xuất lớn như Intel sử dụng trong thực tế. Theo quan điểm của bạn, hướng đi mà các công ty này đang thực hiện đúng đến mức nào?

Michael: Thực hành luôn xoay quanh những gì có thể thành công về mặt thương mại, tức là tạo ra lợi nhuận và tốt hơn hết bạn nên hỏi người khác về điều đó. Công việc của tôi chủ yếu là các ấn phẩm, còn trong lĩnh vực hệ điều hành, chúng được đánh giá dựa trên các chỉ số hiệu suất: tốc độ, mức tiêu thụ năng lượng, kích thước mã. Nhưng đối với tôi, dường như những kết quả thực nghiệm này chỉ được thêm vào các bài báo để có thể xuất bản và động cơ làm việc thực sự của mọi người là mang tính thẩm mỹ. Các nhà nghiên cứu đánh giá các giải pháp từ góc độ nghệ thuật, họ quan tâm đến mức độ tinh tế của các ý tưởng và họ cố gắng tạo ra thứ gì đó tốt hơn các phương pháp tiếp cận hiện có. Các nhà nghiên cứu được thúc đẩy bởi động cơ cá nhân, chủ quan, thẩm mỹ. Nhưng bạn không thể viết về điều này trong chính bài báo; những điều này không phải là lý lẽ của ủy ban chương trình. May mắn thay, các giải pháp tinh tế thường nhanh chóng và rẻ tiền. Tôi và hàng chục đồng nghiệp đã thảo luận về chủ đề này khoảng 15 năm trước và cuối cùng đã viết một bài báo về nó. Tôi nghĩ bây giờ bạn vẫn có thể tìm thấy nó, nó được gọi là "Cách đánh giá nghiên cứu hệ thống" hay gì đó tương tự, nó có hơn chục tác giả. Đây là bài viết duy nhất mà tôi là tác giả cùng với Sasha Fedorova, vì vậy nếu bạn tìm kiếm tên cô ấy trong danh sách các ấn phẩm của tôi, bạn sẽ tìm thấy những gì bạn cần. Nó nói về việc đánh giá nghiên cứu hệ thống và tầm quan trọng của sự tinh tế. 

Alexey: Như vậy có sự khác biệt giữa tiêu chuẩn về những gì được coi là tốt trong khoa học và trong kinh doanh. Khoa học đánh giá hiệu suất, mức tiêu thụ điện năng, TDP, mức độ dễ triển khai và nhiều hơn thế nữa. Bạn có cơ hội thực hiện loại nghiên cứu này tại trường đại học không? Bạn có phòng thí nghiệm với nhiều máy móc và kiến ​​trúc khác nhau để bạn có thể tiến hành thí nghiệm không?

Michael: Vâng, bộ phận của chúng tôi có rất nhiều máy móc thú vị khác nhau. Thông thường chúng có kích thước nhỏ, chúng ta có một cụm nhỏ và nhiều hệ thống đa bộ xử lý với các bộ tăng tốc khác nhau. Ngoài ra, khuôn viên trường còn có một trung tâm điện toán khổng lồ phục vụ các nhà khoa học từ hàng chục ngành khác nhau. Nó có khoảng một nghìn nút và hai mươi nghìn lõi, tất cả đều chạy trên Linux. Nếu có nhu cầu, bạn luôn có thể mua một ít AWS. Vì vậy, chúng tôi không có hạn chế đáng kể nào với phần cứng. 

Alexey: Ba mươi năm trước nó như thế nào? Lúc đó có vấn đề gì không?

Michael: Hồi đó hơi khác một chút. Vào giữa đến cuối những năm 1980, khoa học được coi là thiếu tài nguyên máy tính. Để khắc phục tình trạng này, Quỹ khoa học quốc gia (Quỹ khoa học quốc gia) đã tạo ra một chương trình nghiên cứu thực nghiệm phối hợp (Cobbeded Experimental Research, CER). Sứ mệnh của chương trình là cung cấp cơ sở hạ tầng điện toán cho các khoa Khoa học Máy tính và nó đã đạt được sự thay đổi đáng kể. Với số tiền cô ấy cung cấp, chúng tôi tại Đại học Rochester đã mua một chiếc BBN Butterfly 1984 nút vào năm 128, đó là một năm trước khi tôi đến đó. Vào thời điểm đó, nó là hệ thống đa bộ xử lý lớn nhất thế giới có bộ nhớ dùng chung. Nó có 128 bộ xử lý, mỗi bộ xử lý nằm trên một bo mạch chủ riêng biệt và chiếm bốn giá đỡ. Mỗi bộ xử lý có một megabyte bộ nhớ, 128 megabyte RAM là một con số không thể tưởng tượng được vào thời điểm đó. Trên máy này, lần đầu tiên chúng tôi triển khai khóa MCS. 

Alexey: Vậy nếu tôi hiểu đúng ý bạn thì hiện tại vấn đề về phần cứng đã được giải quyết chưa? 

Michael: Nói chung là có. Có một số lưu ý: trước tiên, nếu bạn đang làm kiến ​​trúc máy tính ở cấp độ chip, thì khó có thể làm được điều đó trong môi trường học thuật vì có nhiều công cụ tốt hơn để thực hiện việc đó trong kinh doanh. Nếu bạn cần bất cứ thứ gì nhỏ hơn 10 nanomet, bạn sẽ phải đặt hàng từ người khác. Trong lĩnh vực này, việc trở thành nhà nghiên cứu tại Intel dễ dàng hơn nhiều. Nếu bạn đang nghiên cứu về truyền thông quang học trên chip hoặc trên bộ nhớ thể rắn, bạn sẽ tìm thấy những công nghệ trong kinh doanh chưa có trong khoa học, vì vậy bạn phải tạo ra các liên minh. Ví dụ: Stephen Swanson (Steven Swanson) tạo sự hợp tác như vậy cho các công nghệ bộ nhớ mới. Hình thức này không phải lúc nào cũng hiệu quả, nhưng trong một số trường hợp, nó có thể khá thành công. Ngoài ra, trong khoa học, việc phát triển các hệ thống máy tính mạnh nhất còn khó khăn hơn. Các dự án siêu máy tính lớn nhất hiện nay ở Mỹ, Nhật Bản, Trung Quốc đều tập trung vào kinh doanh. 

Thực tế triển khai ý tưởng. MCS, MS, CLH, JSR 166, làm việc với Doug Lee và hơn thế nữa.

Виталий: Bạn đã nói về cách bạn bắt đầu nghiên cứu các thuật toán đồng bộ hóa. Bạn có hai bài viết rất nổi tiếng về Chặn MCS и Hàng đợi Michael-Scott (MS), theo một nghĩa nào đó, đã được triển khai trong Java. (Ghi chú của biên tập viên: tất cả các ấn phẩm có thể được xem по ссылке). Ở đó, việc chặn này đã được thực hiện với một số thay đổi và hóa ra khóa CLHvà hàng đợi đã được triển khai như dự định. Nhưng đã nhiều năm trôi qua từ khi xuất bản các bài báo của bạn cho đến khi áp dụng chúng vào thực tế. 

Alexey: Có vẻ như khoảng 10 năm trong trường hợp xếp hàng.

Michael: Trước khi các tính năng này xuất hiện trong thư viện chuẩn Java?

Виталий: Đúng. Bạn đã làm gì để điều này xảy ra? Hay họ không làm gì cả?

Michael: Tôi có thể cho bạn biết MS Queue được đưa vào Java 5 như thế nào. Vài năm trước khi nó ra mắt, tôi đã làm việc với nhóm của Mark Moyers tại Sun Microsystems trong phòng thí nghiệm của họ gần Boston. Anh ấy đã tổ chức một hội thảo cho những người mà anh ấy biết đang giải quyết các vấn đề thú vị trong đa luồng vì anh ấy muốn tìm các chủ đề mà anh ấy có thể bán cho công ty của họ. Đó là nơi lần đầu tiên tôi gặp Doug Lea. Doug và tôi cùng khoảng 25 người khác từ Sun cùng nhau thảo luận về bài thuyết trình của Doug về JSR 166, sau này trở thành java.util.concurrent. Đồng thời, Doug nói rằng anh ấy muốn sử dụng hàng đợi MS, nhưng để làm được điều này, anh ấy cần một bộ đếm số phần tử trong hàng đợi cho giao diện. Nghĩa là, việc này lẽ ra phải được thực hiện bằng một phương pháp riêng biệt, nguyên tử, chính xác và nhanh chóng. Tôi đề nghị chỉ cần thêm số sê-ri vào các nút, lấy số của nút đầu tiên và nút cuối cùng rồi trừ đi nút kia. Doug gãi đầu, nói “tại sao không” và cuối cùng chỉ làm được điều đó. Chúng tôi đã thảo luận về việc triển khai phương pháp này trong thư viện, nhưng Doug đã tự mình thực hiện hầu hết công việc. Kết quả là anh ấy đã thiết lập được khả năng hỗ trợ đa luồng tuyệt vời trong Java. 

Alexey: Vì vậy, nếu tôi hiểu chính xác thì phương thức .size() lẽ ra phải là một phần của giao diện hàng đợi tiêu chuẩn và nó phải có độ phức tạp thuật toán là O(1)?

Michael: Có, và ngoài ra, cần có một bộ đếm riêng.

Alexey: Bởi vì nếu bạn gọi phương thức .size() trong Java, kết quả dự kiến ​​sẽ có ngay lập tức và không dựa trên kích thước thực tế của bộ sưu tập. Tôi hiểu rôi, cảm ơn bạn.

Michael: Vài năm sau, tôi đang làm việc về cấu trúc dữ liệu kép với sinh viên Bill Scherer của mình - thực tế, đây chính là điều tôi sẽ nói đến báo cáo về Hydra. Doug đến gặp chúng tôi và nói rằng anh ấy có thể sử dụng chúng trong Java Executor Framework. Cùng với Bill, họ đã tạo ra hai cách triển khai, được gọi là hàng đợi công bằng và không công bằng. Tôi đã tư vấn cho họ về dự án này, mặc dù tôi không tham gia viết mã thực tế. Nhờ đó, tốc độ của người thực thi đã tăng lên đáng kể. 

Vladimir: Bạn có gặp phải việc triển khai thuật toán không chính xác hoặc yêu cầu thêm tính năng mới không? Nói chung, thực hành phải trùng khớp với lý thuyết, nhưng chúng thường khác nhau. Giả sử bạn đã viết một thuật toán và trên giấy tờ nó hoạt động, nhưng những người tham gia vào quá trình triển khai bắt đầu yêu cầu bạn cung cấp thêm các tính năng hoặc một số loại chỉnh sửa nào đó cho thuật toán. Bạn đã bao giờ gặp những tình huống như vậy chưa?

Michael: Ví dụ duy nhất mà ai đó đến gặp tôi và hỏi “làm thế nào để triển khai nó” là câu hỏi của Doug mà tôi đã nói đến. Nhưng đã có một vài trường hợp những thay đổi thú vị được thực hiện để phù hợp với nhu cầu thực tế. Ví dụ: nhóm K42 tại IBM đã chuyển đổi khóa MCS và biến nó thành giao diện chuẩn để không cần phải chuyển nút hàng đợi qua lại cho các quy trình thu thập và giải phóng. Nhờ giao diện tiêu chuẩn này, một ý tưởng đẹp về mặt lý thuyết đã bắt đầu được áp dụng trên thực tế. Điều đáng ngạc nhiên là họ chưa bao giờ xuất bản một bài báo nào về nó và mặc dù đã nhận được bằng sáng chế nhưng sau đó họ đã từ bỏ nó. Ý tưởng này thật tuyệt vời và tôi cố gắng nói về nó bất cứ khi nào có thể. 

Đã có những trường hợp khác mà mọi người đã cải tiến các thuật toán mà tôi đã xuất bản. Ví dụ: hàng đợi MS có cơ chế cài đặt hai bước, nghĩa là có hai CAS trên đường tới hạn của hàng đợi. Trên những chiếc xe cũ, CAS khá đắt. Intel và các nhà sản xuất khác gần đây đã tối ưu hóa chúng khá tốt, nhưng ngày xưa đây là những hướng dẫn 30 chu kỳ, do đó, việc có nhiều hơn một hướng dẫn trên đường tới hạn là điều không mong muốn. Kết quả là, một hàng đợi riêng biệt đã được phát triển tương tự như hàng đợi MS, nhưng chỉ có một hoạt động nguyên tử trên đường tới hạn. Điều này đạt được là do trong một khoảng thời gian nhất định, hoạt động có thể mất thời gian O(n), thay vì O(1). Điều đó khó xảy ra nhưng có thể xảy ra. Điều này xảy ra do tại một số thời điểm nhất định, thuật toán đi qua hàng đợi từ đầu đến vị trí hiện tại trong hàng đợi này. Nói chung, thuật toán hóa ra rất thành công. Theo những gì tôi biết, nó không được sử dụng rộng rãi, một phần vì các hoạt động nguyên tử đòi hỏi ít tài nguyên hơn đáng kể so với trước đây. Nhưng ý tưởng đó thật tuyệt vời. Tôi cũng thực sự thích tác phẩm của Dave Dice từ Oracle. Mọi việc anh ấy làm đều rất thực tế và anh ấy sử dụng sắt rất khéo léo. Anh ấy đã nắm trong tay phần lớn các thuật toán đồng bộ hóa nhận biết NUMA và cấu trúc dữ liệu đa luồng. 

Vladimir: Khi bạn viết thuật toán hoặc dạy học sinh, kết quả công việc của bạn không được nhìn thấy ngay lập tức. Cộng đồng cần một thời gian để làm quen với một bài viết mới. Thuật toán mới không tìm thấy ứng dụng ngay lập tức. 

Michael: Vẫn chưa rõ ngay liệu bài viết có quan trọng hay không. Tôi nghĩ sẽ rất thú vị nếu nghiên cứu các bài báo đã giành được giải thưởng tại các hội nghị. Nghĩa là, hãy xem những bài báo mà những người trong ủy ban chương trình đã từng cho là hay nhất. Bạn cần cố gắng tính toán bằng số lượng liên kết và tác động đến doanh nghiệp xem những bài báo này thực sự có tầm ảnh hưởng như thế nào trong 10, 20, 25 năm nữa. Tôi nghi ngờ sẽ có một mối tương quan mạnh mẽ giữa hai điều này. Nó sẽ không bằng 10, nhưng rất có thể nó sẽ yếu hơn nhiều so với những gì chúng ta mong muốn. Nhiều ý tưởng vẫn chưa được thừa nhận trong một thời gian dài trước khi chúng trở nên phổ biến. Ví dụ: hãy lấy bộ nhớ giao dịch. Đã hơn 20 năm trôi qua kể từ khi bài báo gốc được xuất bản cho đến khi người ta thực sự bắt đầu chế tạo máy móc bằng nó. Và trước khi xuất hiện bộ nhớ này trong các sản phẩm thương mại - và tất cả đều là XNUMX. Trong một thời gian rất dài không ai chú ý đến bài báo, và sau đó số lượng liên kết đến nó tăng mạnh. Sẽ rất khó để dự đoán trước điều này. Mặt khác, đôi khi ý tưởng được thực hiện ngay lập tức. Một vài năm trước, tôi đã viết một bài báo với Joe Izraelevitz cho DISC đề xuất một định nghĩa chính thức mới về tính hợp lệ đối với các cấu trúc dữ liệu liên tục có thể được sử dụng sau khi máy tính chạy chúng bị hỏng. Tôi đã thích bài viết này ngay từ đầu, nhưng hóa ra nó lại phổ biến hơn tôi mong đợi rất nhiều. Nó được nhiều nhóm khác nhau sử dụng và cuối cùng trở thành định nghĩa tiêu chuẩn về cấu trúc bền vững. Tất nhiên, điều đó là tốt đẹp.

Vladimir: Bạn có sử dụng kỹ thuật nào để đánh giá không? Bạn thậm chí có cố gắng đánh giá các bài viết và học sinh của mình không? Xét về việc người bạn dạy có đi đúng hướng hay không.

Michael: Giống như mọi người khác, tôi chú ý hơn đến những gì mình đang làm vào lúc này. Một lần nữa, giống như những người khác, thỉnh thoảng tôi kiểm tra Google Scholar để xem liệu các bài viết trước đây của tôi có được trích dẫn hay không, nhưng điều đó chỉ vì tò mò mà thôi. Tôi chủ yếu quan tâm đến những gì học sinh của tôi đang làm bây giờ. Khi đánh giá tác phẩm hiện tại, một phần là cân nhắc về mặt thẩm mỹ, cái gì là sang trọng và cái gì là không. Và ở cấp độ hàng ngày, các câu hỏi mở đóng một vai trò lớn. Ví dụ, một sinh viên đến gặp tôi với một biểu đồ chứa một số kết quả và chúng tôi đang cố gắng hiểu xem hành vi kỳ lạ nào đó của biểu đồ đến từ đâu. Nói chung, trong công việc, chúng tôi không ngừng cố gắng hiểu những điều mà chúng tôi chưa hiểu. 

Bộ nhớ giao dịch

Виталий: Có lẽ chúng ta có thể nói một chút về bộ nhớ giao dịch?

Michael: Tôi nghĩ ít nhất cũng đáng nói một chút vì tôi đã nỗ lực rất nhiều vào nó. Đây là chủ đề mà tôi có nhiều ấn phẩm hơn bất kỳ chủ đề nào khác. Nhưng đồng thời, thật kỳ lạ, tôi luôn rất nghi ngờ về trí nhớ giao dịch. Theo tôi, bài viết của Herlihy và Moss (M. Herlihy, J. E. B. Moss) đã được xuất bản trước thời đại. Vào đầu những năm 1990, họ cho rằng bộ nhớ giao dịch có thể giúp các lập trình viên tài năng làm việc trên các cấu trúc dữ liệu đa luồng, để các cấu trúc này sau đó có thể được các lập trình viên bình thường sử dụng làm thư viện. Nghĩa là, nó sẽ giúp ích cho Doug Lee khi thực hiện JSR 166 của mình. Nhưng bộ nhớ giao dịch không nhằm mục đích giúp việc lập trình đa luồng trở nên dễ dàng. Nhưng đây chính xác là cách nó bắt đầu được nhìn nhận vào đầu những năm 2000, khi nó trở nên phổ biến. Nó được quảng cáo như một cách để giải quyết vấn đề lập trình song song. Cách tiếp cận này luôn có vẻ vô vọng đối với tôi. Bộ nhớ giao dịch chỉ có thể giúp việc ghi cấu trúc dữ liệu song song dễ dàng hơn. Đối với tôi, có vẻ như đây là điều cô ấy đã đạt được. 

Về khó khăn khi viết mã đa luồng

Alexey: Rất thú vị. Dường như có một rào cản nhất định giữa những lập trình viên thông thường và những người có thể viết mã đa luồng. Năm ngoái, tôi đã nói chuyện vài lần với những người đang triển khai một số khung thuật toán. Ví dụ như với Martin Thomson, cũng như với các lập trình viên làm việc trên các thư viện đa luồng. (Ghi chú của biên tập viên: Martin Thompson là một nhà phát triển rất nổi tiếng, ông ấy đã viết Disruptor и Aeron. Và anh ấy cũng có báo cáo tại hội nghị Joker 2015 của chúng tôi, quay video có sẵn trên YouTube. Anh ấy cũng vậy đã mở hội nghị này ghi âm bài phát biểu quan trọng cũng có sẵn). Họ cho rằng thách thức chính là làm cho các thuật toán vừa nhanh vừa dễ sử dụng. Tức là họ đang cố gắng vượt qua rào cản này và thu hút càng nhiều người càng tốt đến khu vực này. Bạn nghĩ gì về nó?

Michael: Đây là vấn đề chính của đa luồng: làm thế nào để đạt được hiệu suất cao mà không làm tăng độ phức tạp của hệ thống. 

Alexey: Bởi vì khi họ cố gắng tránh sự phức tạp, thuật toán sẽ trở nên kém phổ biến hơn.

Michael: Chìa khóa ở đây là sự trừu tượng được thiết kế hợp lý. Đối với tôi, có vẻ như đây nói chung là vấn đề chính đối với hệ thống máy tính như một lĩnh vực. Butler Lampson thích sử dụng thuật ngữ này và gọi chúng tôi là “những người buôn bán những thứ trừu tượng”. Công nghệ đơn giản không tồn tại ngày nay. Bộ xử lý chúng tôi sử dụng có 10 tỷ bóng bán dẫn—sự đơn giản là điều không cần bàn cãi. Đồng thời, ISA đơn giản hơn nhiều so với bộ xử lý, vì chúng tôi đã làm việc trong một thời gian rất dài để cung cấp cho nó hiệu suất cao và giao diện tương đối đơn giản. Nhưng không phải mọi thứ đều suôn sẻ với cô ấy. Vấn đề tương tự cũng xảy ra với các máy gia tốc hiện đang xuất hiện trên thị trường. Các câu hỏi đặt ra - làm thế nào để tạo giao diện phù hợp cho GPU, cơ chế mã hóa, nén, cơ chế chuyển mã, cơ chế đại số tuyến tính hoặc thậm chí là một FPGA linh hoạt hơn. Làm cách nào để tạo một giao diện giúp công cụ này dễ sử dụng và ẩn đi sự phức tạp? Nó sẽ không loại bỏ nó mà chỉ giấu nó khỏi một lập trình viên đơn giản. 

Alexey: Theo tôi hiểu, chúng ta vẫn có rào cản trong việc hiểu những điều trừu tượng. Hãy lấy mô hình bộ nhớ; ở giai đoạn phát triển khoa học và công nghệ của chúng ta, đây là một trong những khái niệm trừu tượng chính. Nhờ nó mà tất cả các lập trình viên được chia thành hai nhóm: phần lớn hơn là những người không hiểu nó, và phần nhỏ hơn là những người hiểu hoặc cho rằng mình hiểu. 

Michael: Đó là một câu hỏi hay - có ai trong chúng ta thực sự hiểu mô hình bộ nhớ không?

Виталий: Đặc biệt là trong C++.

Michael: Thỉnh thoảng hãy nói chuyện với Hans Boehm. Anh ấy là một trong những người thông minh nhất mà tôi biết, một chuyên gia hàng đầu về các mô hình trí nhớ. Anh ấy sẽ nói ngay với bạn rằng có rất nhiều điều anh ấy không hiểu. Nhưng nếu chúng ta quay trở lại vấn đề trừu tượng, thì theo tôi, ý tưởng quan trọng nhất trong lĩnh vực mô hình bộ nhớ trong 30 năm qua đã được thể hiện trong luận án của Sarita Adve. (Ghi chú của biên tập viên: có sẵn danh sách đầy đủ các ấn phẩm по ссылке).

Alexey: Câu hỏi của tôi là: rào cản này có xuất phát từ bản chất của khái niệm này không? 

Michael: KHÔNG. Sarita đi đến kết luận rằng với cách tiếp cận phù hợp, bạn có thể che giấu thành công mọi sự phức tạp, đạt được hiệu suất cao và cung cấp cho lập trình viên một API đơn giản. Và nếu bạn tuân theo API này, bạn có thể đạt được tính nhất quán nhất quán. Tôi nghĩ đây là mô hình phù hợp. Viết mã mà không cần chạy đua dữ liệu và có được tính nhất quán tuần tự. Tất nhiên, để giảm khả năng xảy ra đua xe thì cần có những công cụ đặc biệt, nhưng đó lại là một vấn đề khác. 

Vladimir: Đã có lúc nào trong sự nghiệp của bạn, một vấn đề tưởng chừng như đã được giải quyết lại đột nhiên trở thành một thảm họa, hoặc hóa ra vấn đề này là không thể giải quyết được? Ví dụ, về lý thuyết, bạn có thể phân tích bất kỳ số nào hoặc xác định xem số nào có phải là số nguyên tố hay không. Nhưng trong thực tế điều này có thể khó thực hiện; với phần cứng hiện tại thì rất khó để phân tích các con số. Có điều gì tương tự đã xảy ra với bạn không?

Michael: Tôi không nhớ ngay bất cứ điều gì như thế. Đã có lúc tôi tưởng như không còn gì để làm ở một khu vực nào đó, nhưng rồi có điều gì đó mới mẻ và thú vị đã xảy ra ở đó. Ví dụ, tôi nghĩ rằng khu vực xếp hàng không giới hạn đã đạt đến mức trưởng thành. Sau một số cải tiến đối với hàng đợi MNS, không có gì xảy ra nhiều nữa. Và rồi Morrison (Adam Morrison) và Afek (Yehuda Afek) đã phát minh ra hàng đợi LCRQ. Rõ ràng là có thể có hàng đợi đa luồng không giới hạn, trong đó hầu hết thời gian chỉ có lệnh tìm nạp và tăng trên đường dẫn quan trọng. Và điều này giúp có thể đạt được hiệu suất tốt hơn nhiều. Không phải là chúng ta không biết rằng tìm nạp và tăng là một điều rất hữu ích. Eric Freudenthal đã viết về điều này trong nghiên cứu của ông về Ultracomputer với Allan Gottlieb vào cuối những năm 1980, nhưng đó là về hàng đợi hạn chế. Morrison và Afek có thể sử dụng tính năng tìm nạp và tăng dần trên hàng đợi không giới hạn.

Những kiến ​​trúc mới. Chiến thắng của ký ức giao dịch đã gần kề?

Vladimir: Bạn đang tìm kiếm giải pháp kiến ​​trúc mới có thể hữu ích cho các thuật toán? 

Michael: Tất nhiên, có rất nhiều điều tôi muốn thấy được thực hiện. 

Vladimir: Loại gì chẳng hạn?

Michael: Trước hết, một số phần mở rộng đơn giản cho bộ nhớ giao dịch cấp phần cứng của chúng tôi trong bộ xử lý Intel và IBM. Đặc biệt, tôi muốn tải và lưu trữ phi giao dịch vừa xảy ra sẽ có sẵn ngay lập tức trong các giao dịch. Chúng ngay lập tức dẫn đến các vòng lặp trong trình tự xảy ra trước đó, vì vậy chúng có thể khó thực hiện. Nhưng nếu bạn duy trì các lớp trừu tượng, có rất nhiều điều rất thú vị bạn có thể thực hiện bên ngoài giao dịch trong khi nó đang diễn ra. Tôi không biết việc này sẽ khó thực hiện đến mức nào nhưng nó sẽ rất hữu ích. 

Một điều hữu ích khác là tải bộ đệm từ bộ nhớ từ xa. Tôi nghĩ sớm hay muộn việc này cũng sẽ được thực hiện. Công nghệ này sẽ cho phép tạo ra các hệ thống có bộ nhớ được phân chia. Chẳng hạn, có thể giữ 100 terabyte bộ nhớ không khả biến trong một giá và bản thân hệ điều hành sẽ tự động quyết định phần nào của bộ nhớ đó sẽ tương ứng với không gian địa chỉ vật lý của bộ xử lý. Điều này sẽ cực kỳ hữu ích cho điện toán đám mây vì nó sẽ cho phép cung cấp lượng lớn bộ nhớ cho các tác vụ cần đến nó. Tôi nghĩ ai đó sẽ làm điều đó.

Виталий: Để kết thúc việc nói về bộ nhớ giao dịch, tôi có thêm một câu hỏi về chủ đề này. Bộ nhớ giao dịch cuối cùng sẽ thay thế cấu trúc dữ liệu đa luồng tiêu chuẩn?

Michael: KHÔNG. Giao dịch là một cơ chế đầu cơ. Ở cấp độ lập trình, đây là những khóa nguyên tử, nhưng bên trong chúng là những suy đoán. Dự báo như vậy sẽ có tác dụng nếu hầu hết các dự đoán đều đúng. Do đó, bộ nhớ giao dịch hoạt động tốt khi các luồng hầu như không tương tác với nhau và bạn chỉ cần đảm bảo rằng không có tương tác nào. Nhưng nếu một tin nhắn bắt đầu giữa các luồng thì các giao dịch sẽ ít được sử dụng. Hãy để tôi giải thích, chúng ta đang nói về trường hợp các giao dịch được bao bọc xung quanh toàn bộ hoạt động nguyên tử. Chúng vẫn có thể được sử dụng thành công làm thành phần cho cấu trúc dữ liệu đa luồng. Ví dụ: nếu bạn cần một CAS gồm ba từ và bạn cần đa luồng ba thứ nhỏ ở giữa một thuật toán thực sự đa luồng hoạt động với 20 luồng cùng lúc. Nói chung, các giao dịch có thể hữu ích, nhưng chúng sẽ không loại bỏ nhu cầu thiết kế đúng cấu trúc dữ liệu đa luồng. 

Bộ nhớ ổn định, Optane DIMM, thiết bị cực nhanh.

Виталий: Điều cuối cùng tôi muốn nói đến là chủ đề nghiên cứu hiện tại của bạn: trí nhớ bất biến. Chúng ta có thể mong đợi điều gì ở khu vực này trong tương lai gần? Có lẽ bạn biết bất kỳ triển khai hiệu quả nào đã tồn tại? 

Michael: Tôi không phải là chuyên gia phần cứng, tôi chỉ biết những gì đọc được trên tin tức và những gì đồng nghiệp nói với tôi. Mọi người đều đã nghe nói rằng Intel bán DIMM quang học, có độ trễ đọc gấp khoảng 3 lần và độ trễ ghi gấp khoảng 10 lần so với RAM động. Chúng sẽ sớm có sẵn với phiên bản số lượng rất lớn. Thật buồn cười khi nghĩ rằng bạn có thể có một chiếc máy tính xách tay với vài terabyte RAM có thể định địa chỉ theo byte. Có khả năng trong 10 năm nữa chúng tôi sẽ quyết định sử dụng công nghệ mới này, vì chúng tôi sử dụng DRAM - chỉ cần tăng âm lượng. Nhưng nhờ độc lập về năng lượng, những cơ hội hoàn toàn mới mở ra cho chúng ta. Về cơ bản, chúng ta có thể thay đổi ngăn xếp lưu trữ để không có sự tách biệt giữa bộ nhớ làm việc có thể định địa chỉ byte và bộ nhớ liên tục có cấu trúc khối. Vì vậy, chúng ta sẽ không cần phải tuần tự hóa mọi thứ cần chuyển từ chương trình này sang chương trình khác thành các tệp có cấu trúc khối. Từ đó, chúng ta có thể rút ra nhiều nguyên tắc quan trọng ảnh hưởng đến hệ điều hành, môi trường thời gian chạy và kho dữ liệu phân tán. Khu vực này rất thú vị để làm việc. Cá nhân tôi rất khó để dự đoán tất cả những điều này sẽ dẫn đến điều gì, nhưng những vấn đề ở đây cực kỳ thú vị. Ở đây có thể có những thay đổi mang tính cách mạng và chúng diễn ra rất tự nhiên từ công việc đa luồng, vì việc khắc phục lỗi là một quá trình "đa luồng" bên cạnh hoạt động bình thường của hệ thống. 

Chủ đề chính thứ hai mà tôi hiện đang thực hiện là quản lý các thiết bị cực nhanh và quyền truy cập an toàn vào các thiết bị từ không gian người dùng bằng tính năng kiểm soát chính sách hệ thống. Trong những năm gần đây, có xu hướng chuyển quyền truy cập vào thiết bị sang không gian người dùng. Điều này được thực hiện vì ngăn xếp hạt nhân TCP-IP không thể hoạt động trên giao diện mạng cần gói mới cứ sau 5 micro giây; Do đó, các nhà sản xuất cung cấp quyền truy cập trực tiếp vào thiết bị. Nhưng điều này có nghĩa là hệ điều hành mất quyền kiểm soát quy trình và nó không thể cung cấp quyền truy cập thích hợp vào thiết bị cho các ứng dụng cạnh tranh. Nhóm nghiên cứu của chúng tôi tin rằng thiếu sót này có thể tránh được. Chúng tôi sẽ có bài viết về vấn đề này tại USENIX ATC trong tháng này. Nó liên quan đến công việc về tính bền bỉ, vì về bản chất, bộ nhớ liên tục có thể định địa chỉ byte tồn tại lâu dài là một thiết bị có I/O cực nhanh cần được truy cập trong không gian người dùng. Nghiên cứu này tạo ra các phương pháp tiếp cận mới khả thi đối với vi hạt nhân, hạt nhân ngoài và các nỗ lực truyền thống khác nhằm di chuyển chức năng từ nhân hệ điều hành sang không gian người dùng một cách an toàn. 

Vladimir: Bộ nhớ có thể định địa chỉ theo byte rất tốt nhưng có một giới hạn vật lý - tốc độ ánh sáng. Điều này đồng nghĩa với việc chắc chắn sẽ có độ trễ khi tương tác với thiết bị. 

Michael: Hoàn toàn đúng.

Vladimir: Liệu có đủ năng lực để đáp ứng tải trọng mới không?

Michael: Đây là một câu hỏi hay, nhưng tôi sẽ khó trả lời. Ý tưởng xử lý trong bộ nhớ đã có từ khá lâu, nó rất thú vị nhưng cũng rất phức tạp. Tôi chưa từng làm việc trong lĩnh vực này, nhưng sẽ thật tuyệt nếu có một số khám phá nào đó được thực hiện ở đó. Tôi e rằng tôi không còn gì để thêm nữa. 

Vladimir: Còn một vấn đề nữa. Dung lượng RAM mới, lớn hơn đáng kể sẽ không thể lắp vừa vào CPU. Do đó, do hạn chế về mặt vật lý nên RAM này phải được cách ly. 

Michael: Tất cả phụ thuộc vào số lượng lỗi trong quá trình sản xuất mạch tích hợp. Nếu có thể tạo ra các tấm bán dẫn hoàn toàn không có khuyết tật thì cũng có thể tạo ra toàn bộ một vi mạch từ nó. Nhưng bây giờ chúng ta không biết cách tạo ra các vi mạch lớn hơn tem bưu chính. 

Vladimir: Nhưng chúng ta vẫn đang nói về kích thước khổng lồ, khoảng centimet. Điều này chắc chắn có tác động đến độ trễ. 

Michael: Đúng. Bạn không thể làm gì với tốc độ ánh sáng. 

Vladimir: Không may thay. 

Xu hướng lớn tiếp theo. Cấu trúc dữ liệu kép. Hydra.

Виталий: Theo tôi hiểu thì bạn nắm bắt xu hướng mới rất nhanh. Bạn là một trong những người đầu tiên làm việc trong lĩnh vực bộ nhớ giao dịch và là một trong những người đầu tiên làm việc trong lĩnh vực bộ nhớ ổn định. Bạn nghĩ xu hướng lớn tiếp theo sẽ là gì? Hoặc có lẽ đó là một bí mật?

Michael: Thành thật mà nói thì tôi không biết. Hy vọng tôi sẽ có thể nhận ra khi có điều gì đó mới xuất hiện. Tôi không đủ may mắn để tự mình phát minh ra bất kỳ lĩnh vực mới nào, nhưng tôi đã có một chút may mắn và có thể bắt đầu làm việc khá sớm trong các lĩnh vực mới do người khác tạo ra. Tôi hy vọng tôi sẽ có thể làm được điều này trong tương lai.

Alexey: Câu hỏi cuối cùng trong cuộc phỏng vấn này sẽ là về thành tích của bạn tại Hydra và các hoạt động của bạn ở trường. Nếu tôi hiểu đúng thì báo cáo ở trường sẽ về thuật toán không chặn, và tại hội thảo về cấu trúc dữ liệu kép. Bạn có thể nói vài lời về những báo cáo này?

Michael: Một phần, chúng tôi đã đề cập đến những chủ đề này với bạn trong cuộc phỏng vấn này. Đó là về công việc tôi đã làm với học trò Bill Scherer của mình. Anh ấy đã viết luận văn về nó và Doug Lee cũng đóng góp cho nó, và cuối cùng nó đã trở thành một phần của hàng đợi đồng bộ đa luồng trong thư viện Java. Giả sử rằng cấu trúc dữ liệu được đọc và ghi mà không bị chặn, nghĩa là mỗi thao tác có một số hướng dẫn giới hạn trên đường dẫn quan trọng. Nếu bạn cố gắng xóa dữ liệu khỏi vùng chứa trống hoặc cố xóa một số dữ liệu nhất định không có trong vùng chứa này, bạn sẽ được thông báo ngay lập tức rằng việc này không thể thực hiện được. Nhưng hành vi này có thể không được chấp nhận nếu luồng thực sự cần dữ liệu này. Sau đó, điều đầu tiên bạn nghĩ đến là tạo một vòng lặp sẽ liên tục hỏi xem dữ liệu cần thiết đã xuất hiện chưa. Nhưng sau đó có sự can thiệp đối với những người khác. Ngoài ra, với cách làm này, bạn có thể đợi 10 phút, sau đó một số luồng khác sẽ đến và nó sẽ vô tình nhận được dữ liệu cần thiết trước. Cấu trúc dữ liệu kép vẫn không có khóa nhưng chúng cho phép các luồng chờ đúng cách. Thuật ngữ "kép" có nghĩa là cấu trúc chứa dữ liệu hoặc yêu cầu dữ liệu, hãy gọi chúng là phản dữ liệu. Vì vậy, nếu bạn cố gắng truy xuất thứ gì đó từ một vùng chứa trống, thay vào đó, một yêu cầu sẽ được đưa vào vùng chứa đó. Bây giờ, chuỗi có thể chờ yêu cầu mà không làm phiền người khác. Ngoài ra, cấu trúc dữ liệu chỉ định mức độ ưu tiên cho các yêu cầu để khi nhận được, nó sẽ chuyển chúng đến đúng người. Kết quả là một cơ chế không khóa vẫn có thông số kỹ thuật chính thức và hoạt động tốt trong thực tế. 

Alexey: Bạn mong đợi điều gì từ cấu trúc dữ liệu này? Nó sẽ cải thiện hiệu suất trong tất cả các trường hợp phổ biến hay phù hợp hơn với một số tình huống nhất định? 

Michael: Sẽ rất hữu ích nếu trước tiên, bạn cần một vùng chứa không có khóa và thứ hai, bạn cần đợi trong trường hợp bạn cần truy xuất dữ liệu từ vùng chứa không có trong đó. Theo hiểu biết tốt nhất của tôi, khuôn khổ của chúng tôi cung cấp hành vi tối ưu khi đáp ứng hai điều kiện này. Vì vậy, trong những trường hợp này tôi khuyên bạn nên sử dụng nó. Ưu điểm chính của cấu trúc dữ liệu không khóa là chúng tránh được các vấn đề về hiệu suất. Và việc chờ đợi là rất quan trọng trong nhiều thuật toán nếu dữ liệu được truyền từ luồng này sang luồng khác.

Виталий: Hãy để tôi làm rõ: bạn sẽ nói về cùng một điều ở cả trường và hội nghị chứ?

Michael: Ở trường tôi sẽ nói nói chung về cấu trúc dữ liệu đa luồng, với những nguyên tắc cơ bản đã nêu ở đầu bài. Tôi cho rằng khán giả biết chủ đề là gì và quen thuộc với ổ khóa. Dựa trên kiến ​​thức cơ bản này, tôi sẽ nói về cấu trúc dữ liệu không khóa. Tôi sẽ đưa ra cái nhìn tổng quan về các vấn đề quan trọng nhất trong lĩnh vực này, đề cập đến các chủ đề như quản lý bộ nhớ. Tôi không nghĩ sẽ có điều gì phức tạp hơn hàng đợi MS.

Alexey: Bạn có dự định dạy về cấu trúc dữ liệu kép vào cuối giờ học ở trường không?

Michael: Tôi sẽ đề cập đến chúng, nhưng tôi sẽ không dành nhiều thời gian cho chúng. Báo cáo của Hydra sẽ được dành riêng cho họ. Nó sẽ đề cập đến dự án cuối cùng đã được đưa vào Java, cũng như hợp tác với Joe Israelevich để tạo ra một biến thể kép của hàng đợi LCRQ và tạo ra một thiết kế gần như phổ quát cho các cấu trúc dữ liệu kép.

Alexey: Vì vậy, bài giảng ở trường có thể được khuyến khích cho người mới bắt đầu và bài giảng về cấu trúc dữ liệu kép trên Hydra - dành cho những người đã có một số kinh nghiệm?

Michael: Hãy sửa tôi nếu tôi sai, nhưng khán giả tại Hydra sẽ khá đa dạng, bao gồm nhiều chuyên gia Java và nói chung là những người không liên quan cụ thể đến lập trình đa luồng. 

Виталий: Vâng, đó là sự thật.

Alexey: Ít nhất chúng tôi hy vọng như vậy.

Michael: Trong trường hợp này, tôi sẽ phải đối mặt với cùng một vấn đề mà chúng tôi đã bắt đầu cuộc phỏng vấn này: làm thế nào để tạo một báo cáo vừa đủ phong phú về chi tiết kỹ thuật vừa có thể tiếp cận được với tất cả người nghe.

Виталий: Bạn sẽ trình bày báo cáo giống như cách bạn giảng bài chứ? Tức là nói chuyện với khán giả và thích ứng với hoàn cảnh?

Michael: Tôi e rằng mọi chuyện sẽ không diễn ra theo cách đó, vì báo cáo sẽ có slide. Các slide rất quan trọng khi người nghe ban đầu nói các ngôn ngữ khác nhau. Nhiều người sẽ thấy khó hiểu tiếng Anh của tôi, đặc biệt nếu tôi nói quá nhanh. Tôi chọn những chủ đề này vì Pyotr Kuznetsov yêu cầu tôi nói về cấu trúc dữ liệu không khóa tại Trường SPTDC; và sau đó tôi cần một báo cáo cho một hội nghị nhóm người dùng Java và tôi muốn chọn một cái gì đó mà các lập trình viên Java đặc biệt quan tâm. Cách dễ nhất là nói về những thứ đó trong thư viện Java mà tôi đã nhúng tay vào bằng cách này hay cách khác. 

Alexey: Chúng tôi cho rằng khán giả trên Hydra đã biết điều gì đó về lập trình không khóa và có lẽ đã có một số kinh nghiệm trong lĩnh vực này. Nhưng đây chỉ là giả định; tình hình sẽ trở nên rõ ràng hơn tại hội nghị. Dù sao, cảm ơn vì thời gian của bạn. Tôi chắc chắn cuộc phỏng vấn sẽ rất thú vị đối với độc giả của chúng tôi. Cảm ơn rất nhiều!

Виталий: Cảm ơn. 

Michael: Tôi rất vui được gặp bạn ở St. Petersburg. 

Alexey: Chúng tôi cũng vậy, chúng tôi có một thành phố xinh đẹp. Bạn đã bao giờ đến đây chưa?

Michael: Không, tôi chưa bao giờ đến Nga cả. Nhưng St. Petersburg luôn nằm trong danh sách những nơi tôi chưa đến nhưng là nơi tôi rất muốn đến nên tôi rất vui khi nhận được lời mời. 

Alexey: Nhân tiện, chúng tôi sẽ có một chương trình du ngoạn dành cho các diễn giả. Cảm ơn bạn rất nhiều vì cuộc phỏng vấn và chúc bạn một ngày tốt lành!

Bạn có thể tiếp tục cuộc trò chuyện của mình với Michael tại hội nghị Hydra 2019, sẽ được tổ chức vào ngày 11-12 tháng 2019 năm XNUMX tại St. Petersburg. Anh ấy sẽ đến với một bản báo cáo "Cấu trúc dữ liệu kép". Có thể mua vé trên trang web chính thức.

Nguồn: www.habr.com

Thêm một lời nhận xét