C언어와 PERL 프로그램 실행시 속도차는???

koonpal의 이미지

문자열 처리가 많은 프로그램을 작성할려고 하는데 C언어로 할지 PERL로 할지 고민이 많습니다...

PERL로 작성을 했으면 하는데 C언어로 작성한 것보다 실행 속도가 많이 느릴것 같아 걱정인데...

C언어와 PERL로 작성한 프로그램 속도차가 많이 나나요???

아직 프로그램 작성을 하지 않아 크기가 어느정도인지는 알 수 없지만...

전반적으로 말해서 속도차가 눈에 띄게 나타나는지 궁금해서 이렇게 질문을 올립니다....

답변 좀 해 주세요...

assa의 이미지

물론 간단한 프로그램을 코딩한다고 가정했을 경우,

눈에 보이는 차이가 있습니다.

그러나, 자료구조, 알고리즘으로 깊게 들어가면, 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이 더 빠른게 아닌가? 하는
의구심이 들기도 합니다. ㅡㅡ;

소스의 길이가 길어서 그렇겠지요..(실행 속도는 코드라인과도 관계가 있다고 하니까요..^^)

agkrwyasym의 이미지

2년전에 매일 몇천만줄의 문자열,연산을해야 하는일이 있어서 perl로 짰습니다.. 매일 새벽에 처리해야하는일인데 하루안에 결과가 안나오더군여..

C로 짰더니 6시간안에 끝나더군여.. 펄과 C둘다 프로그램 구조는 비슷했습니다.

몇달전까지 그 프로그램이 돌아갔었는데, CPU업그레이드후 6시간이 5시간으로 줄었습니다.

C가 훨씬 빠릅니다.

익명 사용자의 이미지

dankunwizard wrote:
2년전에 매일 몇천만줄의 문자열,연산을해야 하는일이 있어서 perl로 짰습니다.. 매일 새벽에 처리해야하는일인데 하루안에 결과가 안나오더군여..

C로 짰더니 6시간안에 끝나더군여.. 펄과 C둘다 프로그램 구조는 비슷했습니다.

몇달전까지 그 프로그램이 돌아갔었는데, CPU업그레이드후 6시간이 5시간으로 줄었습니다.

C가 훨씬 빠릅니다.

구체적으로 무슨 작업인지 모르겠지만, 효과적으로 perl을 짰다면
속도는 비슷할 것이라는데 100원 걸겠습니다. =3=33

M.W.Park의 이미지

dankunwizard wrote:
2년전에 매일 몇천만줄의 문자열,연산을해야 하는일이 있어서 perl로 짰습니다.. 매일 새벽에 처리해야하는일인데 하루안에 결과가 안나오더군여..

C로 짰더니 6시간안에 끝나더군여.. 펄과 C둘다 프로그램 구조는 비슷했습니다.

몇달전까지 그 프로그램이 돌아갔었는데, CPU업그레이드후 6시간이 5시간으로 줄었습니다.

C가 훨씬 빠릅니다.

이말을 책임 지실수 있습니까? 소스를 보여주세요. 8)
예전에 비슷한 주제가 올라온 적이 있죠. http://bbs.kldp.org/viewtopic.php?t=50189
위의 글타래에서도 썼지만, 최적화에 신경을 쓰지 않고 그냥 날 코딩으로 했을 때는 perl, c, java 중에서 perl이 제일 빨랐습니다. 로그분석의 경우에는...
4배나 빠르다는 것은 도저히 믿기지 않는군요.

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂

익명 사용자의 이미지

c가 처리 속도를 중점적으로 생각하고 만들어진 언어는 아니라고 생각합니다.

익명 사용자의 이미지

Anonymous wrote:
c가 처리 속도를 중점적으로 생각하고 만들어진 언어는 아니라고 생각합니다.

음 그럼 속도를 위주로 설계된 언어는 어떤것이 있나요?

한사람이 여러가지의 언어로 짜는것이 아니고 여럿이 모여서 각자 자신이 자신있는 언어로 같은 일을 하는 코드를 구현하면 C 가 순위권이라고 생각되는데요

아.. 딴지거는글은 절대 아니고, 요즘 언어들은 추상화에 집착을 해서 점점 느려지는게 추세라고 생각하기 때문에 궁금해서 질문드린겁니다.

creativeidler의 이미지

Quote:
음 그럼 속도를 위주로 설계된 언어는 어떤것이 있나요?

그런 언어는 없죠. 말씀처럼 언어가 추상화되면서 더 느려지는 것이고 C는 느려지기 전의 상태인 것 뿐이죠. 좀더 정확히 말하면 언어가 좀더 다이나믹해질수록 느려지는 경향을 보입니다. C -> C++ -> Java -> Python, Perl, Ruby

속도 차가 궁금하다면 가장 좋은 방법은 벤치마크죠. 한 번 붙어봐요. C가 빠르다고 생각하는 사람과 Perl이 빠르다고 생각하는 사람이 각자 같은 일을 하는 프로그램을 짜서 붙어보는 것, 최소한 그 프로그램에 한해서는 답이 나오겠죠.

ㅡ,.ㅡ;;의 이미지

복잡한것이라면 C가 훨씬 빠르게 나옵니다.

복잡하면 복잡할수록요..


----------------------------------------------------------------------------

익명 사용자의 이미지

M.W.Park wrote:
dankunwizard wrote:
2년전에 매일 몇천만줄의 문자열,연산을해야 하는일이 있어서 perl로 짰습니다.. 매일 새벽에 처리해야하는일인데 하루안에 결과가 안나오더군여..

C로 짰더니 6시간안에 끝나더군여.. 펄과 C둘다 프로그램 구조는 비슷했습니다.

몇달전까지 그 프로그램이 돌아갔었는데, CPU업그레이드후 6시간이 5시간으로 줄었습니다.

C가 훨씬 빠릅니다.

이말을 책임 지실수 있습니까? 소스를 보여주세요. 8)
예전에 비슷한 주제가 올라온 적이 있죠. http://bbs.kldp.org/viewtopic.php?t=50189
위의 글타래에서도 썼지만, 최적화에 신경을 쓰지 않고 그냥 날 코딩으로 했을 때는 perl, c, java 중에서 perl이 제일 빨랐습니다. 로그분석의 경우에는...
4배나 빠르다는 것은 도저히 믿기지 않는군요.

개인적으로 Perl의 속도는 좀 과장된 면이 있어보입니다.
물론 단순한 문자열 처리의 연속이라면 Perl이 C만큼 우수한 성능을 보여줄수 있겠지만 코드가 커지고 다른 잡다한 부분이 조금씩 포함될때는 전혀 다른양상을 보여줄수도 있지 않을까요?

_의 이미지

M.W.Park wrote:
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:

M.W.Park의 이미지

tomoyo wrote:
M.W.Park wrote:
4배나 빠르다는 것은 도저히 믿기지 않는군요.

충분히 가능하다고 생각합니다만:?:
수천만번 도는 루프 속에 string processing 뿐만 아니라 그걸 처리하는 어떤 코드가 들어있을지 글쓰신분만 빼고 아무도 모르는데 그렇게 단정하시면 곤란합니다.

처음 글을 올리신 분이 다량의 문자열 처리를 하신다고 해서... 저의 경험을 올린 글입니다만...
언어간의 절대적인 속도 비교는 별 의미가 없다는 것은 공지의 사실이죠. 8)

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂

코퍼스의 이미지

tomoyo wrote:
M.W.Park wrote:

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은 잘 짜고, 그런 있지도 않을 상황 가정하지 말구요. 코딩하는 분은 질문하신 분 한사람이랍니다.


맞는 말씀입니다. 일반적인 경우에 대해서도 잘 설명하셨구요
그렇지만, 실제 작업 결과에서는 조금 차이가 나는 경우가 많습니다.
실제로 특정한 종류의 알고리즘 처리에 따라서는 언어의 내부 최적화 엔진에 따라 차이가 있을 수 있습니다.
실제로 regex 외의 내부 데이터스트럭쳐 처리 방식에 따라서 perl이 C 실행 파일보다 더 빠른 경우도 많지요.
물론, 다른 경우에는 파이썬이 펄보다 빠른 경우도 있구요.

얘기해주신 경우처럼, 실제로 사람이 어설프게 짠 어셈 코드보다 컴파일러에서 만들어낸 코드가 훨씬 효율이 좋은 경우와 같은 예이겠지요.

A few Good Man

익명 사용자의 이미지

M.W.Park wrote:
처음 글을 올리신 분이 다량의 문자열 처리를 하신다고 해서... 저의 경험을 올린 글입니다만...
언어간의 절대적인 속도 비교는 별 의미가 없다는 것은 공지의 사실이죠. 8)

정말 인터프리트 언어와 컴파일 언어의 속도 차이가 별 의미가 없다고 생각 하십니까? :P

pynoos의 이미지

Anonymous wrote:
M.W.Park wrote:
처음 글을 올리신 분이 다량의 문자열 처리를 하신다고 해서... 저의 경험을 올린 글입니다만...
언어간의 절대적인 속도 비교는 별 의미가 없다는 것은 공지의 사실이죠. 8)

정말 인터프리트 언어와 컴파일 언어의 속도 차이가 별 의미가 없다고 생각 하십니까? :P

사실 bash와 perl을 인터프리터로 볼 수있지만,
bash 는 중간코드나 컴파일의 개념이 전혀 없고,
perl은 실행하기전 간단한(?) 컴파일을 선행하기 때문에
인터프리터라는 말로 뭉뚱그려 표현하기에는 어려운것이 있습니다.

논의를 하기 전에 인터프리터에 대한 정리가 선행되어야할 것 같습니다.

spacelee의 이미지

전 퍼포먼스에 민감한 상용 패키지를 오랫동안 만들고
실제 여러 ISP, 포털 규모의
사이트에서 돌려 본 경험이 있습니다. (현재도 돌구 있구요.^^)

제 경험에 비추면 몇몇 대조되는 프로그램을 만들어서
비교해보는건 결론을 내리는데에는 전혀 도움이 못된다라는게
제 생각입니다.

똑같은 문제를
어떤 식으로 짜면 100배 이상이 차이가 날수도 있고,
어떤 식으로 짜면 똑같을수도 있는데
그 편차는 사실 천차만별로 나올 수 있습니다.

제가 만든 상용 패키지도
퍼포먼스 옵티마이징을 수없이 했건만
소스 단 한 줄의 차이에 따라
cpu를 99% 먹기도 하고 5% 미만으로 먹기도 했습니다.

일단 프로그램의 성능에 대해 이해하려면
프로그램 문법이나 알고리즘 뿐만이 아니라
OS,컴파일러,어셈블러에 대한 넓은 지식도 중요합니다.

그런 면에서 본다면 기반 지식만 어느정도 있다면
OS에 대한 로우레벨 콘트롤이 가능한
C로 훨씬 좋은 성능을 낼 수 있습니다.

간단한 예를들어서
malloc 100000번 하는 프로그램과
calloc 100000번 하는 프로그램의 성능 차이가 얼마나 될거라고 생각하십니까?
big O의 개념으로 본다면 차이가 없지만
실제 돌려보면 좀 놀라실 겁니다.

메모리에 대한 접근, locality, 프로세스의 크기,
레지스터, 스와핑, IO등 기반 지식이 매우 필요하다고 생각되구요.

성능이 중요한 경우라면
그런 지식들과 많은 테스트, 시뮬레이션을 해보시라고
권장해드리고 싶네요.

권위를 의심할 것,어긋남을 존경할 것,자리잡기를 거부할 것,항상 자신을 재창조할 것 - MIT 미디어랩 -

lifthrasiir의 이미지

spacelee wrote:
전 퍼포먼스에 민감한 상용 패키지를 오랫동안 만들고
실제 여러 ISP, 포털 규모의
사이트에서 돌려 본 경험이 있습니다. (현재도 돌구 있구요.^^)

제 경험에 비추면 몇몇 대조되는 프로그램을 만들어서
비교해보는건 결론을 내리는데에는 전혀 도움이 못된다라는게
제 생각입니다.

똑같은 문제를
어떤 식으로 짜면 100배 이상이 차이가 날수도 있고,
어떤 식으로 짜면 똑같을수도 있는데
그 편차는 사실 천차만별로 나올 수 있습니다.

제가 만든 상용 패키지도
퍼포먼스 옵티마이징을 수없이 했건만
소스 단 한 줄의 차이에 따라
cpu를 99% 먹기도 하고 5% 미만으로 먹기도 했습니다.

일단 프로그램의 성능에 대해 이해하려면
프로그램 문법이나 알고리즘 뿐만이 아니라
OS,컴파일러,어셈블러에 대한 넓은 지식도 중요합니다.

그런 면에서 본다면 기반 지식만 어느정도 있다면
OS에 대한 로우레벨 콘트롤이 가능한
C로 훨씬 좋은 성능을 낼 수 있습니다.

간단한 예를들어서
malloc 100000번 하는 프로그램과
calloc 100000번 하는 프로그램의 성능 차이가 얼마나 될거라고 생각하십니까?
big O의 개념으로 본다면 차이가 없지만
실제 돌려보면 좀 놀라실 겁니다.

메모리에 대한 접근, locality, 프로세스의 크기,
레지스터, 스와핑, IO등 기반 지식이 매우 필요하다고 생각되구요.

성능이 중요한 경우라면
그런 지식들과 많은 테스트, 시뮬레이션을 해보시라고
권장해드리고 싶네요.

사실 이러한 것은 어떤 언어라도 비슷하리라 생각합니다. 파이썬 같은 언어의 경우 C와 같은 직접적인 접근이 사실상 불가능하다는 점에서 좀 불리할 수도 있지만, 언어 자체의 특성을 알고 접근한다면 마찬가지로 성능 향상이 있을 수 있을 겁니다. 예를 들어서 다음 두 코드를 비교할 수 있겠지요.

def test1(n):
    return [0] * n
def test2(n):
    result = []
    for i in xrange(n): result.append(0)
    return result

test1(3000000)과 test2(3000000)를 비교하면 어떻게 나올 지 상상이 되시죠? :) 결국 일반적인 방법론에는 어떤 언어든 차이가 없으리라는 것이 제 생각입니다. 만약 퍼포먼스를 위해서 모든 것을 희생해야 한다면 C가 좀 더 유리하겠지만요.

- 토끼군

spacelee의 이미지

tokigun wrote:
spacelee wrote:
전 퍼포먼스에 민감한 상용 패키지를 오랫동안 만들고
실제 여러 ISP, 포털 규모의
사이트에서 돌려 본 경험이 있습니다. (현재도 돌구 있구요.^^)

제 경험에 비추면 몇몇 대조되는 프로그램을 만들어서
비교해보는건 결론을 내리는데에는 전혀 도움이 못된다라는게
제 생각입니다.

똑같은 문제를
어떤 식으로 짜면 100배 이상이 차이가 날수도 있고,
어떤 식으로 짜면 똑같을수도 있는데
그 편차는 사실 천차만별로 나올 수 있습니다.

제가 만든 상용 패키지도
퍼포먼스 옵티마이징을 수없이 했건만
소스 단 한 줄의 차이에 따라
cpu를 99% 먹기도 하고 5% 미만으로 먹기도 했습니다.

일단 프로그램의 성능에 대해 이해하려면
프로그램 문법이나 알고리즘 뿐만이 아니라
OS,컴파일러,어셈블러에 대한 넓은 지식도 중요합니다.

그런 면에서 본다면 기반 지식만 어느정도 있다면
OS에 대한 로우레벨 콘트롤이 가능한
C로 훨씬 좋은 성능을 낼 수 있습니다.

간단한 예를들어서
malloc 100000번 하는 프로그램과
calloc 100000번 하는 프로그램의 성능 차이가 얼마나 될거라고 생각하십니까?
big O의 개념으로 본다면 차이가 없지만
실제 돌려보면 좀 놀라실 겁니다.

메모리에 대한 접근, locality, 프로세스의 크기,
레지스터, 스와핑, IO등 기반 지식이 매우 필요하다고 생각되구요.

성능이 중요한 경우라면
그런 지식들과 많은 테스트, 시뮬레이션을 해보시라고
권장해드리고 싶네요.

사실 이러한 것은 어떤 언어라도 비슷하리라 생각합니다. 파이썬 같은 언어의 경우 C와 같은 직접적인 접근이 사실상 불가능하다는 점에서 좀 불리할 수도 있지만, 언어 자체의 특성을 알고 접근한다면 마찬가지로 성능 향상이 있을 수 있을 겁니다. 예를 들어서 다음 두 코드를 비교할 수 있겠지요.

def test1(n):
    return [0] * n
def test2(n):
    result = []
    for i in xrange(n): result.append(0)
    return result

test1(3000000)과 test2(3000000)를 비교하면 어떻게 나올 지 상상이 되시죠? :) 결국 일반적인 방법론에는 어떤 언어든 차이가 없으리라는 것이 제 생각입니다. 만약 퍼포먼스를 위해서 모든 것을 희생해야 한다면 C가 좀 더 유리하겠지만요.

- 토끼군

토끼군님의 의견에는 전적으로 동의합니다.^^
다만 제 개인적인 생각으로 약간의 의견 차이가 있다면
이 문제는 0이나 100의 문제는 아니라는 겁니다.
(사실 대부분의 문제가 그렇죠.^^;; )

OS나 언어 자체 등의 기반지식에 대한 이해가 있으면
어떤 언어든 분명 훨씬 퍼포먼스를 좋게 만들수가 있습니다.

다만, 그 정도의 차가 언어마다 분명히 있을테구요.
그 인식이나 문제해결을 위한 방법론의 관점에서는
0이냐 100이냐의 문제라기보다는
차라리, 10이냐 90이냐, 20이냐 80이냐 같은 식으로
정도의 차로 정의하고 생각하는게
훨씬 정확한 사고방식 것 같습니다.
즉 0이 아닌 것들은 모두다 100인것은 아니다라는
얘기하고도 같은 얘기입니다.
(보통 그레이스케일 사고, 중간적인 사고로
흔히 표현되는 인식론에 관련된 얘기입니다.)

그 정도를 따지자면 토끼군 님이 말씀하셨고, 저도 말씀드렸듯이
로우레벨 콘트롤이 가능한 C가 월등히 낫다고 생각합니다.

단, 위에 말씀드렸듯이 사용환경등에 따라
편차의 정도는 상당하게 날 수 있지만,
cpu-bound job이고 처리가 복잡할수록
그 편차는 월등하게 낫다고 생각합니다.

단순히 몇몇 프로그램 테스트 결과를 인용하여
4배다 아니다라고 하는건 지나친 일반화의 오류라고 생각되네요.

cpu-bound job인 경우
단순하게 포인터 메커니즘 하나면 잘 활용해도
C가 훨씬 유리하다는 걸 쉽게 시뮬레이션으로 보여줄 수가 있습니다.

하여튼 약간의 표현차이지
비슷한 의견같습니다.^^

권위를 의심할 것,어긋남을 존경할 것,자리잡기를 거부할 것,항상 자신을 재창조할 것 - MIT 미디어랩 -

wslee의 이미지

펄은 일단 실행시키면 한박자 쉬고 돌아가 답답하더이다.
가령 cgi프로그램을 펄로 만들어 올려놓으면 상당히 갑갑한데
그걸 다 c로 만들어 놓으면 날아가는 기분

하지만 덩치 큰 프로그램은 일단 한번 실행되면 그 담부터는
차이 모르겠음

c도 최대속도 내게끔 프로그래밍 하려면
그 어떤 언어에 비해 무적이겠지만..
상당히 빡세고, 알고리즘 개선하는데 너무 시간을 많이 보내고
상당한 노하우가 있어야 하고...날밤 다 지셈 ..

프로그램의 실행속도와 효율은
프로그램 소스 짜는 시간에 투자한 시간과 비례한다는..

결국 빨리 짤수 있는 펄 만세~!

상당히 많은 유저가 사용해야할 프로그램이라면 c로짜자.
허나 소수가 사용할 프로그램이라면 펄이 좋다.

litdream의 이미지

제가 한말씀 덧붙인다면, IO 를 고려하라는 것입니다.

어짜피, CPU 가 빨라졌으니, 어느 factor 정도의 차이가 C 와 perl 사이에 있을지라도,
Perl 의 절대적 속도는 빨라졌다는건 사실입니다.

실행속도보다 더욱 중요한것이 IO 에 따른 오버헤드입니다.
즉, 디스크에서 읽어오는시간, 네트웍 입력이 끝날때까지 기다리는시간 등등..
IO bound ops 가 많다면 당연히 perl 이겠죠?

삽질의 대마왕...

litdream의 이미지

wslee wrote:
펄은 일단 실행시키면 한박자 쉬고 돌아가 답답하더이다.
가령 cgi프로그램을 펄로 만들어 올려놓으면 상당히 갑갑한데
그걸 다 c로 만들어 놓으면 날아가는 기분

하지만 덩치 큰 프로그램은 일단 한번 실행되면 그 담부터는
차이 모르겠음

c도 최대속도 내게끔 프로그래밍 하려면
그 어떤 언어에 비해 무적이겠지만..
상당히 빡세고, 알고리즘 개선하는데 너무 시간을 많이 보내고
상당한 노하우가 있어야 하고...날밤 다 지셈 ..

프로그램의 실행속도와 효율은
프로그램 소스 짜는 시간에 투자한 시간과 비례한다는..

결국 빨리 짤수 있는 펄 만세~!

상당히 많은 유저가 사용해야할 프로그램이라면 c로짜자.
허나 소수가 사용할 프로그램이라면 펄이 좋다.

제가 잘 몰르지만, FastCGI 가 이것때문에 나온것 아닌가요?
perl process build 비용이 크기때문에 FastCGI 가 나왔다고만 알고있어서,
이런경우가 아닌가 그냥 넘겨짚어봅니다만..

삽질의 대마왕...

죠커의 이미지

사실 아무 생각없이 C언어로 문자열 처리하는 것이 스크립트 언어로 문자열 처리하는 것 보다 나쁠 가능성은 상당 수 존재합니다.

대표적인 예로는 C언어의 null terminated string과 그것을 처리하는 표준 함수의 무 비판적인 사용에서 발생하는 부하입니다.

상당히 잘 고려한 소스라면 C언어가 앞서겠지만 그 외의 경우에는 변수가 많습니다.

sunyzero의 이미지

문자열 처리가 대다수의 잡이라면 펄이 유리한것은 사실입니다.

하지만, 매우 많은 양의 문자열 처리라면 오히려 C의 REGEX 나 메모리로 불러와 직접 처리하는 것이 더 빠를 수 있습니다. 거기에다가 IO 처리는 Realtime extension 의 AIO 나, thread 를 이용해서 비동기화된 작업에 최적화를 걸어주는게 더 빠를 가능성이 높지요.

따라서 일단은 코딩의 절대적 시간은 펄이 훨씬 유리하기 때문에, 펄로 프로토타입을 만들어보시기 바랍니다. 펄로 짜여진게 충분히 기대에 부응하면 문제가 없을테고, 만일 원하는 속도가 안나온다 싶으면 C 로 개작하는게 좋을것 같습니다. C 언어는 자유의 만끼함 대신에 잘못짜면 각종 오류와 잠정적인 무한루프등 고려사항이 많이 등장합니다.

========================================
* The truth will set you free.

creativeidler의 이미지

Quote:
c가 처리 속도를 중점적으로 생각하고 만들어진 언어는 아니라고 생각합니다.

제가 아는 지식으로 생각컨데 C언어의 문법은 속도를 희생하지 않으면서 인간에 가까워질 수 있는 그 극한에 있습니다. 이보다 더 인간에 가까운 문법으로 C언어보다 더 빠르게 만드는 것은 거의 불가능에 가까울 겁니다.

머, 그래도 대충 짜면 Perl이 더 빠를 수도 있죠.

ykish의 이미지

언제나 이런 종류의 문제는 흥미진진하군요. 답글수만 보아도..

펄을 많이 써보진 않았지만, 제가 아는 바로는 그거 인터프리터 언어거든요. 인터프리터 언어가 컴파일러 보다 빠르다는 거는 들어본적이 없는 얘기라 살짝 흥분할 뻔했습니다.

그런데 여기서 얘기하려는 건 그런 원론적인 얘기를 하려는건 아니겠지요.

원칙적으로 C가 빨라야 겠지만, perl이 빠른 경우가 있는 것은 잘짜여진 라이브러리 때문이라고 단언할 수 있습니다. 빠르다고 하는 perl의 내부함수들이 perl로 짜여져 있지는 않을꺼라 생각합니다. 아마 C나 뭐 그런 컴파일러로 되어 있을 겁니다. 전문가들이 짜논 알고리즘이 잘된 라이브러리를 쓰기 때문에 더 빠를 수도 있는거고, 솔직히 같은 라이브러리를 쓴다면 서로 속도가 비슷하겠죠. 사실 논란거리가 없는 겁니다.

하지만 문제는 직접 구현하는 알고리즘이지요.
루틴의 실행 라인수가 많은 상태에서 같은 알고리즘의 C와 Perl은 어느게 더 빠를까요?
특히 루프를 많이 돌려야 하는 부분이라면 차이는 극명해집니다. 그런경우라면 Perl은 찍소리도 못한다는데 1000원 걸겠습니다.

Perl이 속도가 빠르게 하려면 라이브러리를 바로 쓸수 있는데에서는 절대 직접 코드로 구현하면 안될것입니다. 있는 기능만 잘활용하면 Perl을 써도 문제가 없겠죠. 저는 특정 언어를 고집하는 주의는 절대 아닙니다.

예전에 VB를 쓰다가 엄청 놀란적이 있는데, VB가 컴파일언어임에도 불구하고 C에 비해 1000배도 느려질수 있다는 걸 알았는데, 그게 루프를 N번을 돌리는 루틴때문이었습니다. 대신 기존 API하나로 처리하도록 바꿨더니 1/N로 실행시간이 줄어버리더군요.
루프 정말 조심해야 합니다. 꼭 기억하세요.

익명 사용자의 이미지

ykish wrote:
언제나 이런 종류의 문제는 흥미진진하군요. 답글수만 보아도..

펄을 많이 써보진 않았지만, 제가 아는 바로는 그거 인터프리터 언어거든요. 인터프리터 언어가 컴파일러 보다 빠르다는 거는 들어본적이 없는 얘기라 살짝 흥분할 뻔했습니다.

그런데 여기서 얘기하려는 건 그런 원론적인 얘기를 하려는건 아니겠지요.

원칙적으로 C가 빨라야 겠지만, perl이 빠른 경우가 있는 것은 잘짜여진 라이브러리 때문이라고 단언할 수 있습니다. 빠르다고 하는 perl의 내부함수들이 perl로 짜여져 있지는 않을꺼라 생각합니다. 아마 C나 뭐 그런 컴파일러로 되어 있을 겁니다. 전문가들이 짜논 알고리즘이 잘된 라이브러리를 쓰기 때문에 더 빠를 수도 있는거고, 솔직히 같은 라이브러리를 쓴다면 서로 속도가 비슷하겠죠. 사실 논란거리가 없는 겁니다.

하지만 문제는 직접 구현하는 알고리즘이지요.
루틴의 실행 라인수가 많은 상태에서 같은 알고리즘의 C와 Perl은 어느게 더 빠를까요?
특히 루프를 많이 돌려야 하는 부분이라면 차이는 극명해집니다. 그런경우라면 Perl은 찍소리도 못한다는데 1000원 걸겠습니다.

Perl이 속도가 빠르게 하려면 라이브러리를 바로 쓸수 있는데에서는 절대 직접 코드로 구현하면 안될것입니다. 있는 기능만 잘활용하면 Perl을 써도 문제가 없겠죠. 저는 특정 언어를 고집하는 주의는 절대 아닙니다.

예전에 VB를 쓰다가 엄청 놀란적이 있는데, VB가 컴파일언어임에도 불구하고 C에 비해 1000배도 느려질수 있다는 걸 알았는데, 그게 루프를 N번을 돌리는 루틴때문이었습니다. 대신 기존 API하나로 처리하도록 바꿨더니 1/N로 실행시간이 줄어버리더군요.
루프 정말 조심해야 합니다. 꼭 기억하세요.

정리 좀 해주세요. 당췌 무슨 말씀이신지?

익명 사용자의 이미지

정리!...?

Quote:

...
정리 좀 해주세요. 당췌 무슨 말씀이신지?

"프로그래밍 언어 자체에 대해 특정적인 속도에 연연하기 보다는 좋은 알고리듬을 항상 고려하여야 한다" 가 요약이 아닐까 합니다.

고급언어의 장점이라면 바로 코딩시간을 줄여서 절약한 시간에 더 좋은 알고리듬을 생각해낼 시간을 벌어준다는 것이죠. C로 하루 걸리는 것을 Perl로 2-3시간 걸린다고 했을 때 그 절약된 시간을 더 적합한 알고리듬을 찾는데 사용한다면 C로 하루 걸린 프로그램을 알고리듬 상으로 능가하여 더 나은 수행속도를 경험 할 수도 있다는 겁니다.

eminency의 이미지

손님아 wrote:
ykish wrote:
언제나 이런 종류의 문제는 흥미진진하군요. 답글수만 보아도..

펄을 많이 써보진 않았지만, 제가 아는 바로는 그거 인터프리터 언어거든요. 인터프리터 언어가 컴파일러 보다 빠르다는 거는 들어본적이 없는 얘기라 살짝 흥분할 뻔했습니다.

그런데 여기서 얘기하려는 건 그런 원론적인 얘기를 하려는건 아니겠지요.

원칙적으로 C가 빨라야 겠지만, perl이 빠른 경우가 있는 것은 잘짜여진 라이브러리 때문이라고 단언할 수 있습니다. 빠르다고 하는 perl의 내부함수들이 perl로 짜여져 있지는 않을꺼라 생각합니다. 아마 C나 뭐 그런 컴파일러로 되어 있을 겁니다. 전문가들이 짜논 알고리즘이 잘된 라이브러리를 쓰기 때문에 더 빠를 수도 있는거고, 솔직히 같은 라이브러리를 쓴다면 서로 속도가 비슷하겠죠. 사실 논란거리가 없는 겁니다.

하지만 문제는 직접 구현하는 알고리즘이지요.
루틴의 실행 라인수가 많은 상태에서 같은 알고리즘의 C와 Perl은 어느게 더 빠를까요?
특히 루프를 많이 돌려야 하는 부분이라면 차이는 극명해집니다. 그런경우라면 Perl은 찍소리도 못한다는데 1000원 걸겠습니다.

Perl이 속도가 빠르게 하려면 라이브러리를 바로 쓸수 있는데에서는 절대 직접 코드로 구현하면 안될것입니다. 있는 기능만 잘활용하면 Perl을 써도 문제가 없겠죠. 저는 특정 언어를 고집하는 주의는 절대 아닙니다.

예전에 VB를 쓰다가 엄청 놀란적이 있는데, VB가 컴파일언어임에도 불구하고 C에 비해 1000배도 느려질수 있다는 걸 알았는데, 그게 루프를 N번을 돌리는 루틴때문이었습니다. 대신 기존 API하나로 처리하도록 바꿨더니 1/N로 실행시간이 줄어버리더군요.
루프 정말 조심해야 합니다. 꼭 기억하세요.

정리 좀 해주세요. 당췌 무슨 말씀이신지?

루프를 조심하라는군요. 중간 내용은 저도 잘 이해가 안되지만..-_- 루프 얘기 빼면 이것도 원론적인 얘기 같은데요...;

노루가 사냥꾼의 손에서 벗어나는 것 같이, 새가 그물치는 자의 손에서 벗어나는 것 같이 스스로 구원하라 -잠언 6:5

7339989b62a014c4ce6e31b3540bc7b5f06455024f22753f6235c935e8e5의 이미지

스크립트 언어의 (작성) 효율성과 C의 속도를 동시에 잡을 수 있는 방법은 없을까요? :)
이를테면, 스크립트를 C 코드로 변환준다던가요. (이미 있을 것 같은 예감이...~_~)

근데 저는 아주 속도가 중요한 부분이 아니라면, 펄을 선택하겠습니다.

lifthrasiir의 이미지

ditto wrote:

스크립트 언어의 (작성) 효율성과 C의 속도를 동시에 잡을 수 있는 방법은 없을까요?
이를테면, 스크립트를 C 코드로 변환준다던가요. (이미 있을 것 같은 예감이...~_~)

근데 저는 아주 속도가 중요한 부분이 아니라면, 펄을 선택하겠습니다.

pyrex 같은 게 좀 도움이 될 수 있을 것 같습니다. 그리고 컴파일을 지원하는 언어 중에도 꽤 쓸만한 게 많았던 걸로 기억합니다.

- 토끼군

덤: 근데... 자동으로 quote 붙는 게 안 되네요 이런 줸장 -,.-

wslee의 이미지

ditto wrote:
스크립트 언어의 (작성) 효율성과 C의 속도를 동시에 잡을 수 있는 방법은 없을까요? :)
이를테면, 스크립트를 C 코드로 변환준다던가요. (이미 있을 것 같은 예감이...~_~)

근데 저는 아주 속도가 중요한 부분이 아니라면, 펄을 선택하겠습니다.

펄로짜다가 효율성과 속도가 중요한
어마어마어마 무지막대한 루프가 그것도 아주 자주 많이 반복
종종 불러써야하는 상황이 된다면.
고 부분만 뚝 떼서 c로 짜면
ok~

꼬마앙마의 이미지

프로그래밍 언어에서 아직까지 속도가 주요 논쟁이 될줄은 몰랐네요.

만약에 복잡한 프로그래밍을 각각 C와 Perl로 작성했을때

C는 6시간, Perl은 12시간, Python은 15시간이 걸린다고 칩시다.

저라면 Perl이나 Python을 선택하겠습니다.

적어도 정확하게 돌아가는 C프로그램을 만들기 위해서는 Perl보다는 2배의 시간이 걸릴것 같거든요.

Python보다 3배의 시간이 걸리겠죠.

그리고 결정적인것은 제가 작성한 C프로그램이 정확하게 동작하기 위해서

Perl이나 Python보다 수배나 더 테스트를 반복해야 한다는 겁니다.

ㅡ,.ㅡ;;의 이미지

저같으면 무조건 C로 짭니다 시간이 두배 세배 걸리더라두요..

만일 8시간안에 결과가 나와야되는것이라면요...
예를들어 어제의 데이터를 오늘 아침 9시전까지 다른업체에 보내야한다면요..

이런경우도 있습니다. 밤12시에 작업해서 결과나올때까지 집에못갑니다..ㅡㅡ;;

위의경우는 실무에서 종종 대두되는 문제구요...

위문제가 아니라 하더라도 1억장비에서 12시간돌려야되니까 시간단축하려면.. 장비를 2억짜리 구해야 되는경우가 있겠죠..
C로 짜면 1억번다는결론이되겠죠?

또한 시간을 단축하기위해 하드웨어적으로 업그래이드 하는것은 한계가 있습니다. 정말많이 투자해봐야 두세배빨라지기도 힘들죠...
그러나 소프트웨어적으로 해결하는것은 수십배 수백배 빨라 질수 도 있습니다.
또한 언어의 문법적인 차이가 Logic 의 차이를 불러오죠..

하드웨어 사양이 작업량에 비해 월등하여 성능개선이 전혀불필요한경우도 마찬가지입니다.
그럴겨우 1억장비구할것을 5000만원짜리 구해도 될테니까요...


----------------------------------------------------------------------------

지나가다가의 이미지

질문하신분이 어떤 것을 프로그래밍하실지 모르지만..
적어도 속도차를 생각한다는 작은 것을 프로그래밍한다고 생각되지 않아서 몇자 적습니다..
유지보수가 특별히 필요 없고 목적이 퍼포먼스다면 구현하기 편하게 C와 Perl을 섞어서 프로그래밍하면서 기계어를 섞는게 낮지 않을까요?

hokim의 이미지

http://root.cern.ch/root/Cint.html

cint를 사용하면 동일한 c/c++ 코드를 인터프리터방식으로 실행이 가능하고 컴파일에 의한 것과 비교가 가능합니다. 제가 time을 가지고 두가지방식을 직접비교해 보았을때 컴파일방식이 인터프리터 방식보다 약 70배 정도 빠른 결과가 나오더군요. cint자체의 퍼포먼스가 하나의 팩터로 작용할 수는 있으나 근본적으로 컴파일방식이 인터프리터방식을 실행속도면에서는 월등한 퍼포먼스를 보이는 것같습니다.

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.