728x90
Ruby's Concurrency Nightmare
Ruby on Rails, like most other programming technologies, now finds itself caught in the concurrency quagmire. While RoR has a streamlined focus on the Web application domain, parallelism isn't as limited in terms of domain, platform or application—it's everywhere.

Read James Reinders' counter to this article.

It's interesting that James would extol the virtues of Ruby on Rails in a forum dedicated to discussing concurrency. Why? Ruby on Rails has done a magnificent job of wrangling the complexity of Web applications into a relatively simple model-view-controller concept, but Ruby enthusiasts know that the technology is embarrassingly nonfunctional when it comes to concurrency.

Describing Ruby's "somewhat cooperative" threading scheduler, the official Ruby wiki notes the language's limitations, most shockingly with regards to the 10ms timeout to guarantee atomicity and allow context switching. "On a high-end system, a 10ms timeslice can be an extremely long time; when running a thousand threads, as might be common in a large massively-concurrent application, it would take at least ten seconds for all threads to get a timeslice. Because of the issues associated with this 10ms timeslice and those associated with green threading in general, concurrency in Ruby is typically achieved by running or spawning additional Ruby processes."

Ruby also boasts some native-incompatible threading features such as the ability to kill threads from anywhere in the program, invoke infinite sleep states and enter critical sections at will.

Benjamin Gorlick has written an informative piece on the challenges of threading in Ruby and the hopes its aficionados have for concurrency support in the future. Rails, especially, "was not designed with multi-threading in mind. It was coded completely non-thread safe. There is no reentrancy in many code paths and there is no good locking on important data structures, especially during development mode. It appears rails core is assuming everyone is going to stuff their servers with as much RAM as possible. I recommend 8-16GB of RAM for applications over ten pages (That was a joke, sort of). The RAM solution works until you reach the point of running a huge installation. Assuming you are using mongrel to serve your rails applications, most developers are coming up with hacks to move logic out of rails so the mongrel processes will be lighter. This is done using basic message queues and partly helps this sort of operation. Small shared hosting applications and small projects really suffer from the rails lack of multi-threading implementation."

New tools are on the horizon, however. Gorlick writes about JRuby, a Java implementation of the Ruby programming language that uses Java threads (generally, native OS threads). "Since Java no longer uses green threads, JRuby is able to map one ruby thread to one OS thread," Gorlick explains. "This means it is truly concurrent and the JRuby team is working to make it more safely concurrent in all the core classes."

Another tool is the Rubinius virtual machine for the Ruby programming language. Loosely based on the Smalltalk-80 architecture, Rubinius is written in C and has several concurrency primitives such as Channels, Actors, Tasks and Threads. "Rubinius is able to create and manage 1000 threads instantly with no noticeable overhead. Java and Rubinius allow threads to run concurrently (i.e., access the heap concurrently) and since Rubinius implements the same way Java does so it should have performance much like JRuby, although there are still potential bugs and missing features," according to Gorlick.

New Analogies: Experts Needed
I realize that James was merely admiring the elegant focus of Ruby, not its aptitude for concurrency. But I find it supremely interesting that Ruby on Rails, like most other programming technologies, now finds itself caught in the concurrency quagmire.

Furthermore, RoR is adapted to an MVC convention because the Web application domain doesn't need too many additional models. Parallelism isn't as limited in terms of domain, platform or application—it's everywhere.

James's questions bear repeating: Following Ruby's "Convention over Configuration" mantra, what should be the conventions of parallelism be? Certainly, OpenMP and Threading Building Blocks have gone a long way toward standardizing threading code via libraries of common parallel methods. So, are we already achieving CoC, or could there be additional ways to define standard threading and implicit parallelism while forcing developers to specify only their unconventional programming decisions?

With regards to the other Ruby tenet, "Don't repeat yourself," again one could argue that contributions to parallelism libraries are a way to reduce unnecessary labor. But in the context of Ruby, that also means that information is not sprinkled around in hard-to-trace regions of code, but kept in unambiguous repositories. Is there an analogy for concurrency?

Regardless, parallelism solutions can learn from RoR's domain-specific nature—even if RoR needs a push to enter the age of concurrency.

출처: http://www.devx.com/go-parallel/Article/36235?trk=IntelGo%5FCplusSpecial
================================================================================
루비의 당면 과제에 대해 말하고 있는 듯 보인다.
여기서는 동시성에 대해 언급하고 있는데 Ruby on Rails(ROR)에서 thread를 생성하고 실행할 때 10ms(0.1초)정도 소요된단다. 앞서 루비를 소개할 때 스크립트 언어가 느리다고 했는데 thread는 더 느린가보다. (thread가 수백개정도 생성되는 경우가 web application에서는 흔한 일이니까 치명적일 수도 있다.)

Ruby는 몇몇 native-incompatible threading features를 자랑한단다. 이걸 뭐라고 설명해야 할까? thread를 다룰 때 thread의 상태에 상관없이 해당 쓰레드를 kill할 수 있는 능력이 있단다.(이거 thread를 다룰 때 괘 골치아픈 문제다.)

Benjamin Gorlick란 유명한 사람이 앞으로 Ruby는 동시성에 대한 지원이 있어야 한다고 말했단다. 그사람 말에 따르면 Ruby는 multi-threading을 염두하지 않고 만들어졌다. (쓰레드가 없는 것이 안전하단다.)
많은 code에서 재진입을 허용하지 않고 있으며 그것은 중요한 자료구조들을 보호하는 것에 (특히 개발하는 도중엔 더욱) 좋지 않다. Ruby는 서버컴퓨터에서 RAM의 용량이 충분하다고 생각하고 만들어졌다.(RAM이 부족한 상황을 준비하지 않았다는 말. 10page 이상의 프로그램을 위해 8~16G RAM을 권장한다고 그래놓고 농담이란다.ㅡㅡ;)
이 문제를 해결하기 위해 mongrel를 사용하는 경우가 있다고 하는데 mongrel은 사전에 잡종개라고 되어 있다. 아마 다른 언어를 혼용해서 사용하는 것 같다. 기본적으로 ROR을 사용하지만 thread와 관련된 부분은 다른 것을 사용한다는 것 같다.(내가 알기로는 JRuby를 사용해서 thread는 자바의 thread를 쓰기도 한다.) 이런 mongrel processes는 좀더 가볍단다. 소규모 호스팅 applications와 소규모 프로젝트들은 루비의 멀티쓰레딩때문에 생기는 랙(lack)때문에 고생이 많단다.

JRuby를 쓴 Gorlick가 말하길 새로운 tool들이 떠오르고 있단다. 바로 위에서 내가 말한 내용이다. JRuby에서 Ruby언어를 사용하면서 thread는 JAVA의 thread를 쓴다. 자바가 더이상 green thread를 사용하지 않기 때문에 Ruby의 thread하나당 OS thread하나로 매핑시킬 수 있단다.


다른 tool은 Rubinius virtual machine이다. 루비전용 가상머신 정도 되겠다. Rubinius는 Smalltalk-80 architecture에 기반을 두고 만들어졌기 때문에 C로 만들어졌다. 그리고 몇몇 동시성에 대한 원형을 가지고 있는데 Channels, Actors, Tasks and Threads가 그 예다. Rubinius는 눈에띄는 오버헤드없이 1000개의 thread를 생성하고 관리할 수 있다. JAVA와 Rubinius는 thread가 동시성을 가지도록 해준다.(heap에 동시에 접근할 수 있다는 말이다.) Rubinius는 JRuby만큼의 효율을 보여주지만 여전히 가능한 버그들(potential bugs)을 가지고 있고 특징이 없다(missing features)고 Gorlick이 말했다.
728x90
728x90
마이크로소프트가 신규 OS 커널의 프로토 타입을 발표했다. MS 사내행사인 '테크페스트(TechFest)’에서 선보인 이 개념은 ‘Singularity(특이성)’라 불리며, 고난도 컴퓨팅 연구가 주목적이다.

MS에 따르면 이 개념은 윈도우 차기 버전 혹은 도스의 재탕도 아니다. 아직 확실한 설명은 없지만 윈도우를 포함한 현재의 OS 보다 높은 신뢰성과 안정성을 지녔다고 한다.

MS 리서티 릭 라시드 부사장은 "Singularity는 차기 윈도우와는 상관이 없다"며 "OS와 애플리케이션간 정보 교환 방법에 대한 새로운 패러다임을 제시할 것"이라고 밝혔다. 곧, MS 연구원들이 신규 아이디어를 빠르게 시험할 수 있도록 지원하는 다리라는 설명이다.

싱귤래리티 아키텍처.

(제공: Microsoft Research)
구체적으로 보면 Singularity는 현재의 일반적인 OS에 채택된 C나 C++ 대신 MS의 고수준 프로그램 언어인 C#의 확장판으로 기술돼 있다. MS 측은 “C#을 이용하면 ‘버퍼 오버 런’과 같은 에러를 피할 수 있어 악성코드에 대한 방어력이 증대된다”고 주장했다.

이 프로토 타입은 MS의 코드플렉스(CodePlex) 웹 사이트에서 무료로 다운 받을 수 있다. 단, 이는 연구자용 개발 킷(RDK)임을 유념해야 한다.

이 RDK에는 소스코드나 빌드 툴, 테스트 스위트, 설계 메모 등과 기타 자료가 포함돼 있다. 또 MS 리서치 라이선스에 근거, 비상용 연구 프로젝트에서만 사용 가능하다.

한편, MS는 이 SW를 5년 이상 전부터 연구했다고 한다. 40명 이상의 MS 연구원들이 이 프로젝트에 참여해 보안이나 프로그램 언어, 툴에 관한 아이디어를 제공했다. 그 시작에는 ‘근대적인 OS’를 만들어 보자는 야심이 있었다.

윈도우, 유닉스, 리눅스, 맥 OS 등은 1960년대 중반에 개발된 Multics에 기반하고 있다. 즉, 우리가 현재 사용하고 있는 OS는 40여년 전 기술이 모태인 것이다. 그리고 MS는 Singularity로 이런 구도에서 탈피하려 한다.

==========================================================================
dos나 windows계열의 OS는 C와 C++이 운영체제의 기반이 되어 있다. C++이 객체지향언어라고는 하나 완전한 객체지향 언어는 아니다. 기것을 C#으로 대체한다면 어떤 일이 생길까?
난 운영체제에 대한 지식이 많이 없어서 내가 생각하는 것이 맞다는 믿을 순 없다.
하지만 C#이라면 지금처럼 알수없는 주소에 접근하려고 한다면서 뜨는 오류창은 사라질 것이다. 운영체제에서 사용하는 서비스들이 지금보다 자유롭게 움직일 것으로 보인다. 지금은 운영체제가 하나의 프로그램으로 다른 프로그램을 관리해야 하는데 그러한 구분이 사라지면 속도가 훨씬 개선될 것으로 보인다.

하지만 JAVA에서 JVM이 필요하듯이 C#이 구동되기 위해서는 프레임워크도 있어야 하고 실행환경이 있어야 한다. 그 말은 운영체제를 시작하기 위해서는 부팅시스템이 또 필요하다는 말이다. 그리고 C와 C++과 달리 C#은 MS에서 만든(JAVA를 본따서 만들었지만) 언어이니만큼 경쟁회사의 프로그램들은 제대로 작동하지 않을 수도 있다. 한국은 거의 독식하고있고 세계적으로도 꽤 많은 부분을 차지하고 있는 MS에서 점점 경쟁사죽이기에 나가면 멋지다~하고 넉놓고 있을 게 아니라 반기를 들만한 새로운 개념이 등장해야 할 것 같다.
728x90
728x90
  • Design and implement (in C++) an ADT Array that can dynamically grow and shrink as integers are data is inserted and removed. // ADT array 을 하나 맏르어줘서 엄청나게 커질수도 작아질수도 있게 만들어 주는거네요 . Access time to any item in an array (via it's index) should be constant. The cost of an insert into the middle of an array may be O(n). Indexes need not start at zero and may be negative.
  1. The ADT should include the following:
    1. -A default constructor that creates an empty array starting at index 0.
    2. -A constructor taking an intdata [] array that builds an array populated with the items in the array starting at index 0.
    3. -A constructor taking a range int low, int high that builds an empty array ranging from the low index to the high. (Pre: high >= low.)
    4. -A copy constructor array( const array& that ) .
    5. -A destructor. 
    6. -An accessor int size( ) that returns the size of (number of entries in) the array. 
    7. -An accessor int find( intdata n ) that returns the index of element n in the array.
    8. -An accessor int at( intdata n ) that returns the integer at the given index n. 
    9. -A mutator void insert( intdata n ) that inserts the element n at the end of the array.
    10. -A mutator void insert( intdata n, index i ) that inserts the element n into the array at index position i. 
    11. -Amutator void erase( int index ) that removes the element at the given index position in the array. 
    12. -A mutator void clear( ) that empties the array.
    13. Overload the [] operator
    14. Overload the assignment operator =
    15. Overload the operator == to test array equality.
    16. Overload the operator != to test array inequality.

ADT란게 자료의 type에 무관하게 사용하겠다는 겁니다. 뎃글에 자료형을 물어보신 글이 있던데 특정한 자료가 정해진 것아닙니다. C++ 문법에 template이 있는데 이 부분은 표준이 제대로 안되어 있어서 컴파일러마다 조금씩 다르기도 합니다.

배열의 크기가 동적으로 커졌다고 줄었다가 한다고 되어 있습니다. 배열로 지정하고 크기에 따라 deep copy를 통해 크기가 다른 배열로 바꿀 수도 있습니다만 문제에서 O(n)이 예상된다고 하니 링크드리스트를 원하는 것으로 보입니다.


한시간 넘게 붙잡고 있었는데 엉망이다. 귀찮아서 다 inline으로 해버렸고
A constructor taking a range int low, int high that builds an empty array ranging from the low index to the high. (Pre: high >= low.)
이부분... 생성자에서 low와 high값을 argument로 던져주고 배열사이즈를 계산해서 생성하란 것 같은데 무슨 뜻인지, 왜 필요한지 몰라서 제대로 못했다.
그리고 test결과 =연산자가 제대로 작동하지 않는다. 제대로 연산은 되는데 const &로 parameter를 맞추니까 오류나고 그냥 해버리니까 연산이 끝난 후 R-value의 링크가 사라진다. 뭐냐고..

아무튼 문제에 보면 Indexes need not start at zero and may be negative. 이렇게 되어 있는데 그러면 생성할 때 배열의 low와 high를 정하는 것이 아니라 method중에 begin을 결정하는 method가 있으면 되는거 아닌가? 문제를 만든 사람은 뭘 생각한 거지? 내 영어실력이 문젠가?
아무튼 제대로 이해한 사람 있으면 좀 알려주..
728x90

'Programming > C++은객체지향언어다' 카테고리의 다른 글

error C2220: warning treated as error - no object file generated  (0) 2011.07.29
g++ for windows  (0) 2008.11.07
집합(차집합, 교집합, 합집합) - cpp  (0) 2008.04.02
C++ (OOP개념들)  (0) 2008.02.26
C++ (객체)  (0) 2008.02.26
C++ (OOP개념)  (0) 2008.02.26
C++ (개요)  (0) 2008.02.26
728x90

안녕하세요 오랫만에 질문을하네요!!

음 전 이제 중3올라가는데요  수학 공부하다가 모르는것이 생겼습니다.

머 제목을 보시다싶이 아시겠지만 ...암튼 중3이 그냥 수2 미적에 알짱거리는것이 아니라 차원적으로 생각했을때 모순이 발생하기 때문에 그렇습니다.

질문을 자세하게 적죠

평면이라고 하는것은 두께가 없다고 들었습니다(만약있다면 머 문제는 해결된거고요) 즉 2차원이라고나 할까요??

이렇게 두께가 없는 것들이 어떻게 쌓일수가 있죠?? 수투에서 보니까 인테그랄~ ~~ 해가지고 공간이 된다고하는데 쩝 이해가 안가네요

추가적으로 궁금한것은 0차원은 점입니다 점은 길이가 없죠 그냥 point일뿐입니다 근데 이 점이 왜 모여서 길이가 될수있고 왜 면적이 없는 길이가 모여서 넓이가 될수있죠??

아참 점하나하나를 숫자에 대입해서 직선이 된다는 답변은 사절입니다.

제가 궁금한것은 어떻게 점에 길이가있고 직선에 면적이 있고 평면에 부피가 있냐는 말입니다.

무에서 유를 창조하는것도 아니고 도대체 머죠??

그리고 누군가가 그랬는데 점은 0에 가까운 길이가 있고 길이는 0에 가까운 면적이있다고 했습니다

하지만 이것은 모순되지 안나요???

정확하게 설명좀해주세요!!!!

존나 정확하게 말입니다!!

그리고 일반 인간들이 왜 우리가 살고있는 공간이 3차원이라고 하는데 4차원 아닌가요?/??

휴!! 차원이란것 정말 지대로 배우고싶네요!!


728x90

+ Recent posts