パフォーマンスとJavaの相互運用性について:ClojureとScala


82

私はすでにClojure対Scalaのさまざまな説明を読みましたが、どちらにも場所があることに気づきました。ClojureとScalaの両方を比較する場合、完全な説明が得られていない考慮事項がいくつかあります。

1.)2つの言語のどちらが一般的に速いですか?これは言語機能ごとに異なることは理解していますが、パフォーマンスの一般的な評価が役立つでしょう。例:Python辞書は本当に高速であることを私は知っています。しかし、全体として、Javaよりもはるかに遅い言語です。Clojureを使用して、この問題に遭遇したくありません。

2.)Javaとの相互運用性はどうですか?私がこれまで読んだことは、Scalaにはネイティブコレクションタイプがあるため、大規模なJavaコードベースと統合するのが少し不器用であるのに対し、ClojureはJavaクラスと相互運用するための単純な反復可能/反復子中心の方法に従います。これについてこれ以上の考え/詳細はありますか?

最終的に、それがclojureとscalaの間の十分に近い引き分けである場合、私は両方を試すかもしれません。Clojureの1つは、言語が非常に単純に見えることです。しかし、繰り返しになりますが、Scalaには非常に柔軟な型システムがあります。しかし、私はScalaが高速であることを知っています(複数の個人アカウントに基づく)。したがって、Clojureの速度が大幅に遅い場合は、後でではなく早く知りたいと思います。


1
Clojure 1.2を使用すると、ClojureはオーバーヘッドなしでJavaを呼び出すことができます。assembla.com/wiki/show/clojure/Datatypesassembla.com/wiki/show/clojure/New_newを見てください。これは、ClojureがJavaに近いことを望んでいるが、Clojureに実装されているために行われます。
nickik 2010

回答:


73

どちらの言語でも十分に速いと思います。PythonとJavaを比較するとき、速度の違いについて言語を非難するのは少し不合理に思えます。JavaはJITでコンパイルされます(モバイルデバイス*を除く)が、Pythonは解釈されます。両方がバイトコードを使用しているからといって、実装がリモートで同等のパフォーマンスを発揮することを意味するわけではありません。ただし、ScalaとClojureはどちらもJVM言語であるため、同様のパフォーマンスが得られるはずです。

ScalaにはClojureに比べていくつかの実装上の利点があり、多少高いパフォーマンスが期待できます。Scalaの静的型付けは通常、Clojureのダック型付けよりも速度が優れていますが、Clojure型ヒントをサポートしており、コードを大幅に高速化できます。おそらく、通常のScalaは通常のClojureよりも高速ですが、ボトルネックを最適化するだけで済みます。プログラムの実行時間のほとんどは、少量の実際のコードによって生成されます。

Javaとの相互運用に関しては、ScalaはJavaに近いですが、両方の言語がうまく相互運用できると確信しています。ではClojureのプログラミングスチュアートHallowayが書き込みを行う:「[あなたがアクセスすることができます]あなたはJavaコードから達することができる何かを。」。

そして、Scalaの作者であるMartin OderskySunのJavaコンパイラーを書いたので、Scala側にもボールがドロップされていないと思います。:-)

私はRubyも好きですが、2つのより良い言語を選ぶのは難しいでしょう。なぜどれを試すのか心配なのですか?両方試してみませんか?Scalaは「次のJava」になる可能性が高いですが、Lispが50年以上そうしなかった後にようやく離陸することは想像しがたいです。しかし、Lispが独自の抽象化レベルにあることは明らかであり、Clojureはかなり単純なので、Scala + Clojureは単なる(かなり複雑な)Scalaよりもそれほど難しくはなく、喜んでいただけると思います。それ。

そして、そのことについては、彼らは相互運用しています...

* dalvik(androidのJVM)は、2010年に2.2バージョンでJITコンパイラを取得しました


6
ええと。さて、すべての洞察に感謝します。最初は、1つだけ選んで実行したいモードでした。しかし、どういうわけか、両方を使用して相互運用できるとは思いもしませんでした。だから、おそらく私は両方を選んで、彼らと一緒に早歩きをします:-)
Ryan Delucchi 2009年

7
そして、私にはLISPの「ソフトスポット」が少しあるので、Clojureがparethesitisに苦しんでいるという事実は私を怖がらせるのに十分ではないことを付け加えたいと思います。
Ryan Delucchi 2009年

8
JVMで記述された言語が最高速度で実行されるとは限りません。元のJRubyは、ソースコードではなく、JVMにコンパイルされたインタープリターであったため、パフォーマンスが非常に悪かった。言語もまた、責任がある可能性があります。静的言語はなど、動的な言語よりも、最適化するために、多くの場合、容易です型付け
ビル・K

7
-1「ScalaとClojureはどちらもJVM言語であるため、同様のパフォーマンスが必要です」はまったく意味がありません。Javaのような静的言語との相互運用性を維持する必要がある動的言語は、常にはるかに低速です(オーバーロードには莫大なコストがかかり、タイプヒントではすべての問題が解決されないなど)
julx 2011

4
@ julkiewicz-動的言語が常にはるかに遅いというのは事実ではありません。それはあなたのコンパイラが問題のコードを最適化するまともな仕事をすることができるかどうかに依存します。たとえば、Clojureでは、Javaのパフォーマンスと完全に一致するJavaプリミティブを使用して算術演算を実行できます。同様に、型指定されたJavaオブジェクトでメソッドを呼び出すことは、Javaオブジェクトのメソッド呼び出しと同じくらい高速です。Clojureコンパイラーは、基本的に、同等のJavaコードのjavacと同じバイトコードを生成します。
mikera 2012

32

現在のJVMでは、動的型付け(リフレクション)に対するJVMのサポートが遅いため、静的に型付けされるという点でScalaには利点があります。実際、同じ手法で実装する必要のある1つのScala機能、構造型は、まさにこの理由で警告されることがよくあります。

また、Scalaは可変オブジェクトを問題なく受け入れ、一部のアルゴリズムは可変性を使用して実装する方が高速です。

ScalaとJavaはどちらも本質的にクラスベースの言語であるため、相互運用がより簡単になります。または、おそらく、よりシームレスに。JavaクラスはScalaのクラスであり、ScalaクラスはJavaのクラスです。ScalaのシングルトンまたはJavaの静的メンバーに関しては、特に物事が特定の方法で機能することを期待するフレームワークがある場合に、問題が発生する可能性があります。

だから私はこれら両方アカウントでScalaを使います。Clojureは、多くの点でより優れた言語であり、Scalaには(これまでのところ)存在しない非常に興味深い機能を確かに備えていますが、完全に機能することでそのようなメリットを享受できます。それを行うつもりなら、Clojureの方がおそらく優れています。そうでない場合は、おそらくScalaを使用する必要があります。


9
clojureの関数型プログラミング機能は、私がこの言語を検討している最も説得力のある理由です。機能的な方法で何かをコーディングしていない場合、とにかくJavaに埋め込まれたスクリプト言語に悩まされているのはなぜですか?私はすでにPythonを持っており、手っ取り早いタスクを実行できます。
Ryan Delucchi 2009年

9
次に、Clojureを使用します。
ダニエルC.ソブラル

「Javaに埋め込まれたスクリプト言語」。正当化してください。
jus12 2011

@ダニエル:混乱してすみません。ライアン・デルッキへのコメントを意味しました。Scalaは「Javaに埋め込まれたスクリプト言語」であり、私は購入していません。(彼がClojureを意味していない限り、私にはわかりません)。
jus12 2011

@ Jus12私は、彼がこれらの言語をJVMスクリプト言語として使用していることを意味すると解釈しました。それを考えると、彼が機能するようにならない限り、Pythonよりも優れているとは思えません。繰り返しになりますが、私は彼ではないので、推測することしかできません。
ダニエルC.ソブラル2011

20

ClojureとScalaはまったく異なるタイプのプログラミング言語であることに注意してください。Clojureは機能的なLispのような言語であり、オブジェクト指向ではありません。Scalaは、関数型プログラミング機能を備えたオブジェクト指向言語です。

私の意見では、言語の機能と概念(機能、OOなど)は、(その言語の特定の実装の)パフォーマンスよりも言語を選択するためのはるかに重要な基準です-あなたがそうではないことは理解していますがパフォーマンスの高い実装が利用できない言語に閉じ込められたい。

Scalaはオブジェクト指向であるだけでなく、関数型プログラミングを学ぶこともできるので(興味があれば)、Scalaを選びます。一方、OOを気にせず、「純粋な」関数型プログラミングを学びたい場合は、Clojureを試してください。


9
明らかに、Clojureを使用したことはありません。Clojureは、Scalaが機能するのとほぼ同じくらいオブジェクト指向です。インターフェイスの実装、クラスの拡張、プライベート関数と静的関数の宣言などを行うことができます(clojure.org/java_interop)。
リチャードクレイトン2010年

28
これらはJavaとの相互運用性のためにClojureに存在しますが、クラスとオブジェクトは明らかにClojureの主な機能ではありません。Clojureでプログラミングする場合は、クラスを作成したり、オブジェクト指向プログラミングでプロジェクトを設計したりすることはありません。
ジェスパー2010年

>>「パフォーマンスより」。問題は、プロジェクトの奥深くで、パフォーマンスが悪いことに気付いたときに何が起こるかということです。これは、そのほんの一部(その理由でJavaに変換することをすでに計画していた)が原因ではありません。ここで「clojureを使用しないでください-期間..」と言うつもりはありませんが、パフォーマンスの分野ではclojureがより大きなリスクであることは明らかです。それが問題にならないアプリケーションレベルのコードにはたくさんの機会がありますが、それが責任となるフレームワーク/マルチスレッド/処理集約型のコードベースもたくさんあります。
StephenBoesch 2015

@javadba clojureが低レベルのマルチスレッドコードに悪いという考えは、か​​なり恣意的です。Clojureは、マルチスレッドプログラミングの間違いを犯しにくいように設計されています。clojure言語のコアである不変データとSTM機能は、コアScalaでは利用できないものであり、プログラマーが誤って競合状態やデッドロックをコードに挿入する可能性がはるかに低くなります。確かに、これは、ScalaやJavaのような静的に型付けされた言語から得られる数ミリ秒のランタイムよりも価値があります。
nben 2015年

「確かに、これは数ミリ秒のランタイムよりも価値があります」..それはデータの規模に依存します。いくつかのレコードでは、数ミリ秒で十分です。乗算何百万、数百による...
StephenBoesch

16
  1. 慣用的なScalaは慣用的なClojureよりも高速であり、今後もそうなります。
  2. ScalaとClojureはどちらもJavaの上に簡単に座ることができます。どちらもその下にうまく座っていません。

コードが全体を通してタイムクリティカルまたはスペースクリティカルである場合は、Javaを使用してください。しかし、あなたがそう思っていても、そうではありません。

コンピュータ言語のベンチマークゲームのClojureの真のリソースコストにはほとんど光を当てます。Clojureデータ構造は採用されていません。機能およびシーケンスの抽象化は表示されません。

Clojureは単純に見えるかもしれません。そうではありませんが、表現力豊かです。Javaの5分の1の速度で実行される可能性がありますが、ソースは5分の1(YMMV)です。ほとんどのアプリケーションにとって、これは大きなメリットです。しかし、一部の人にとって、そして他の多くの部分にとって、それは壊滅的な損失です。

Clojure言語の経験があれば、問題がClojureで簡潔かつ適切に(パフォーマンスの観点から)表現できる部分とJavaで実行する必要のある部分にきれいに切り分けられるかどうかを事前に知ることができると思います。

  • Scala liteに行くことができます:ScalaでJavaイディオムを書く。複雑な型システムではありますが、簡潔さ、見やすい構文、一貫性のあるシステムが得られます。
  • Clojureliteのようなものはありません。ClojureでJavaイディオムを書くことはまったく無意味です。あなたが得るのは遅いJavaだけです。それはそれを表現するために使われるイディオムの粒を横切っているので理解するのが難しいです。

ScalaはJavaが正しく行われていると言われています。ClojureはJavaのようなものではありません。Lispが正しく行われていると言うかもしれません-大胆で、ばかげていると言う人もいます-それは本当であることが判明するかもしれません。


4
この答えは、2つの真の違いと長所/短所に良い光を当てます。それは、scala-またはclojure-の謝罪者の方法ではなく、むしろ真実の方法で書かれています。
StephenBoesch 2015

15

ComputerLanguageBenchmark Game」によって生成された統計は、おそらくあなたが見つけようとしている最高のものです。

それらは詳細であり、多くの言語を比較できます。問題は、Clojureをカバーしていないことです:(

とは言うものの、何でも提出するのは非常に簡単です-それはすべてオープンソースです。

統計によると、Scalaはかなり速いです。


9
どうぞ。Javaより2〜25倍遅く、メモリとコードサイズは一般にJavaより2〜30倍大きくなります。ScalaがJavaに非常に近いPythonに匹敵するように見えます。Clojureテストの記述が不十分でない限り、Scalaはかなり明確な勝者であり、Clojureは大幅に低速だと思います。
ビルK

2
ベンチマークは現在Clojureをカバーしているようです(OPの発言は1年前です)。そして、その結果は心強いものではありません。Scalaは行く方法です。
マーティン

4
上記のコメントはやや時代遅れです-2012年半ばの時点で、Clojureはギャップを大幅に埋め、現在は平均してJavaの約2倍にすぎません。
mikera 2012

9

相互運用性については、Clojureについて話すことはできませんが、Scalaと同様の状況になると思います。

ScalaからJavaを呼び出すのは簡単です。

外部APIをScalaとJavaの共通点に準拠している限り、JavaからScalaを呼び出すのは簡単です。たとえば、Scalaオブジェクトは、Javaの静的メソッドのようにいくつかの方法で使用されますが、同じものではありません。Scalaクラスは、Javaでおかしな名前のクラスにコンパイルされる場合があります。

あなたはあまり混ぜ合わせたくないでしょう。多くのJavaライブラリを使用するScalaまたはClojureでコンポーネントを構築することは非常に実現可能です。もちろん、Javaからこのコンポーネントを呼び出すこともできますが、やりたくないのは、JavaのScalaプログラムで使用することを目的としたScalaAPIを使用することです。

SVNは「CVSが正しく行われた」と主張しています。私の見解では、ScalaはJavaで正しく実行されています。


19
だからclojureはgitですか?
ロン

1
@ロンハハ、私はまったく同じだと思いました。
KoW 2011年

2
実際、Clojureのコレクションはgitっぽいです
Joe Lehmann

2

PragPubの2010年11月の問題は、 Clojureの-Javaの相互運用性について説明します。Javaメソッドの呼び出しは簡単ですが、Javaクラス/インターフェースの拡張はまったく異なります。

一方、ScalaはJavaにはるかに近いです。Scala-Javaの相互運用性については、http://www.codecommit.com/blog/java/interop-between-java-and-scalaで詳しく説明されています。

Javaコードの呼び出しとJavaクラス/インターフェースの拡張は、Scalaコードの呼び出しと同じように機能します。Scalaの型システムはJavaの型システムよりはるかに強力であるため、いくつかの問題点はJavaのジェネリックを扱う際のいくつかのエッジケースである可能性があります。Java Bean規則に従ってゲッターとセッターを作成するには、アノテーションが必要です。

JavaからScalaを呼び出すことは、ほとんどの場合簡単ですが、たとえば、Scalaのコンパニオンオブジェクトは、それらがバイトコードにコンパイルされる方法を知っている必要があります。また、Javaの非抽象メソッドで特性を使用することは複雑である必要があり、特殊文字を使用してメソッドを呼び出すには、それらがバイトコードでどのようにエンコードされているかを知る必要があります。


1

現在(2010年5月現在)Clojureの最新の1.2ブランチを見る価値があります-これには、プリミティブ型と静的型付け(さまざまな型ヒントとプロトコルによる)の多くの追加サポートが含まれています。

私の理解では、これらの機能は、純粋なJavaでまったく同じコードを書くのと同等の速度を得るために必要なときに使用できます。


2
同時に@specialized、次のScala 2.8の手法は、Scalaライブラリに同様の改善をもたらしています。また、言語機能として、標準ライブラリだけでなく、すべてのコードで利用できます。
Randall Schulz
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.