루비를 느리게 만드는 것은 무엇입니까?

루비를 느리게 만드는 것은 무엇입니까?

---

루비는 특정한 일에서 느립니다. 하지만 가장 문제가되는 부분은 무엇입니까?

가비지 수집기는 성능에 얼마나 영향을 줍니까? 특히 OpenGL 라이브러리로 작업 할 때 가비지 수집기를 단독으로 실행하는 데 몇 초가 걸렸다는 것을 알고 있습니다.

특히 느린 Ruby와 함께 매트릭스 수학 라이브러리를 사용했습니다. 루비가 기본 수학을 구현하는 방법에 문제가 있습니까?

Ruby에 효율적으로 구현할 수없는 동적 기능이 있습니까? 그렇다면 Lua 및 Python과 같은 다른 언어가 이러한 문제를 어떻게 해결합니까?

성능을 크게 향상시킨 최근 작업이 있었습니까?

---

루비는 느립니다. 하지만 가장 문제가되는 부분은 무엇입니까?

유연성을 허용하기 위해 메소드에 대한 "지연 조회"를 수행합니다. 이로 인해 속도가 상당히 느려집니다. 또한 평가를 허용하기 위해 컨텍스트별로 변수 이름을 기억해야하므로 프레임 및 메서드 호출 속도가 느립니다. 또한 MRI 1.9에는 바이트 코드 컴파일러 (더 좋음)가 있지만 jruby는이를 Java 바이트 코드로 컴파일 한 다음 HotSpot JVM의 JIT 컴파일러를 통해 컴파일 할 수 있지만 현재는 좋은 JIT 컴파일러가 없습니다. 1.9와 같은 속도입니다.

가비지 수집기는 성능에 얼마나 영향을 줍니까? 특히 OpenGL 라이브러리로 작업 할 때 가비지 수집기를 단독으로 실행하는 데 몇 초가 걸렸다는 것을 알고 있습니다.

http://www.igvita.com/2009/06/13/profiling-ruby-with-googles-perftools/의 일부 그래프에서 약 10 %가 소요되며 이는 상당히 많은 양입니다. gc.c에서 malloc_limit를 늘리고 다시 컴파일하여 히트를 줄입니다.

특히 느린 Ruby와 함께 매트릭스 수학 라이브러리를 사용했습니다. 루비가 기본 수학을 구현하는 방법에 문제가 있습니까?

Ruby 1.8은 Numeric 클래스를 구현 한 기본 수학을 구현하지 않았으며 호출 당 한 번씩 Fixnum # + Fixnum # /과 같은 것을 호출했습니다. Ruby 1.9는 기본 수학 연산의 일부를 인라인하여 약간의 속임수를 사용합니다.

Ruby에 효율적으로 구현할 수없는 동적 기능이 있습니까? 그렇다면 Lua 및 Python과 같은 다른 언어가 이러한 문제를 어떻게 해결합니까?

eval과 같은 것은 효율적으로 구현하기 어렵지만 많은 작업을 수행 할 수 있습니다. Ruby의 핵심 은 다른 스레드의 누군가 가 자발적으로 클래스의 정의를 변경하는 것을 수용해야하므로 매우 보수적이어야한다는 것입니다.

성능을 크게 향상시킨 최근 작업이 있었습니까?

1.9는 2 배 속도 향상과 같습니다. 또한 공간 효율적입니다. JRuby는 지속적으로 속도 향상을 위해 노력하고 있습니다 [아마도 KRI보다 GC에서 더 적은 시간을 소비합니다]. 그 외에도 제가하고있는 취미에 대한 작은 것 외에는 많이 알지 못합니다. 또한 1.9의 문자열은 인코딩 친 화성으로 인해 느려집니다.

---

Ruby는 솔루션을 빠르게 제공하는 데 매우 유용합니다. 빠른 솔루션을 제공하는 데는 덜 적합합니다. 해결하려는 문제의 종류에 따라 다릅니다. 90 년대 초에 이전 CompuServe MSBASIC 포럼에서 논의한 내용이 생각납니다. Windows 개발, VB 또는 C 중 어느 것이 더 빠른지 물었을 때 일반적인 대답은 "VB, 약 6 개월 정도"였습니다.

MRI 1.8 형식에서 Ruby는 일부 유형의 계산 집약적 인 작업을 수행하는 데 상대적으로 느립니다. 대부분의 메인 스트림 컴파일 언어에 비해 거의 모든 해석 언어가 그런 식으로 어려움을 겪습니다.

그 이유는 여러 가지입니다. 일부는 상당히 쉽게 주소 지정이 가능하고 (예 : 1.8의 원시 가비지 콜렉션) 일부는 그렇지 않습니다.

1.9는 몇 가지 문제를 해결하지만, 일반적으로 사용되기까지는 시간이 좀 걸릴 것입니다. 예를 들어 기존 런타임을 대상으로하는 일부 다른 구현 (예 : JRuby, IronRuby, MagLev)은 훨씬 더 빠를 수 있습니다.

수학적 성능과 관련하여 상당히 느린 처리량에 놀라지 않을 것입니다. 이는 임의 정밀도에 대해 지불하는 대가의 일부입니다. 다시, 문제를 선택하십시오. 루비에서 70 개 이상의 프로젝트 오일러 문제를 해결했으며 실행하는 데 1 분 이상 걸리는 솔루션이 거의 없습니다. 실행하는 데 얼마나 빠르며 얼마나 빨리 필요합니까?

---

가장 문제가되는 부분은 "모두"입니다.

"모든 사람"이 실제로 언어를 사용하지 않으면 보너스 포인트가 주어집니다.

진지하게 1.9는 훨씬 빠르며 이제 파이썬과 동등하며 jruby는 자이 썬보다 빠릅니다.

가비지 수집가는 어디에나 있습니다. 예를 들어 Java에는 하나가 있으며 동적 메모리 처리에서 C ++보다 빠릅니다. Ruby는 숫자 처리에 적합하지 않습니다. 하지만 언어가 거의 없기 때문에 프로그램에 어떤 언어로든 계산 집약적 인 부분이있는 경우 C로 다시 작성하는 것이 좋습니다 (자바는 원시 유형으로 인해 수학에서 빠르지 만 그에 대한 대가를 치렀습니다. 분명히 # 언어의 가장 못생긴 부분에서 1 위).

동적 기능은 빠르지 않지만 정적 언어로 작성된 코드는 더 느릴 수 있습니다. 예를 들어, java는 DSL을 사용하는 Ruby 대신 XML 구성을 사용합니다. XML 파싱은 비용이 많이 들기 때문에 속도가 느릴 수 있습니다.

---

흠-몇 년 전에 Ruby 성능으로 배럴을 긁어 모은 프로젝트에서 일했는데 그 이후로 많은 변화가 있었는지 모르겠습니다. 지금 당장은주의 할 점이 있습니다. 특정 작업을 수행하지 않도록 알아야하며 솔직히 게임 / 실시간 애플리케이션이 그중 하나 일 것입니다 (OpenGL을 언급 한 이후로).

대화 형 성능을 저하시키는 원인은 가비지 수집기입니다. 여기에있는 다른 사람들은 Java 및 기타 환경에도 가비지 수집이 있지만 Ruby는 실행 을 중지 해야한다고 언급 합니다. 즉, 프로그램 실행을 중지하고 모든 레지스터와 메모리 포인터를 처음부터 스캔하고 아직 사용중인 메모리를 표시하고 나머지는 해제해야합니다. 이 과정에서 프로세스를 중단 할 수 없으며 눈치 채 셨겠지만 수백 밀리 초가 걸릴 수 있습니다.

실행 빈도와 길이는 생성하고 파괴하는 객체의 수에 비례하지만 완전히 비활성화하지 않는 한 제어 할 수 없습니다. 내 경험으로는 Ruby 애니메이션 루프를 매끄럽게 만드는 몇 가지 불만족스러운 전략이있었습니다.

• GC.disable / GC.enable은 중요한 애니메이션 루프 주변에서 가능하며 기회 주의적 GC.start는 해를 입힐 수 없을 때 강제로 강제 실행합니다. (당시의 타겟 플랫폼이 64MB Windows NT 시스템 이었기 때문에 이로 인해 시스템에 가끔 메모리가 부족해졌습니다.하지만 근본적으로 이것은 나쁜 생각입니다.이 작업을 수행하기 전에 필요한 메모리 양을 미리 계산할 수 없다면, '메모리 고갈 위험이 있습니다)
• 생성하는 개체 수를 줄여 GC에서 수행 할 작업을 줄입니다 (실행 빈도 / 길이 감소).
• 애니메이션 루프를 C로 다시 작성하십시오 (코프 아웃이지만 제가 함께했던 것입니다!).

요즘에는 JRuby가 Java의 더 정교한 가비지 수집기에 의존한다고 믿기 때문에 JRuby가 대체 런타임으로 작동하는지 확인할 수도 있습니다.

내가 찾은 또 다른 주요 성능 문제는 Ruby로 TFTP 서버를 작성하려고 할 때 기본 I / O입니다 (예, 성능이 중요한 프로젝트에 가장 적합한 언어를 모두 선택했습니다. 이것은 단지 실험이었습니다). 하나의 UDP 패킷에 다른 하나의 UDP 패킷에 간단히 응답하여 파일의 다음 부분을 연결하는 가장 간단한 가장 엄격한 루프는 기본 C 버전보다 약 20 배 느 렸을 것입니다. 저수준 IO (sysread 등) 사용을 기반으로 한 개선이 있었을 수도 있지만 저수준 바이트 데이터 유형이 없다는 사실이 느려질 수 있습니다-모든 작은 읽기가 끈. 이것은 단지 추측 일뿐입니다. 저는이 프로젝트를 훨씬 더 이상 진행하지 않았지만 빠른 I / O에 의존하지 않도록 경고했습니다.

내가 여기서 완전히 최신 상태는 아니지만 최근에 진행된 주요 속도 증가는 가상 머신 구현이 1.9 용으로 다시 실행되어 코드 실행 속도가 빨라 졌다는 것입니다. 그러나 나는 GC가 변경되었다고 생각하지 않으며 I / O 전면에 새로운 것이 없다고 확신합니다. 그러나 나는 최첨단 Ruby에 대해 완전히 최신이 아니므로 다른 누군가가 여기에 칩을 원할 수 있습니다.

---

Steve Dekorte : "고수준 언어로 Mandelbrot 세트 계산기를 작성하는 것은 버스에서 Indy 500을 실행하려는 것과 같습니다."

http://www.dekorte.com/blog/blog.cgi?do=item&id=4047

I recommend to learn various tools in order to use the right tool for the job. Doing matrix transformations could be done efficiently using high-level API which wraps around tight loops with arithmetic-intensive computations. See RubyInline gem for an example of embedding C or C++ code into Ruby script.

There is also Io language which is much slower than Ruby, but it efficiently renders movies in Pixar and outperforms raw C on vector arithmetics by using SIMD acceleration.

• http://iolanguage.com
• https://renderman.pixar.com/products/tools/it.html
• http://iolanguage.com/scm/git/checkout/Io/docs/IoGuide.html#Primitives-Vector

---

I assume that you're asking, "what particular techniques in Ruby tend to be slow."

One is object instantiation. If you are doing large amounts of it, you want to look at (reasonable) ways of reducing that, such as using the flyweight pattern, even if memory usage is not a problem. In one library where I reworked it not to be creating a lot of very similar objects over and over again, I doubled the overall speed of the library.

---

Ruby 1.9.1 is about twice as fast as PHP, and a little bit faster than Perl, according to some benchmarks.

(Update: My source is this (screenshot). I don't know what his source is, though.)

Ruby is not slow. The old 1.8 is, but the current Ruby isn't.

---

Ruby is slow because it was designed to optimize the programmers experience, not the program's execution time. Slowness is just a symptom of that design decision. If you would prefer performance to pleasure, you should probably use a different language. Ruby's not for everything.

---

IMO, dynamic languages are all slow in general. They do something in runtime that static languages do in compiling time.

Syntax Check, Interpreting and Like type checking, converting. this is inevitable, therefore ruby is slower than c/c++/java, correct me if I am wrong.

ReferenceURL : https://stackoverflow.com/questions/1011460/what-makes-ruby-slow