bao nhiêu CPU là cần thiết trước khi Erlang là nhanh hơn so với đơn luồng Java

Question

Tôi hiện đang sử dụng Java, tôi đã đọc rất nhiều về Erlang trên mạng, và tôi có 2 câu hỏi lớn:

1. thế nào chậm hơn nhiều (nếu có) sẽ Erlang trên Java đơn giản?
   Tôi giả định ở đây rằng Java sẽ nhanh hơn từ shootout benchmarks trên mạng (Erlang không làm tốt điều đó). Vì vậy, có bao nhiêu CPU nữa tôi sẽ cần phải làm cho Erlang tỏa sáng trên Java đơn luồng (trong tình hình cụ thể của tôi, đưa ra dưới đây)?

2. Sau khi đọc xung quanh về Erlang trong một thời gian tôi đã nhấn vào một số ý kiến ​​/ bài viết nói rằng hầu hết các hệ thống Erlang lớn chứa một số lượng tốt của C/C++.
   Đây có phải là lý do tốc độ (giả định của tôi) hay cái gì khác không? tức là tại sao điều này lại được yêu cầu?

Tôi đã đọc về số lượng bộ vi xử lý trong hầu hết các máy móc và mô hình luồng khó (tôi đồng ý) nhưng tôi đang tìm hiểu khi nào "dòng" sẽ bị gạch chéo để tôi có thể thay đổi ngôn ngữ/mô hình vào đúng thời điểm.

Một chút nền/ngữ cảnh:
Tôi đang làm việc phía máy chủ trên các dịch vụ Java có liên kết CPU và dễ dàng thực hiện song song. Điều này là do, thông thường, một bản cập nhật đến (thông qua TCP) kích hoạt thay đổi cho nhiều (100s) kết quả đầu ra.

Các tính toán thường khá đơn giản (vài vòng, chỉ cần nhiều số học) và các đầu vào đang đến khá nhanh (100/s).

Hiện tại chúng tôi đang chạy trên 4 máy CPU và chạy nhiều dịch vụ trên mỗi máy (vì vậy đa luồng khá đơn giản và Java dường như chạy nhanh hơn mà không cần khối đồng bộ, v.v. Bây giờ có một sự thúc đẩy mạnh mẽ về tốc độ và bây giờ chúng ta có thể truy cập tới 24 máy xử lý (cho mỗi tiến trình nếu cần) vì vậy tôi tự hỏi làm thế nào tốt nhất để tiến hành - đa luồng Java đa luồng hoặc một cái gì đó dễ dàng hơn để mã hóa, như Erlang.

Answer 1

vì đây là tải khối lượng lớn và bạn đã thực hiện công việc tách mã thành các quy trình dịch vụ riêng biệt, bạn sẽ không thu được nhiều từ Erlang. Công việc của bạn dường như phù hợp với Java một cách thoải mái. Erlang rất tốt trong các giao dịch nhỏ - chẳng hạn như chuyển đổi thư hoặc phục vụ các trang web tĩnh hoặc đơn giản. Không - tại doanh nghiệp ở mức độ crunching hoặc khối lượng công việc cơ sở dữ liệu.

Tuy nhiên, bạn có thể xây dựng trên thư viện số bên ngoài và cơ sở dữ liệu và sử dụng Erlang là MSG switch: D đó là những gì chiếc ghế-db không: P

- chỉnh sửa -

1. Nếu bạn di chuyển các phép tính số học của bạn vào một trình điều khiển Erlang async-IO erlang sẽ chỉ tốt như ngôn ngữ bắn ra công cụ - nhưng với 24 cpu có lẽ nó sẽ không quan trọng mà nhiều; cơ sở dữ liệu erlang là thủ tục và thefore khá nhanh - điều này có thể được khai thác trong ứng dụng của bạn cập nhật 100 thực thể trên mỗi giao dịch.

2. Hệ thống thời gian chạy erlang cần phải là kết hợp của C và C++ vì (a) trình giả lập erlang được viết bằng C/C++ (bạn phải bắt đầu từ đâu đó), (b) bạn phải nói chuyện với hạt nhân làm async tập tin io và mạng io, và (c) các phần nhất định của hệ thống cần phải phồng rộp nhanh --eg, phần phụ của hệ thống cơ sở dữ liệu (mất trí nhớ).

- thảo luận -

với 24 CPU trong 6 lõi * 4 CPU topo sử dụng một khe bộ nhớ chia sẻ - bạn có 4 đơn vị NUMA (CPU) và một bộ nhớ trung tâm. Bạn cần phải khôn ngoan về mô hình, cách tiếp cận đa quy trình chia sẻ không có gì có thể giết chết bộ nhớ của bạn.

Để giải quyết vấn đề này, bạn cần tạo 4 quy trình với 6 luồng xử lý và liên kết từng chuỗi xử lý với lõi tương ứng trong CPU tương ứng. 6 chủ đề này cần phải hợp tác đa luồng - Erlang và Lua có điều này một cách bẩm sinh - Erlang làm điều đó một cách cứng rắn vì nó có một bộ lập lịch toàn diện như là một phần của thời gian chạy mà nó có thể sử dụng để tạo ra nhiều các quy trình như bạn muốn.

Bây giờ nếu bạn phân vùng nhiệm vụ của bạn trong 4 quy trình (1 trên CPU vật lý), bạn sẽ là người hạnh phúc, tuy nhiên bạn đang chạy 4 công việc (có lẽ vì nhiều lý do) của Java VM. Vấn đề cần được giải quyết với khả năng cắt và xúc xắc vấn đề tốt hơn.

Trong hệ thống Erlang OTP, nó được thiết kế cho các hệ thống mạng dự phòng mạnh mẽ, nhưng bây giờ nó đang di chuyển về cùng một CPU NUMA-esque của CPU. Nó đã có bộ giả lập SMP kick-ass và nó sẽ sớm trở thành NUMA. Với mô hình lập trình này, bạn có cơ hội tốt hơn để bão hòa các máy chủ mạnh mẽ của mình mà không phải giết xe buýt của bạn.

Có lẽ cuộc thảo luận này đã được lý thuyết; tuy nhiên, khi bạn nhận được cấu trúc liên kết 8x8 hoặc 16x8, bạn cũng sẽ sẵn sàng cho nó. Vì vậy, câu trả lời của tôi là khi bạn có nhiều hơn thì 2 - hiện đại - CPU vật lý trên mainboard của bạn, bạn có lẽ nên xem xét một mô hình lập trình tốt hơn.

Ví dụ về sản phẩm chính sau cuộc thảo luận tại đây: Microsoft's SQL Server is CPU-Level NUMA-aware in the SQL-OS layer mà trên đó công cụ cơ sở dữ liệu được tạo.

Answer 2

Bạn đã so sánh chi phí phần cứng mới so với chi phí đào tạo nhân viên trong Erlang và kiến ​​trúc lại phần mềm của bạn bằng ngôn ngữ mới?

Tôi sẽ không đánh giá thấp chi phí bồi dưỡng bản thân (hoặc những người khác) và chi phí thuê người giao tiếp trong Erlang (những người sẽ là số nhiều hơn khó tìm hơn người Java). Máy chủ rõ ràng là chi phí về chi phí lưu trữ của họ/điện/bảo trì, vv, nhưng chúng vẫn rẻ hơn rất nhiều so với nhân viên có trình độ. Nếu bạn có thể tiến bộ và duy trì khả năng mở rộng trong khi sử dụng các kỹ năng hiện tại của mình, tôi nghi ngờ đó là phương pháp thực dụng nhất.

Answer 3

Nếu bạn nhận được 100 mỗi giây nhưng họ mất 100 mỗi lần, làm thế nào để nó có thể tiếp tục? Có lẽ tôi đang hiểu sai phần đó, nhưng dù sao đi nữa, trừ khi nó là hàng ngàn hoặc hàng triệu yêu cầu thì mã đồng bộ hóa của bạn sẽ không mất nhiều thời gian. Nếu có, bạn đang làm điều gì đó sai, có thể khóa trong khi bạn thực hiện toàn bộ công việc hoặc một cái gì đó.

Đối với mã đa luồng, việc chuyển sang ngôn ngữ cấp cao hơn thậm chí có thể là một sai lầm. Ngay cả khi bạn viết phần ứng dụng trong erlang hoặc bất kể đa luồng có lẽ nên ở trong Java hoặc di chuyển đến C++ nếu hiệu năng thực sự trở thành một vấn đề.

Answer 4

Câu hỏi về tốc độ khi nói đến ngôn ngữ lập trình phức tạp như một câu hỏi có thể nhận được. Những người ủng hộ Java có thể trỏ tới rất nhiều lĩnh vực và tuyên bố là nhanh nhất và chúng sẽ chính xác 100%. Những người ủng hộ Ruby/Python chỉ vào một tập hợp các tham số khác nhau và yêu cầu được nhanh hơn và chúng cũng chính xác. Những người ủng hộ Erlang sau đó chỉ vào các kết nối đồng thời và yêu cầu phải nhanh nhất khi xử lý hàng trăm hoặc hàng nghìn kết nối đồng thời hoặc tính toán và cũng sẽ không sai.

Nhìn vào mô tả cơ bản của dự án được đề cập, có vẻ như với tôi rằng Erlang sẽ hoàn toàn phù hợp với nhu cầu của bạn. Không biết chi tiết tôi sẽ nói rằng điều này thực sự sẽ là một chương trình Erlang đơn giản darn và có thể được thực hiện trong một thời gian rất ngắn.

Answer 5

Tùy thuộc vào một số yếu tố. Câu trả lời nhanh là bạn sẽ cần phải chuẩn mỗi chương trình differnt để hiểu nơi mà watermark quiescence là.

Dưới đây là một số trong những khía cạnh có liên quan có thể tác động mà tỷ lệ lợi ích:

1) Dependencies tính toán: nếu luồng logic có nhiều phụ thuộc vào nguồn lực bên ngoài (DBMS, truy cập đĩa, mạng). Số lượng phụ thuộc tính toán càng cao trong quá trình xử lý đồng thời càng cao, lợi ích của việc áp dụng nền tảng tính toán phân tán cao hơn như erlang càng cao.

2) Nguyên tử lưu lượng logic: nếu chương trình của bạn phải mất một lượng lớn thời gian tính toán trên một điều khiển luồng đồng bộ tuần tự và không thể chia nhỏ. Lớn hơn là mã nguyên tử của bạn, ít hơn nó có thể được chia thành các dòng chảy CPU.

3) Chia sẻ trạng thái trên cao: lớn hơn lượng dữ liệu phải phân phối trên nhiều chức năng khác nhau, chi phí cần thiết để truyền và nhận trạng thái càng cao. Nói cách khác, nếu bạn gửi một lượng lớn dữ liệu lặp đi lặp lại mà không có vùng lưu trữ chung được chia sẻ, lợi ích sẽ giảm, mặc dù điều này có các cách tiếp cận khác nhau tùy thuộc vào các mẫu lập trình được chấp nhận.

Do đó, với các khả năng và biến thể lớn dựa trên các tiêu chí như trên, không thể có ước tính chung cho tất cả các trường hợp.