2010-10-24 33 views
27

Tôi đã nhìn thấy đối số này ở một vài nơi, và bây giờ, gần đây tôi đã nhìn thấy nó một lần nữa trên một bài đăng reddit. Đây không phải là ngọn lửa chống lại bất kỳ ngôn ngữ nào trong hai ngôn ngữ này. Tôi chỉ bối rối tại sao có danh tiếng xấu này về python không thể mở rộng được.
Tôi là một anh chàng python và bây giờ tôi bắt đầu với Java và tôi chỉ muốn hiểu những gì làm cho Java có khả năng mở rộng và nếu thiết lập python mà tôi có trong tâm trí là một cách tốt để mở rộng các ứng dụng python lớn.Tại sao mọi người nói rằng Java có khả năng mở rộng hơn so với python?

Bây giờ trở lại ý tưởng của tôi về mở rộng ứng dụng Python. Giả sử bạn viết mã bằng Django. Django chạy các ứng dụng của nó ở chế độ fastcgi. Vì vậy, những gì nếu bạn có một máy chủ Nginx phía trước và đằng sau nó như nhiều máy chủ khác khi cần thiết mà mỗi sẽ chạy ứng dụng Django của bạn trong chế độ fastcgi. Máy chủ Nginx phía trước sẽ tải cân bằng giữa các máy chủ chạy nhanh Django fastcgi của bạn. Django cũng hỗ trợ nhiều cơ sở dữ liệu để bạn có thể ghi vào một DB chính và sau đó đọc từ nhiều nô lệ, một lần nữa để cân bằng tải. Ném một máy chủ memcached vào hỗn hợp này và có bạn đi bạn có khả năng mở rộng. Phải không?

Đây có phải là thiết lập khả thi không? Java làm gì tốt hơn? Làm thế nào để bạn mở rộng một ứng dụng Java?

+0

Điều này có thể sẽ bị đóng vì bất kỳ lúc nào bạn thảo luận về các vấn đề tiềm năng với ngôn ngữ động, cảm giác bị tổn thương rất nhanh. Tuy nhiên, hãy nhớ, ý tưởng của bạn về việc mở rộng quy mô python có thể là tốt nhưng điều đó không nói bất cứ điều gì về việc liệu Java có khả năng mở rộng hơn hay không. Ngoài ra, một điều khác cần xem xét, nếu một nền tảng có thể mở rộng quy mô "tương tự tốt" với một nền tảng khác nhưng yêu cầu thiết lập phức tạp hơn nhiều, nó có thực sự mở rộng hơn không? – BobbyShaftoe

+4

"cảm xúc bị tổn thương rất nhanh". Tôi nghĩ rằng một số người nên ngừng uống quá nhiều cà phê và tập trung vào những điều quan trọng hơn trong cuộc sống. Nó chỉ là một ngôn ngữ chết tiệt ... –

+4

Khả năng mở rộng có thể có nghĩa là nhiều thứ. Nếu bạn nói điều gì đó không quy mô, bạn phải nói theo cách nào, và cũng nói tại sao nó lại quan trọng. C + + có thể mở rộng đến 100K thread và Java có thể mở rộng tới 10K threads, nhưng nếu bạn chỉ cần 10s thread thì có vấn đề gì không? –

Trả lời

21

Khả năng mở rộng là thuật ngữ quá tải trong những ngày này. Các nhận xét có thể đề cập đến khả năng mở rộng theo chiều dọc trong quy trình.

Python có khóa thông dịch toàn cầu (GIL) giới hạn nghiêm trọng khả năng mở rộng lên nhiều chuỗi. Nó phát hành nó khi gọi mã nguồn gốc (trả lời nó khi native trả về), nhưng điều này vẫn đòi hỏi thiết kế cẩn thận khi cố gắng viết phần mềm có thể mở rộng bằng Python.

+8

Điều đó nói rằng, một số triển khai như Stackless là tốt hơn trong khía cạnh luồng - tốt hơn nhiều. Ví dụ, Stackless Python được sử dụng bởi MMORPG Eve Online. –

+4

Nhưng cần lưu ý rằng Stackless Python không loại bỏ GIL. Nó có thể làm cho lập trình đồng thời dễ dàng hơn nhưng nó không cho phép thực thi song song. PyPy và Unladen Swallow cả hai đều loại bỏ GIL là một trong những mục tiêu của họ, nhưng không (như tôi nhớ lại) là có được nêu ra. IronPython và Jython là những đối thủ nghiêm túc nhất, hiện thời không phải là GIL mà tôi biết. –

+1

@Tim: Stackless là đơn luồng. Nó mô phỏng các chủ đề để cho phép hành vi đồng thời cao, như tất cả mọi thứ dài là I/O-ràng buộc. Nhưng nếu bạn chạy một khối lượng công việc CPU bị ràng buộc thông qua Stackless trên một hệ thống 8 lõi, Bạn sẽ không thấy nhiều hơn khoảng 12% sử dụng. –

3

Nếu không tham gia vào một loạt quảng cáo, hãy xem xét cách Python xử lý các ứng dụng đa luồng so với Java? Ví dụ, những gì các khóa toàn cầu được đặt ra trong cả hai ngôn ngữ làm tổn thương concurrency (gợi ý, GIL của Python - Global Interpreter Lock)?

12

Mặc dù tôi không đồng ý với tuyên bố, tôi cho rằng họ nghĩ Java có thể mở rộng hơn vì nó chạy nhanh hơn lot. JVM rất hiệu quả (ngoại trừ việc sử dụng bộ nhớ). Ngoài ra GIL của Python (Global Interpreter Lock) không cho phép luồng "thực", trong khi Java không có GIL và có đa luồng thực.

+0

Bạn có ý nghĩa gì với "JVM"? Nó chỉ là một spec có thể được thực hiện theo những cách rất khác nhau, dẫn đến kết quả hiệu suất rất khác nhau. Không cố gắng để được một tinh ranh, thực sự chỉ tò mò. –

+3

HotSpot, đó là những gì hầu hết mọi người sử dụng. –

+4

Nhưng Python chạy trên JVM, và do đó rõ ràng là trên HotSpot, vì vậy nếu khả năng mở rộng là tất cả về HotSpot, và cả hai ngôn ngữ đều chạy trên HotSpot thì tại sao chính xác lại là một "khả năng mở rộng" hơn? –

1

Hmmm - có thể mở rộng có thể có nghĩa là nhiều thứ - có thể mở rộng bằng kiến ​​trúc phân tán, có thể mở rộng theo tốc độ? Trên mặt trước tốc độ, Java thường có thể xử lý các lệnh nhanh hơn python - cho đúng loại vấn đề, nhanh hơn nhiều (tôi đoán lý do chính là Java được biên dịch trong khi Python được hiểu). Từ quan điểm đó, Java thường có thể làm được nhiều hơn với ít hơn, và do đó có khả năng mở rộng hơn.

Tôi đang giới thiệu thông tin thử nghiệm nguồn của mình về hai nguồn; http://mrpointy.wordpress.com/2007/11/06/java-vs-python-performance/http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java-python-ruby-jython-jruby-groovy/

+2

Trên mặt trước số, bạn chính xác về mặt kỹ thuật. Ngoại trừ điều đó, bất kỳ việc ghép số nghiêm trọng nào trong Python được thực hiện bằng cách sử dụng thư viện [numpy] (http://numpy.scipy.org/), dựa trên C/Fortran và thường hoạt động tốt hơn các thư viện Java. –

+0

Xin lỗi, khi tôi nói số crunching, tôi không cụ thể đề cập đến đại số tuyến tính và muốn. Tôi sẽ nói lại. – Brabster

+1

1) Python không được giải thích, nó được biên dịch. Đó là những gì downvote là về. 2) hầu hết các crunching số làm giảm đại số tuyến tính "và như thế." – aaronasterling

3

Tôi nghĩ rằng bài viết này tóm tắt nhiều tranh luận về mở rộng quy mô và các ngôn ngữ động:

http://blogs.tedneward.com/2008/01/24/Can+Dynamic+Languages+Scale.aspx

Nó đáng chú ý nghĩa của nó đối với hai nhân rộng ...

  1. Quy mô dự án, như trong dòng-of-mã (LOC) xử lý Dung tích
  2. , như trong "nó cần phải mở rộng đến 100.000 yêu cầu mỗi giây"

Một lập luận thường sử dụng khoảng bất kỳ quy mô ngôn ngữ động nào là khi mã-base phát triển trở nên khó khăn hơn để cấu trúc lại nó mà không cần hỗ trợ IDE. Do thiếu thông tin loại tại thời điểm biên dịch nên việc hỗ trợ này thường không thể thực hiện bằng ngôn ngữ động.

+0

Tôi đang gọi nhảm nhí về điều này. Các IDE tái cấu trúc tự động được phát minh * bằng ngôn ngữ động và hỗ trợ tái cấu trúc trong các IDE ngôn ngữ động như VisualWorks và co. vẫn là con đường phía trước của bất cứ điều gì tôi đã thấy cho các ngôn ngữ gõ tĩnh. –

+0

Không cần phải nguyền rủa! - Tôi là một fan hâm mộ lớn của các ngôn ngữ động nhưng thực tế là nhiều loại tái cấu trúc lại khó thực hiện hơn nhiều trong các ngôn ngữ động. http://beust.com/weblog/2006/10/01/dynamic-language-refactoring-ide-pick-one/ – Pablojim

0

Tôi phát điên khi thấy các đối số như thế này. Không phải vì tôi nhận được tất cả butthurt về hận thù harshing của tôi Python êm dịu, nhưng vì với tâm trí của tôi, nói rằng "X không quy mô" là vô nghĩa. Nó là cần thiết để xác định một kích thước, ít nhất là.

Mọi người không muốn làm điều này, vì nó thường cho thấy thực tế rằng họ không có một xử lý tốt về vấn đề mà họ đang nói với sự tự tin về. Khóa thông dịch toàn cầu là một điểm tiếp xúc tốt ở đây: các luồng không phải là cách duy nhất để thực hiện các hoạt động đồng thời.

Các vấn đề liên quan