C언어와 PERL 프로그램 실행시 속도차는???
글쓴이: koonpal / 작성시간: 금, 2005/08/05 - 11:40오전
문자열 처리가 많은 프로그램을 작성할려고 하는데 C언어로 할지 PERL로 할지 고민이 많습니다...
PERL로 작성을 했으면 하는데 C언어로 작성한 것보다 실행 속도가 많이 느릴것 같아 걱정인데...
C언어와 PERL로 작성한 프로그램 속도차가 많이 나나요???
아직 프로그램 작성을 하지 않아 크기가 어느정도인지는 알 수 없지만...
전반적으로 말해서 속도차가 눈에 띄게 나타나는지 궁금해서 이렇게 질문을 올립니다....
답변 좀 해 주세요...
Forums:
속도차이 눈에 띄게 나타나지 않습니다.
물론 간단한 프로그램을 코딩한다고 가정했을 경우,
눈에 보이는 차이가 있습니다.
그러나, 자료구조, 알고리즘으로 깊게 들어가면, perl이나 c나 속도? 거의 비슷합니다.
따지고 보면. y(perl)= x(c or c++)+ a 에서 a 값이 perl이 더 높을뿐이라고 생각합니다.
알고리즘적으로 복잡도를 보자면, x 나 x+ a나 같다고 보니까(big O 개념)요.
그리고, 구현에 있어서 perl이 c 보다 쉽죠... c로 하루종일 걸릴꺼,
perl이면 2~3시간안에 해결해내는 경우도 많습니다.
(가령 hash를 이용할 경우 perl은 %hash 로 끝. c 는 STL 아니면 힘듬)
복잡한 알고리즘을 구현하는 건, C 쓰는 것을 권장하지만, 간단한(?) 부분 특히 문자열 처리는 C 보다는 perl을 쓰는 것이 좋다고
생각합니다.
저같은 경우는 문자열을 처리할 떄, perl로 한번 실행결과를 미리 보기도 하는데요.
c++로 다시 짜서 볼때보다 오히려 perl이 더 빠른게 아닌가? 하는
의구심이 들기도 합니다. ㅡㅡ;
소스의 길이가 길어서 그렇겠지요..(실행 속도는 코드라인과도 관계가 있다고 하니까요..^^)
2년전에 매일 몇천만줄의 문자열,연산을해야 하는일이 있어서 perl로 짰
2년전에 매일 몇천만줄의 문자열,연산을해야 하는일이 있어서 perl로 짰습니다.. 매일 새벽에 처리해야하는일인데 하루안에 결과가 안나오더군여..
C로 짰더니 6시간안에 끝나더군여.. 펄과 C둘다 프로그램 구조는 비슷했습니다.
몇달전까지 그 프로그램이 돌아갔었는데, CPU업그레이드후 6시간이 5시간으로 줄었습니다.
C가 훨씬 빠릅니다.
[quote="dankunwizard"]2년전에 매일 몇천만줄의 문자열,
구체적으로 무슨 작업인지 모르겠지만, 효과적으로 perl을 짰다면
속도는 비슷할 것이라는데 100원 걸겠습니다. =3=33
[quote="dankunwizard"]2년전에 매일 몇천만줄의 문자열,
이말을 책임 지실수 있습니까? 소스를 보여주세요. 8)
예전에 비슷한 주제가 올라온 적이 있죠. http://bbs.kldp.org/viewtopic.php?t=50189
위의 글타래에서도 썼지만, 최적화에 신경을 쓰지 않고 그냥 날 코딩으로 했을 때는 perl, c, java 중에서 perl이 제일 빨랐습니다. 로그분석의 경우에는...
4배나 빠르다는 것은 도저히 믿기지 않는군요.
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
c가 처리 속도를 중점적으로 생각하고 만들어진 언어는 아니라고 생각합니다
c가 처리 속도를 중점적으로 생각하고 만들어진 언어는 아니라고 생각합니다.
[quote="Anonymous"]c가 처리 속도를 중점적으로 생각하고
음 그럼 속도를 위주로 설계된 언어는 어떤것이 있나요?
한사람이 여러가지의 언어로 짜는것이 아니고 여럿이 모여서 각자 자신이 자신있는 언어로 같은 일을 하는 코드를 구현하면 C 가 순위권이라고 생각되는데요
아.. 딴지거는글은 절대 아니고, 요즘 언어들은 추상화에 집착을 해서 점점 느려지는게 추세라고 생각하기 때문에 궁금해서 질문드린겁니다.
[quote]음 그럼 속도를 위주로 설계된 언어는 어떤것이 있나요?[/q
그런 언어는 없죠. 말씀처럼 언어가 추상화되면서 더 느려지는 것이고 C는 느려지기 전의 상태인 것 뿐이죠. 좀더 정확히 말하면 언어가 좀더 다이나믹해질수록 느려지는 경향을 보입니다. C -> C++ -> Java -> Python, Perl, Ruby
속도 차가 궁금하다면 가장 좋은 방법은 벤치마크죠. 한 번 붙어봐요. C가 빠르다고 생각하는 사람과 Perl이 빠르다고 생각하는 사람이 각자 같은 일을 하는 프로그램을 짜서 붙어보는 것, 최소한 그 프로그램에 한해서는 답이 나오겠죠.
복잡한것이라면 C가 훨씬 빠르게 나옵니다.복잡하면 복잡할수록요..
복잡한것이라면 C가 훨씬 빠르게 나옵니다.
복잡하면 복잡할수록요..
----------------------------------------------------------------------------
[quote="M.W.Park"][quote="dankunwizard"]
개인적으로 Perl의 속도는 좀 과장된 면이 있어보입니다.
물론 단순한 문자열 처리의 연속이라면 Perl이 C만큼 우수한 성능을 보여줄수 있겠지만 코드가 커지고 다른 잡다한 부분이 조금씩 포함될때는 전혀 다른양상을 보여줄수도 있지 않을까요?
[quote="M.W.Park"]4배나 빠르다는 것은 도저히 믿기지 않는
충분히 가능하다고 생각합니다만:?:
수천만번 도는 루프 속에 string processing 뿐만 아니라 그걸 처리하는 어떤 코드가 들어있을지 글쓰신분만 빼고 아무도 모르는데 그렇게 단정하시면 곤란합니다.
그리고 C가 속도를 위해 만들어진 언어는 아니라고 하신 분이 있는데... 맞습니다. 하지만 사실상 그렇게 되어버렸습니다. 어설프게 인라인 어셈블리를 끼워넣는 것보다 컴파일러 자체의 최적화가 더 나을 정도로 컴파일러가 발전했으니. 완전히 새로운 패러다임이 등장하지 않는 이상, 저급언어를 제외하고는 C보다 획기적으로 더 빠른 언어가 등장하기는 거의 불가능하다고 생각합니다.
Unix가 어셈블리로 되어있을 때 고급언어로 Unix를 짜면 얼마나 느릴지 회의적인 생각을 하던 사람들이 있었습니다. 그때 만들어진 언어라서 그런지 C는 안전성을 상당히 희생했습니다. overflow 체크 안하기. bound check 안하기. 등등등. 더이상 속도를 위해 뺄 것들이 별로 없습니다.
그리고 글쓰신분껜 perl을 권하고 싶습니다. 문자열 처리는 perl의 특기입니다. :D 코딩도 C보다 훨씬 간편하게 할 수 있구요. perl의 소스를 안봐서 모르겠지만...;; string processing에는 상당히 최적화가 되어있는 걸로 알고 있습니다.
프로그래밍 언어 벤치마크를 언급하신 분이 있는데, 그런 사이트 많이 있답니다. 예전에 The great computer language shootout이라는 사이트가 북마크에 있었는데 없어졌더군요.... 그래서 지웠었는데, 이 글을 보고 다시 찾았습니다.
http://shootout.alioth.debian.org/great/index.php
perl과 gcc를 비교하시려면,
http://shootout.alioth.debian.org/great/benchmark.php?test=all&lang=perl&lang2=gcc&sort=fullcpu
이런, perl이 1000배 느린것도 있군요. :lol:
하지만 regex는 속도가 거의 같네요. 무슨 뜻인지 아시겠죠?
더이상 C와 perl의 속도를 비교하시는분이 없길 바랍니다. 8)
C는 대충대충 짜고, perl은 잘 짜고, 그런 있지도 않을 상황 가정하지 말구요. 코딩하는 분은 질문하신 분 한사람이랍니다.
아, 참고로 그 사이트가 직접순위를 비교하기 어렵게 바뀌었는데... 굳이
아, 참고로 그 사이트가 직접순위를 비교하기 어렵게 바뀌었는데... 굳이 언어를 속도순으로 나열하고 싶으신 분을 위해 제가 기억나는대로 써드립니다. 서열화는 안좋은 거지만 :?
C = Ocaml > C++ > ....생각안남... > Perl > Python > Ruby > php > bash
항상 C 또는 Ocaml 이 가장 빨랐고.. bash가 가장 느렸습니다. (그거야 원래 용도가 다르니까..)
Java는 테스트 프로그램에 따라서 편차가 컸던 걸로 기억합니다.
메모리 사용량은 Java가 제일 많았습니다.
인상깊었던건 Ocaml의 작은 메모리 사용량과 빠른 속도. 그것 때문에 functional language에 더 많은 관심을 갖게 됐죠.
그때는 C#도 없을때였으니, 지금 많이 최적화된 컴파일러들을 갖고 비교한다면 순위가 달라질 수 있음을 알려드립니다.
그리고 저것은 '가장 일반적인 상황에서의 평균'을 갖고 비교한겁니다. 특수한 상황에서는 달라질 수 있다는거 모르는 사람 없습니다.... :wink:
[quote="tomoyo"][quote="M.W.Park"]4배나 빠르
처음 글을 올리신 분이 다량의 문자열 처리를 하신다고 해서... 저의 경험을 올린 글입니다만...
언어간의 절대적인 속도 비교는 별 의미가 없다는 것은 공지의 사실이죠. 8)
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
[quote="tomoyo"][quote="M.W.Park"]perl
A few Good Man
[quote="M.W.Park"]처음 글을 올리신 분이 다량의 문자열 처
정말 인터프리트 언어와 컴파일 언어의 속도 차이가 별 의미가 없다고 생각 하십니까? :P
[quote="Anonymous"][quote="M.W.Park"]처음
사실 bash와 perl을 인터프리터로 볼 수있지만,
bash 는 중간코드나 컴파일의 개념이 전혀 없고,
perl은 실행하기전 간단한(?) 컴파일을 선행하기 때문에
인터프리터라는 말로 뭉뚱그려 표현하기에는 어려운것이 있습니다.
논의를 하기 전에 인터프리터에 대한 정리가 선행되어야할 것 같습니다.
---
http://coolengineer.com
전 퍼포먼스에 민감한 상용 패키지를 오랫동안 만들고실제 여러 ISP,
전 퍼포먼스에 민감한 상용 패키지를 오랫동안 만들고
실제 여러 ISP, 포털 규모의
사이트에서 돌려 본 경험이 있습니다. (현재도 돌구 있구요.^^)
제 경험에 비추면 몇몇 대조되는 프로그램을 만들어서
비교해보는건 결론을 내리는데에는 전혀 도움이 못된다라는게
제 생각입니다.
똑같은 문제를
어떤 식으로 짜면 100배 이상이 차이가 날수도 있고,
어떤 식으로 짜면 똑같을수도 있는데
그 편차는 사실 천차만별로 나올 수 있습니다.
제가 만든 상용 패키지도
퍼포먼스 옵티마이징을 수없이 했건만
소스 단 한 줄의 차이에 따라
cpu를 99% 먹기도 하고 5% 미만으로 먹기도 했습니다.
일단 프로그램의 성능에 대해 이해하려면
프로그램 문법이나 알고리즘 뿐만이 아니라
OS,컴파일러,어셈블러에 대한 넓은 지식도 중요합니다.
그런 면에서 본다면 기반 지식만 어느정도 있다면
OS에 대한 로우레벨 콘트롤이 가능한
C로 훨씬 좋은 성능을 낼 수 있습니다.
간단한 예를들어서
malloc 100000번 하는 프로그램과
calloc 100000번 하는 프로그램의 성능 차이가 얼마나 될거라고 생각하십니까?
big O의 개념으로 본다면 차이가 없지만
실제 돌려보면 좀 놀라실 겁니다.
메모리에 대한 접근, locality, 프로세스의 크기,
레지스터, 스와핑, IO등 기반 지식이 매우 필요하다고 생각되구요.
성능이 중요한 경우라면
그런 지식들과 많은 테스트, 시뮬레이션을 해보시라고
권장해드리고 싶네요.
권위를 의심할 것,어긋남을 존경할 것,자리잡기를 거부할 것,항상 자신을 재창조할 것 - MIT 미디어랩 -
[quote="spacelee"]전 퍼포먼스에 민감한 상용 패키지를 오랫
사실 이러한 것은 어떤 언어라도 비슷하리라 생각합니다. 파이썬 같은 언어의 경우 C와 같은 직접적인 접근이 사실상 불가능하다는 점에서 좀 불리할 수도 있지만, 언어 자체의 특성을 알고 접근한다면 마찬가지로 성능 향상이 있을 수 있을 겁니다. 예를 들어서 다음 두 코드를 비교할 수 있겠지요.
def test1(n): return [0] * n def test2(n): result = [] for i in xrange(n): result.append(0) return resulttest1(3000000)과 test2(3000000)를 비교하면 어떻게 나올 지 상상이 되시죠? :) 결국 일반적인 방법론에는 어떤 언어든 차이가 없으리라는 것이 제 생각입니다. 만약 퍼포먼스를 위해서 모든 것을 희생해야 한다면 C가 좀 더 유리하겠지만요.
- 토끼군
[quote="tokigun"][quote="spacelee"]전 퍼포먼
토끼군님의 의견에는 전적으로 동의합니다.^^
다만 제 개인적인 생각으로 약간의 의견 차이가 있다면
이 문제는 0이나 100의 문제는 아니라는 겁니다.
(사실 대부분의 문제가 그렇죠.^^;; )
OS나 언어 자체 등의 기반지식에 대한 이해가 있으면
어떤 언어든 분명 훨씬 퍼포먼스를 좋게 만들수가 있습니다.
다만, 그 정도의 차가 언어마다 분명히 있을테구요.
그 인식이나 문제해결을 위한 방법론의 관점에서는
0이냐 100이냐의 문제라기보다는
차라리, 10이냐 90이냐, 20이냐 80이냐 같은 식으로
정도의 차로 정의하고 생각하는게
훨씬 정확한 사고방식 것 같습니다.
즉 0이 아닌 것들은 모두다 100인것은 아니다라는
얘기하고도 같은 얘기입니다.
(보통 그레이스케일 사고, 중간적인 사고로
흔히 표현되는 인식론에 관련된 얘기입니다.)
그 정도를 따지자면 토끼군 님이 말씀하셨고, 저도 말씀드렸듯이
로우레벨 콘트롤이 가능한 C가 월등히 낫다고 생각합니다.
단, 위에 말씀드렸듯이 사용환경등에 따라
편차의 정도는 상당하게 날 수 있지만,
cpu-bound job이고 처리가 복잡할수록
그 편차는 월등하게 낫다고 생각합니다.
단순히 몇몇 프로그램 테스트 결과를 인용하여
4배다 아니다라고 하는건 지나친 일반화의 오류라고 생각되네요.
cpu-bound job인 경우
단순하게 포인터 메커니즘 하나면 잘 활용해도
C가 훨씬 유리하다는 걸 쉽게 시뮬레이션으로 보여줄 수가 있습니다.
하여튼 약간의 표현차이지
비슷한 의견같습니다.^^
권위를 의심할 것,어긋남을 존경할 것,자리잡기를 거부할 것,항상 자신을 재창조할 것 - MIT 미디어랩 -
펄은 일단 실행시키면 한박자 쉬고 돌아가 답답하더이다.가령 cgi프로
펄은 일단 실행시키면 한박자 쉬고 돌아가 답답하더이다.
가령 cgi프로그램을 펄로 만들어 올려놓으면 상당히 갑갑한데
그걸 다 c로 만들어 놓으면 날아가는 기분
하지만 덩치 큰 프로그램은 일단 한번 실행되면 그 담부터는
차이 모르겠음
c도 최대속도 내게끔 프로그래밍 하려면
그 어떤 언어에 비해 무적이겠지만..
상당히 빡세고, 알고리즘 개선하는데 너무 시간을 많이 보내고
상당한 노하우가 있어야 하고...날밤 다 지셈 ..
프로그램의 실행속도와 효율은
프로그램 소스 짜는 시간에 투자한 시간과 비례한다는..
결국 빨리 짤수 있는 펄 만세~!
상당히 많은 유저가 사용해야할 프로그램이라면 c로짜자.
허나 소수가 사용할 프로그램이라면 펄이 좋다.
제가 한말씀 덧붙인다면, IO 를 고려하라는 것입니다.어짜피, C
제가 한말씀 덧붙인다면, IO 를 고려하라는 것입니다.
어짜피, CPU 가 빨라졌으니, 어느 factor 정도의 차이가 C 와 perl 사이에 있을지라도,
Perl 의 절대적 속도는 빨라졌다는건 사실입니다.
실행속도보다 더욱 중요한것이 IO 에 따른 오버헤드입니다.
즉, 디스크에서 읽어오는시간, 네트웍 입력이 끝날때까지 기다리는시간 등등..
IO bound ops 가 많다면 당연히 perl 이겠죠?
삽질의 대마왕...
[quote="wslee"]펄은 일단 실행시키면 한박자 쉬고 돌아가 답답
제가 잘 몰르지만, FastCGI 가 이것때문에 나온것 아닌가요?
perl process build 비용이 크기때문에 FastCGI 가 나왔다고만 알고있어서,
이런경우가 아닌가 그냥 넘겨짚어봅니다만..
삽질의 대마왕...
사실 아무 생각없이 C언어로 문자열 처리하는 것이 스크립트 언어로 문자열
사실 아무 생각없이 C언어로 문자열 처리하는 것이 스크립트 언어로 문자열 처리하는 것 보다 나쁠 가능성은 상당 수 존재합니다.
대표적인 예로는 C언어의 null terminated string과 그것을 처리하는 표준 함수의 무 비판적인 사용에서 발생하는 부하입니다.
상당히 잘 고려한 소스라면 C언어가 앞서겠지만 그 외의 경우에는 변수가 많습니다.
- 죠커's blog / HanIRC:#CN
문자열이라면 펄이 대세죠
문자열 처리가 대다수의 잡이라면 펄이 유리한것은 사실입니다.
하지만, 매우 많은 양의 문자열 처리라면 오히려 C의 REGEX 나 메모리로 불러와 직접 처리하는 것이 더 빠를 수 있습니다. 거기에다가 IO 처리는 Realtime extension 의 AIO 나, thread 를 이용해서 비동기화된 작업에 최적화를 걸어주는게 더 빠를 가능성이 높지요.
따라서 일단은 코딩의 절대적 시간은 펄이 훨씬 유리하기 때문에, 펄로 프로토타입을 만들어보시기 바랍니다. 펄로 짜여진게 충분히 기대에 부응하면 문제가 없을테고, 만일 원하는 속도가 안나온다 싶으면 C 로 개작하는게 좋을것 같습니다. C 언어는 자유의 만끼함 대신에 잘못짜면 각종 오류와 잠정적인 무한루프등 고려사항이 많이 등장합니다.
========================================
* The truth will set you free.
[quote]c가 처리 속도를 중점적으로 생각하고 만들어진 언어는 아니라
제가 아는 지식으로 생각컨데 C언어의 문법은 속도를 희생하지 않으면서 인간에 가까워질 수 있는 그 극한에 있습니다. 이보다 더 인간에 가까운 문법으로 C언어보다 더 빠르게 만드는 것은 거의 불가능에 가까울 겁니다.
머, 그래도 대충 짜면 Perl이 더 빠를 수도 있죠.
언제나 이런 종류의 문제는 흥미진진하군요. 답글수만 보아도..펄을
언제나 이런 종류의 문제는 흥미진진하군요. 답글수만 보아도..
펄을 많이 써보진 않았지만, 제가 아는 바로는 그거 인터프리터 언어거든요. 인터프리터 언어가 컴파일러 보다 빠르다는 거는 들어본적이 없는 얘기라 살짝 흥분할 뻔했습니다.
그런데 여기서 얘기하려는 건 그런 원론적인 얘기를 하려는건 아니겠지요.
원칙적으로 C가 빨라야 겠지만, perl이 빠른 경우가 있는 것은 잘짜여진 라이브러리 때문이라고 단언할 수 있습니다. 빠르다고 하는 perl의 내부함수들이 perl로 짜여져 있지는 않을꺼라 생각합니다. 아마 C나 뭐 그런 컴파일러로 되어 있을 겁니다. 전문가들이 짜논 알고리즘이 잘된 라이브러리를 쓰기 때문에 더 빠를 수도 있는거고, 솔직히 같은 라이브러리를 쓴다면 서로 속도가 비슷하겠죠. 사실 논란거리가 없는 겁니다.
하지만 문제는 직접 구현하는 알고리즘이지요.
루틴의 실행 라인수가 많은 상태에서 같은 알고리즘의 C와 Perl은 어느게 더 빠를까요?
특히 루프를 많이 돌려야 하는 부분이라면 차이는 극명해집니다. 그런경우라면 Perl은 찍소리도 못한다는데 1000원 걸겠습니다.
Perl이 속도가 빠르게 하려면 라이브러리를 바로 쓸수 있는데에서는 절대 직접 코드로 구현하면 안될것입니다. 있는 기능만 잘활용하면 Perl을 써도 문제가 없겠죠. 저는 특정 언어를 고집하는 주의는 절대 아닙니다.
예전에 VB를 쓰다가 엄청 놀란적이 있는데, VB가 컴파일언어임에도 불구하고 C에 비해 1000배도 느려질수 있다는 걸 알았는데, 그게 루프를 N번을 돌리는 루틴때문이었습니다. 대신 기존 API하나로 처리하도록 바꿨더니 1/N로 실행시간이 줄어버리더군요.
루프 정말 조심해야 합니다. 꼭 기억하세요.
[quote="ykish"]언제나 이런 종류의 문제는 흥미진진하군요. 답
정리 좀 해주세요. 당췌 무슨 말씀이신지?
정리!...?[quote]...정리 좀 해주세요. 당췌 무
정리!...?
"프로그래밍 언어 자체에 대해 특정적인 속도에 연연하기 보다는 좋은 알고리듬을 항상 고려하여야 한다" 가 요약이 아닐까 합니다.
고급언어의 장점이라면 바로 코딩시간을 줄여서 절약한 시간에 더 좋은 알고리듬을 생각해낼 시간을 벌어준다는 것이죠. C로 하루 걸리는 것을 Perl로 2-3시간 걸린다고 했을 때 그 절약된 시간을 더 적합한 알고리듬을 찾는데 사용한다면 C로 하루 걸린 프로그램을 알고리듬 상으로 능가하여 더 나은 수행속도를 경험 할 수도 있다는 겁니다.
[quote="손님아"][quote="ykish"]언제나 이런 종류의 문
루프를 조심하라는군요. 중간 내용은 저도 잘 이해가 안되지만..-_- 루프 얘기 빼면 이것도 원론적인 얘기 같은데요...;
노루가 사냥꾼의 손에서 벗어나는 것 같이, 새가 그물치는 자의 손에서 벗어나는 것 같이 스스로 구원하라 -잠언 6:5
스크립트 언어의 (작성) 효율성과 C의 속도를 동시에 잡을 수 있는 방법
스크립트 언어의 (작성) 효율성과 C의 속도를 동시에 잡을 수 있는 방법은 없을까요? :)
이를테면, 스크립트를 C 코드로 변환준다던가요. (이미 있을 것 같은 예감이...~_~)
근데 저는 아주 속도가 중요한 부분이 아니라면, 펄을 선택하겠습니다.
pyrex 같은 게 좀
pyrex 같은 게 좀 도움이 될 수 있을 것 같습니다. 그리고 컴파일을 지원하는 언어 중에도 꽤 쓸만한 게 많았던 걸로 기억합니다.
- 토끼군
덤: 근데... 자동으로 quote 붙는 게 안 되네요 이런 줸장 -,.-
[quote="ditto"]스크립트 언어의 (작성) 효율성과 C의 속도를
펄로짜다가 효율성과 속도가 중요한
어마어마어마 무지막대한 루프가 그것도 아주 자주 많이 반복
종종 불러써야하는 상황이 된다면.
고 부분만 뚝 떼서 c로 짜면
ok~
프로그래밍 언어에서 아직까지 속도가 주요 논쟁이 될줄은 몰랐네요.
프로그래밍 언어에서 아직까지 속도가 주요 논쟁이 될줄은 몰랐네요.
만약에 복잡한 프로그래밍을 각각 C와 Perl로 작성했을때
C는 6시간, Perl은 12시간, Python은 15시간이 걸린다고 칩시다.
저라면 Perl이나 Python을 선택하겠습니다.
적어도 정확하게 돌아가는 C프로그램을 만들기 위해서는 Perl보다는 2배의 시간이 걸릴것 같거든요.
Python보다 3배의 시간이 걸리겠죠.
그리고 결정적인것은 제가 작성한 C프로그램이 정확하게 동작하기 위해서
Perl이나 Python보다 수배나 더 테스트를 반복해야 한다는 겁니다.
저같으면 무조건 C로
저같으면 무조건 C로 짭니다 시간이 두배 세배 걸리더라두요..
만일 8시간안에 결과가 나와야되는것이라면요...
예를들어 어제의 데이터를 오늘 아침 9시전까지 다른업체에 보내야한다면요..
이런경우도 있습니다. 밤12시에 작업해서 결과나올때까지 집에못갑니다..ㅡㅡ;;
위의경우는 실무에서 종종 대두되는 문제구요...
위문제가 아니라 하더라도 1억장비에서 12시간돌려야되니까 시간단축하려면.. 장비를 2억짜리 구해야 되는경우가 있겠죠..
C로 짜면 1억번다는결론이되겠죠?
또한 시간을 단축하기위해 하드웨어적으로 업그래이드 하는것은 한계가 있습니다. 정말많이 투자해봐야 두세배빨라지기도 힘들죠...
그러나 소프트웨어적으로 해결하는것은 수십배 수백배 빨라 질수 도 있습니다.
또한 언어의 문법적인 차이가 Logic 의 차이를 불러오죠..
하드웨어 사양이 작업량에 비해 월등하여 성능개선이 전혀불필요한경우도 마찬가지입니다.
그럴겨우 1억장비구할것을 5000만원짜리 구해도 될테니까요...
----------------------------------------------------------------------------
지나가다가
질문하신분이 어떤 것을 프로그래밍하실지 모르지만..
적어도 속도차를 생각한다는 작은 것을 프로그래밍한다고 생각되지 않아서 몇자 적습니다..
유지보수가 특별히 필요 없고 목적이 퍼포먼스다면 구현하기 편하게 C와 Perl을 섞어서 프로그래밍하면서 기계어를 섞는게 낮지 않을까요?
http://root.cern.ch/root/Cint.htmlci
http://root.cern.ch/root/Cint.html
cint를 사용하면 동일한 c/c++ 코드를 인터프리터방식으로 실행이 가능하고 컴파일에 의한 것과 비교가 가능합니다. 제가 time을 가지고 두가지방식을 직접비교해 보았을때 컴파일방식이 인터프리터 방식보다 약 70배 정도 빠른 결과가 나오더군요. cint자체의 퍼포먼스가 하나의 팩터로 작용할 수는 있으나 근본적으로 컴파일방식이 인터프리터방식을 실행속도면에서는 월등한 퍼포먼스를 보이는 것같습니다.
댓글 달기