Tại sao nhóm tại LMAX sử dụng Java và thiết kế kiến ​​trúc để tránh GC bằng mọi giá?

Tại sao nhóm tại LMAX thiết kế Trình phân tích LMAX trong Java nhưng tất cả các điểm thiết kế của họ để giảm thiểu việc sử dụng GC? Nếu một người không muốn chạy GC thì tại sao lại sử dụng ngôn ngữ được thu gom rác?

Tối ưu hóa của họ, mức độ kiến ​​thức phần cứng và suy nghĩ họ đặt ra chỉ là tuyệt vời nhưng tại sao Java?

Tôi không chống lại Java hay bất cứ điều gì, nhưng tại sao lại là ngôn ngữ GC? Tại sao không sử dụng một cái gì đó như D hoặc bất kỳ ngôn ngữ nào khác mà không có GC nhưng cho phép mã hiệu quả? Có phải nhóm đã quen thuộc nhất với Java hay Java có một số lợi thế duy nhất mà tôi không thấy?

Nói rằng họ phát triển nó bằng cách sử dụng D với quản lý bộ nhớ thủ công, điều gì sẽ là sự khác biệt? Họ sẽ phải nghĩ mức độ thấp (mà họ đã có), nhưng họ có thể đạt được hiệu suất tốt nhất trong hệ thống như bản địa của nó.

Bởi vì có một sự khác biệt rất lớn giữa tối ưu hóa hiệu suất và tắt hoàn toàn an toàn

Bằng cách giảm số lượng GC, khung của họ phản ứng nhanh hơn và có thể chạy (có lẽ) nhanh hơn. Bây giờ, tối ưu hóa cho trình thu gom rác không có nghĩa là họ không bao giờ thực hiện việc thu gom rác. Nó chỉ có nghĩa là họ làm điều đó ít thường xuyên hơn, và khi họ làm điều đó, nó chạy rất nhanh. Những loại tối ưu hóa bao gồm:

1. Giảm thiểu số lượng vật thể di chuyển đến một không gian sống sót (nghĩa là đã sống sót ít nhất một bộ sưu tập rác) bằng cách sử dụng các vật thể vứt bỏ nhỏ. Đối tượng di chuyển đến không gian sống sót khó thu thập hơn và bộ sưu tập rác ở đây đôi khi ngụ ý đóng băng toàn bộ JVM.
2. Đừng phân bổ quá nhiều đối tượng để bắt đầu. Điều này có thể gây tác dụng ngược nếu bạn không cẩn thận, vì các đối tượng thế hệ trẻ có giá siêu rẻ để phân bổ và thu thập.
3. Đảm bảo rằng đối tượng mới trỏ đến đối tượng cũ (chứ không phải ngược lại) để đối tượng trẻ dễ thu thập, vì không có tham chiếu nào đến chúng sẽ khiến chúng bị giữ

Khi bạn điều chỉnh hiệu suất, bạn thường điều chỉnh một số "điểm nóng" rất cụ thể trong khi bỏ qua mã không chạy thường xuyên. Nếu bạn làm điều đó trong Java, bạn có thể để trình thu gom rác vẫn xử lý các góc tối đó (vì nó sẽ không tạo ra nhiều khác biệt) trong khi tối ưu hóa rất cẩn thận cho khu vực chạy trong một vòng lặp chặt chẽ. Vì vậy, bạn có thể chọn nơi bạn tối ưu hóa và nơi bạn không, và do đó bạn có thể tập trung nỗ lực của mình vào nơi quan trọng.

Bây giờ, nếu bạn tắt bộ sưu tập rác hoàn toàn, thì bạn không thể chọn. Bạn phải vứt bỏ thủ công mọi đối tượng, bao giờ hết. Phương pháp đó được gọi nhiều nhất một lần mỗi ngày? Trong Java, bạn có thể để nó như vậy, vì tác động hiệu năng của nó là không đáng kể (có thể ổn khi để cho một GC đầy đủ xảy ra mỗi tháng). Trong C ++, bạn vẫn đang rò rỉ tài nguyên, vì vậy bạn phải cẩn thận ngay cả phương thức tối nghĩa đó. Vì vậy, bạn phải trả giá cho việc quản lý tài nguyên trong mọi phần, một phần của ứng dụng của bạn, trong khi ở Java, bạn có thể tập trung.

Nhưng nó trở nên tồi tệ hơn.

Điều gì nếu bạn có một lỗi, giả sử trong một góc tối của ứng dụng của bạn chỉ được truy cập vào thứ Hai vào một ngày trăng tròn? Java có đảm bảo an toàn mạnh mẽ. Có rất ít hoặc không có "hành vi không xác định". Nếu bạn sử dụng sai, một ngoại lệ sẽ bị ném, chương trình của bạn dừng lại và không xảy ra hỏng dữ liệu. Vì vậy, bạn khá chắc chắn rằng không có gì sai có thể xảy ra mà bạn không nhận ra.

Nhưng trong một cái gì đó như D, bạn có thể có quyền truy cập con trỏ xấu hoặc tràn bộ đệm và bạn có thể làm hỏng bộ nhớ của mình, nhưng chương trình của bạn sẽ không biết (bạn đã tắt an toàn, nhớ không?) Và sẽ tiếp tục chạy không đúng dữ liệu, và làm một số điều khá khó chịu và làm hỏng dữ liệu của bạn, và bạn không biết, và khi càng nhiều tham nhũng xảy ra, dữ liệu của bạn càng ngày càng sai, và sau đó đột nhiên nó bị hỏng, và đó là một ứng dụng quan trọng trong cuộc sống, và Một số lỗi đã xảy ra trong tính toán của một tên lửa, và do đó nó không hoạt động, và tên lửa phát nổ, và ai đó chết, và công ty của bạn ở trên trang nhất của mỗi tờ báo và ông chủ của bạn chỉ tay bạn nói rằng "Bạn là kỹ sư gợi ý chúng tôi sử dụng D để tối ưu hóa hiệu suất, tại sao bạn không nghĩ đến sự an toàn?"Và đó là lỗi của bạn. Bạn đã giết những người đó bằng nỗ lực ngu ngốc của mình trong hiệu suất.

OK, ok, hầu hết thời gian nó ít kịch tính hơn thế. Nhưng ngay cả một ứng dụng quan trọng trong kinh doanh hoặc chỉ là một ứng dụng GPS hoặc giả sử, một trang web chăm sóc sức khỏe của chính phủ có thể mang lại một số hậu quả khá tiêu cực nếu bạn gặp lỗi. Sử dụng một ngôn ngữ ngăn chặn chúng hoàn toàn hoặc thất bại nhanh khi chúng xảy ra thường là một ý tưởng rất tốt.

Có một chi phí để tắt một sự an toàn. Về bản địa không phải lúc nào cũng có ý nghĩa. Đôi khi nó đơn giản và an toàn hơn nhiều khi chỉ cần tối ưu hóa một chút ngôn ngữ an toàn để sử dụng tất cả ngôn ngữ mà bạn có thể tự bắn vào chân mình. Tính chính xác và an toàn trong rất nhiều trường hợp là một vài nano giây mà bạn đã loại bỏ bằng cách loại bỏ hoàn toàn GC. Disruptor có thể được sử dụng trong những tình huống đó, vì vậy tôi nghĩ LMAX-Exchange đã thực hiện cuộc gọi đúng.

Nhưng những gì về D nói riêng? Bạn có một GC nếu bạn muốn cho các góc tối và tập hợp con SafeD (mà tôi không biết trước khi chỉnh sửa) xóa hành vi không xác định (nếu bạn nhớ sử dụng nó!).

Vâng, trong trường hợp đó là một câu hỏi đơn giản về sự trưởng thành. Hệ sinh thái Java có đầy đủ các công cụ được viết tốt và các thư viện trưởng thành (tốt hơn để phát triển). Nhiều nhà phát triển biết Java hơn D (tốt hơn để bảo trì). Tìm kiếm một ngôn ngữ mới và không phổ biến cho một thứ quan trọng như ứng dụng tài chính sẽ không phải là một ý tưởng hay. Với ngôn ngữ ít được biết đến, nếu bạn gặp vấn đề, ít người có thể giúp bạn và các thư viện bạn tìm thấy có xu hướng có nhiều lỗi hơn do chúng tiếp xúc với ít người hơn.

Vì vậy, điểm cuối cùng của tôi vẫn là: nếu bạn muốn tránh các vấn đề với hậu quả thảm khốc, hãy kiên trì với các lựa chọn an toàn. Tại thời điểm này trong cuộc đời của D, khách hàng của nó là những người khởi nghiệp nhỏ sẵn sàng chấp nhận rủi ro điên rồ. Nếu một vấn đề có thể tốn hàng triệu đô la, tốt hơn hết bạn nên tiếp tục theo đường cong chuông đổi mới .

Có vẻ như lý do nó được viết bằng Java là vì họ có chuyên môn về Java và có lẽ nó đã được viết (mặc dù nó vẫn đang được phát triển tích cực) trước khi C ++ có hành động cùng với C ++ 0x / 11.

Mã của họ thực sự chỉ là Java theo tên, họ sử dụng sun.misc.Unsafe khá nhiều loại đánh bại quan điểm của Java và sự an toàn được cho là mang lại. Tôi đã viết một cổng C ++ của Disruptor và nó vượt trội hơn mã Java mà họ gửi (Tôi không mất nhiều thời gian để điều chỉnh JVM).

Điều đó nói rằng, các nguyên tắc mà người gây rối tuân theo không phải là ngôn ngữ cụ thể, ví dụ: Đừng mong đợi mã C ++ có độ trễ thấp mà allocs hoặc giải phóng khỏi heap.

Câu hỏi này nêu một tiền đề không chính xác là thực tế, sau đó đưa ra lập luận về tiền đề không chính xác đó.

Hãy đi sâu vào vấn đề này .. "tất cả các điểm thiết kế của họ để giảm thiểu việc sử dụng GC" - đơn giản là không đúng. Sự đổi mới trong kẻ gây rối không liên quan nhiều đến GC. Kẻ gây rối thực hiện vì thiết kế của nó khéo léo xem xét cách thức các máy tính hiện đại hoạt động - thứ ít phổ biến hơn nhiều so với người ta tưởng. Xem bài nói chuyện của Cliff Click http://www.azulsystems.com/events/javaone_2009/session/2009_J1_HardwareCrashCference.pdf để thảo luận.

LMax là khách hàng của Azul. Tôi biết trước rằng với Azul GCs chỉ đơn giản là không phát hành - thậm chí với hàng đống 175GB.

Họ sẽ phải suy nghĩ cấp thấp

Ở trên làm cho một nửa câu trả lời bạn đang tìm kiếm. Bạn có thể tìm thấy một nửa khác để hoàn thành lý do không xa hơn trong blog LMAX :

Mặc dù rất hiệu quả, nó có thể dẫn đến một số lỗi vì nó rất dễ bị hỏng ...

Theo thừa nhận của các nhà phát triển LMAX, mã như thế có thể khá khó để phát triển, hiểu và gỡ lỗi - ngay cả trong Java. Đi xuống cấp độ thấp hơn nhiều so với nơi họ đang ở hiện tại sẽ chỉ làm trầm trọng thêm vấn đề này, như được chỉ ra trong bài viết trên Wikipedia về các ngôn ngữ lập trình cấp thấp :

Một chương trình được viết bằng ngôn ngữ cấp thấp có thể được thực hiện để chạy rất nhanh và với dung lượng bộ nhớ rất nhỏ; một chương trình tương đương trong một ngôn ngữ cấp cao sẽ nặng hơn. Các ngôn ngữ cấp thấp rất đơn giản, nhưng được coi là khó sử dụng, do nhiều chi tiết kỹ thuật phải được ghi nhớ .

Khi so sánh, một ngôn ngữ lập trình cấp cao tách biệt ngữ nghĩa thực thi của kiến ​​trúc máy tính khỏi đặc tả của chương trình, giúp đơn giản hóa việc phát triển ...

Nếu bạn sử dụng Java như một ngôn ngữ cú pháp và tránh các thư viện JDK của nó, nó có thể nhanh như một ngôn ngữ không được biên dịch. GC không phù hợp với các hệ thống thời gian thực, nhưng có thể phát triển các hệ thống trong Java mà không để lại bất kỳ rác nào. Kết quả là GC không bao giờ kích hoạt.

Chúng tôi tin rằng ngôn ngữ và nền tảng Java có nhiều lợi thế so với C / C ++ và chúng tôi đã phát triển và đánh giá một số thành phần Java có độ trễ cực thấp để chứng minh điều đó. Chúng ta nói về các kỹ thuật để làm như vậy trong bài viết này: Phát triển Java mà không cần GC .

LMAX là một Thư viện nhắn tin liên chủ đề hiệu suất cao.

Để có ích, người khác phải viết mã để nhận từng luồng để thực hiện công việc hữu ích. Cho rằng mã rất có thể là bằng Java hoặc C # và sau đó có rất ít lựa chọn ngôn ngữ có giao diện tốt với chúng.

Sử dụng C hoặc C ++ không phải là một lựa chọn tốt trừ khi bạn muốn giới hạn người dùng của mình trong một HĐH duy nhất, vì không có mô hình luồng nào được xác định trong chúng.

Java là tiêu chuẩn cho rất nhiều sự phát triển phần mềm ngày nay, vì vậy trừ khi bạn có lý do chính đáng khác, nó có xu hướng là lựa chọn tốt nhất. (Khi ở Rôma, hãy làm như người Rôma…)

Viết phần mềm hiệu suất cao bằng Java (hoặc C #) thường được thực hiện để chứng minh một điểm điểm