64비트 컴퓨터의 활용성 ( 내지는 효용성 ) 이 뛰어난가요?

오리주둥이의 이미지

요즘 모두들 컴을 업그레이드 할때 64비트 환경으로 넘어가는것 같습니다. ( 여러 스레드를 보니 그런거 같아서요.)

그런데 갑자기 의문이 들어서요.
32비트와의 관계를 따졌을때 64 비트라는것은 2의 64제곱이라는 개념이기 때문에
두배의 속도 개선이 아니라 비약적인 속도개선이라는것은 인정을 합니다.
하지만 cpu만 64비트가 되었다고 해서 그 속도만큼의 컴퓨터가 되는가 하는 의문이 듭니다.
일단 메인보드가 뒷바침을 해줘야 하고 (아주 당연한 이야기 입니다만. -_-; )
그외에 메인보드에 사정없이 꽃히는 각종 카드들이 64비트가 되어야 하지 않겠습니까.
또한 소프트웨어 역시 64비트를 지원하지 않는이상 소용이 없지 않는가 하는 생각이 들어서요.

물론 앞으로 64비트로 모든것이 변할것은 사실이지만 현재 64비트 컴을 구입을 하는것이
과연 현실적으로 현명한 판단인가 하는 생각이 듭니다.

몇년 후 를 내다보고 구입을 한다면 할말이 없는건 사실입니다만
그 몇년 후가 2, 3년이 될 지, 아니면 4, 5년이 될지는 모르겠거든요.
만약 4,5년 이후라면 차라리 저렴하게 32비트 컴퓨터로 가고 그때가서 업그레이드가 아니라
새로 구입을 하는것이 오히려 경제적이고 현실적인 생각이 아닐까 합니다.

과연 현재의 64비트 컴퓨터가 그만큼의 성능을 내는것일까요?

P/S 위의 얘기는 개인적으로 생각한 내용입니다. 틀린 내용이 있으면 넓게 이해해 주시고 설명해 주세요.
알지도 못한다고 구박하시면 어여쁜 가슴에 상처가 남아요. 잉잉~

jyoung의 이미지

64비트 CPU가 두배의(혹은 2^32)의 속도 개선이 있는 것은 아닙니다. (만약 그랬다면 이미 수만 비트의 CPU를 쓰고 있겠죠. :))
가장 기본적인 차이는 64비트 크기의 데이터가 있는 경우 기존의 32비트 CPU에서는 2번 혹은 그 이상의 계산이 필요한 일을 단 한번에 처리한다는 점입니다.(그렇다고 2배 빨라지는 것은 아닐겁니다. 한번의 64비트 계산은 한번의 32비트 계산보다 오래걸리니까요.) 그래서, 실제로 속도상의 이득을 얻을 수 있는 것은 암/복호화 프로그램 같이 큰 자리수의 연산이 필요한 경우이고 그 이외에 경우에는 오히려 속도가 떨어질 수도 있습니다.
제가 생각하는 64비트가 필요한 이유는 기존의 32비트로 표현할 수 있는 숫자의 크기가 제한되어 있기 때문인데요. 그 한 예로 현재 시간을 표시하는데 사용되는 time_t가 32비트인 경우에는 2038년까지밖에 나타낼 수 없다는 것이 있습니다.(그 이외에도 Windows에서 2TB까지 하드디스크 용량을 표시할 수 없다는 점, 32비트로는 4GB의 메모리까지 addressing이 가능하다는 점 등이 있습니다.)
기존에 8비트 CPU나 16비트 CPU의 경우에는 메인 모드상의 데이터 전송 폭 자체가 CPU와 동일하게 되어 있는 경우가 많아서 CPU에 따라서 보드 및 카드도 달라져야 하는 경우가 있었는데요. 요즘은 CPU에서의 연산의 단위와 CPU와 메모리 혹은 카드간의 전송 단위가 다르기 때문에 CPU가 바뀐다고 해서 카드나 메모리가 바뀔 필요는 없습니다.
소프트웨어의 경우에는 64비트를 지원하는 소프트웨어를 사용하는것이 중요합니다. 실제로 OS를 64비트 지원하는 것을 설치하지 않으면 32비트 모드로만 동작하는 CPU도 있으니까요. 64비트 연산을 위한 명령어들을 사용한 소프트웨어를 사용하지 않으면 64비트 CPU를 사는 것이 별 의미가 없겠죠.

될대로 되라지..

오리주둥이의 이미지

jyoung wrote:
64비트 CPU가 두배의(혹은 2^32)의 속도 개선이 있는 것은 아닙니다. (만약 그랬다면 이미 수만 비트의 CPU를 쓰고 있겠죠. :))
가장 기본적인 차이는 64비트 크기의 데이터가 있는 경우 기존의 32비트 CPU에서는 2번 혹은 그 이상의 계산이 필요한 일을 단 한번에 처리한다는 점입니다.(그렇다고 2배 빨라지는 것은 아닐겁니다. 한번의 64비트 계산은 한번의 32비트 계산보다 오래걸리니까요.) 그래서, 실제로 속도상의 이득을 얻을 수 있는 것은 암/복호화 프로그램 같이 큰 자리수의 연산이 필요한 경우이고 그 이외에 경우에는 오히려 속도가 떨어질 수도 있습니다.
제가 생각하는 64비트가 필요한 이유는 기존의 32비트로 표현할 수 있는 숫자의 크기가 제한되어 있기 때문인데요. 그 한 예로 현재 시간을 표시하는데 사용되는 time_t가 32비트인 경우에는 2038년까지밖에 나타낼 수 없다는 것이 있습니다.(그 이외에도 Windows에서 2TB까지 하드디스크 용량을 표시할 수 없다는 점, 32비트로는 4GB의 메모리까지 addressing이 가능하다는 점 등이 있습니다.)
기존에 8비트 CPU나 16비트 CPU의 경우에는 메인 모드상의 데이터 전송 폭 자체가 CPU와 동일하게 되어 있는 경우가 많아서 CPU에 따라서 보드 및 카드도 달라져야 하는 경우가 있었는데요. 요즘은 CPU에서의 연산의 단위와 CPU와 메모리 혹은 카드간의 전송 단위가 다르기 때문에 CPU가 바뀐다고 해서 카드나 메모리가 바뀔 필요는 없습니다.
소프트웨어의 경우에는 64비트를 지원하는 소프트웨어를 사용하는것이 중요합니다. 실제로 OS를 64비트 지원하는 것을 설치하지 않으면 32비트 모드로만 동작하는 CPU도 있으니까요. 64비트 연산을 위한 명령어들을 사용한 소프트웨어를 사용하지 않으면 64비트 CPU를 사는 것이 별 의미가 없겠죠.

역시나 소프트웨어도 64비트로 넘어가야겠군요.

그런데 의문이 드는 부분이 있습니다. 카드에 대해서는 의문이 듭니다.
cpu가 64비트의 성능을 가지고 있다면, 특히나 그래픽의 경우는 그 막대한 데이터를 처리를 하려면 결국
cpu 보다는 그래픽카드의 gpu에 의존을 하게되는것은 당연한것인데
그래픽 카드가 32비트라면 그 부담을 당연히 cpu가 가져갔을때의 성능저하는 역시나 의심이 됩니다.
특히 저처럼 듀얼 모니터를 사용하는 사람이라면 더욱 그럴것이라고 보거든요.

그래서 저는 개인적으로 모든 체제 ( 하드웨어, OS, 소프트웨어 ) 가 64비트로 전환이 되지 않는 이상은
cpu만의 64비트 변화가 크나큰 성능의 개선을 보여주리라 생각하지 않습니다.

amd가 32비트를 지원한다고는 하지만 그것은 32비트의 소프트웨어와 하드웨어도 수용한다는것이지
그러한 것들을 64비트의 성능을 내도록 한다는것은 아니지 않습니까?

글을 적다보니 정작 궁금한것이 이것이였군요. -_-;;;

익명 사용자의 이미지

32빗 지원안하고 당장 64만되는 버전나오면 아이테니엄 꼴나져

eezen의 이미지

며칠 사용했지만 뭐가 좋은 건지 전혀 모릅니다. 사실 저 개인적으로는 왜 돈 더 더주고 3기가 이상 되는 놈을 샀느냐? 1기가짜리 하고 성능 차이가 나냐?고 물어도 할말이 없는 상태입니다. 컴퓨터를 심하게 부려먹을 일도 없으니까요.

그런데 32비트 cpu가 저렴하기는 한가요? 제가 구입하면서 보니 64비트와 32비트 사이에 가격차가 별로 없었습니다. (그렇게 봤기에 이왕이면 하고 64비트로 구입했지요 ^^)
제가 잘못 안 것이 아니라면 성능차이가 별로 없어도 뭐 상관없는 셈이죠.

그런데 소프트웨어가 32비트만 지원하는 경우가 많아서 아직 불편하기는 합니다. 파이어폭스는 64비트가 있지만 플러그인 때문에 32비트를 써야 하는데, 성능의 차이는 모르겠지만, 불편하다는 것이죠.

hyperhidrosis의 이미지

소프트웨어가 64비트로 컴파일 되었다고 더 빨라지는건 아닙니다.
소프트웨어 내에서 64비트 처리를 할 경우, 기존 32비트 프로그램은
32비트 레지스터로 여러번 처리할것을 한번에 처리할수 있기 때문에
빨라질 수도 있다는 겁니다.

만일 프로그램 내에서 int64 나 longlong 타입을 한번도 쓴적이 없다면...
32비트로 컴파일 했건 64비트로 컴파일 했건 속도차이는 거의 없습니다.

메모리를 4기가 이상 쓰는 서버프로그램이나 동영상 편집 소프트웨어,
내부적으로 64비트 최적화가 된 멀티미디어 프로그램이 아닌이상..
단순이 int 타입만 쓰는 프로그램은 속도 향상이 없습니다.

대부분의 일반 어플리케이션은 32비트 타입으로 내부 데이타를
다 처리할 수 있기 때문에 64비트로 컴파일해도 속도향상이 없죠.

uriel의 이미지

64비트로 올라가서 빨라지는 것은 OS와 어플리케이션이 모두 64비트로 되어 있을 때에 그래픽 랜더링 쪽 등에서 가장 쉽게 느낄 수 있습니다. 64비트 리눅스 배포판에서 김프를 띄워 보면 정말 빨리 뜨죠. (32비트 불여우보다 김프가 훨씬 더 빨리 뜹니다) 실제 동작 속도도 필터링이나 이미지 처리 쪽은 정말 빠릅니다.

P.S. OS가 64비트라면 하드 디스크의 데이타 억세스가 좀 더 빠르다는 이야기가 있긴 합니다.

kornet의 이미지

jyoung wrote:
가장 기본적인 차이는 64비트 크기의 데이터가 있는 경우 기존의 32비트 CPU에서는 2번 혹은 그 이상의 계산이 필요한 일을 단 한번에 처리한다는 점입니다.(그렇다고 2배 빨라지는 것은 아닐겁니다. 한번의 64비트 계산은 한번의 32비트 계산보다 오래걸리니까요.)

궁금해서 그러는데요. 64비트 cpu라면 32비트 연산과 64비트 연산이 속도가 같지 않나요? 32비트의 경우, 많은 32비트 cpu들이 16비트나 8비트 정수의 덧셈을 16비트나 8비트끼리가 아닌 32비트 정수간의 덧셈으로 처리한다고 알거든요. 아니면 64비트 cpu는 64비트건 32비트건 cpu 자체가 연산이 더 느리다는 뜻인가요? 가산기 자체가 비트수가 높아진다고 느릴 이유는 없지 않나? 혹은 64비트 연산시에는 메모리에서 32비트가 아닌 64비트를 가져와야 하기 때문에 데이터 가져오는 속도가 느리다는 이야기? 아, 이것도 보통 32비트 cpu에서 메모리에서 8비트 데이터를 가져올 때 32비트짜리 한 개의 워드를 통째로 가져오듯이 64비트도 32비트를 64비트짜리 묶음으로 가져오지 않나요? 아니면 파이프라인과 클럭과 발열 문제까지 나오나요? 64비트가 더 느린 이유가 궁금합니다~.

warpdory의 이미지

이번에 AMD64 베니스 3000+ + 메인보드 으로 바꿨습니다.

바꾼 이유는 ..

비슷한 성능대의 32비트 CPU + 메인보드 보다 값도 싸고, 메인보드에서 기본적으로 지원하는 것도 많았기 때문입니다. 게다가 베니스 CPU 의 경우는 오히려 32비트 CPU 보다 발열문제도 덜하더군요. - 이건 벤치마크를 찾아본 결과입니다. 실제로도 그럴지는 써 봐야 아는 건데, 어젯밤에 작업하면서 CPU 온도가 38 도 이상으로 올라가지는 않더군요. 바톤 2500+ 는 거의 42도 유지였는데... 4도 정도니깐 오차 범위라고 할 수도 있겠지만, 어쨌든 낮은 온도겠죠.
- 값은 CPU + 메인보드 + 잡다부품 몇개(케이블, 커넥터 등등)해서 24만원도 안 들더군요.

어차피 게임 같은 건 xbox 에서 하니깐 별 신경 안 쓰고...

젠투에서 AMD 32비트용으로 되어 있던 것을(athlon-xp 였습니다. 바톤 2500+) 현재 AMD64 용으로 바꾸고 있습니다.
make.conf 에서 CHOST 와 CFLAGS 를 좀 바꾸고 USE flag 도 좀 바꾸고 ... emerge -eD world && emerge --newuse world
해두고 왔는데...

에러가 날지, 제대로 다 될지는 있다가 집에 가보면 알겠지요. 안되면 설정 파일만 백업 받고 다시 깔면 되는 거죠. (씨디도 다시 다 구워뒀으니깐...)

그리고 .. 부팅할 때 뽀다구가 장난 아닙니다. 64비트 ! 떡하니 찍히고, 메모리 체크하면서 듀얼 채널 128비트 뜨는 거 처음 보면서 .. 캬 ... 했습니다.


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.

kornet의 이미지

오리주둥이 wrote:
jyoung wrote:
64비트 CPU가 두배의(혹은 2^32)의 속도 개선이 있는 것은 아닙니다. (만약 그랬다면 이미 수만 비트의 CPU를 쓰고 있겠죠. :))
가장 기본적인 차이는 64비트 크기의 데이터가 있는 경우 기존의 32비트 CPU에서는 2번 혹은 그 이상의 계산이 필요한 일을 단 한번에 처리한다는 점입니다.(그렇다고 2배 빨라지는 것은 아닐겁니다. 한번의 64비트 계산은 한번의 32비트 계산보다 오래걸리니까요.) 그래서, 실제로 속도상의 이득을 얻을 수 있는 것은 암/복호화 프로그램 같이 큰 자리수의 연산이 필요한 경우이고 그 이외에 경우에는 오히려 속도가 떨어질 수도 있습니다.
제가 생각하는 64비트가 필요한 이유는 기존의 32비트로 표현할 수 있는 숫자의 크기가 제한되어 있기 때문인데요. 그 한 예로 현재 시간을 표시하는데 사용되는 time_t가 32비트인 경우에는 2038년까지밖에 나타낼 수 없다는 것이 있습니다.(그 이외에도 Windows에서 2TB까지 하드디스크 용량을 표시할 수 없다는 점, 32비트로는 4GB의 메모리까지 addressing이 가능하다는 점 등이 있습니다.)
기존에 8비트 CPU나 16비트 CPU의 경우에는 메인 모드상의 데이터 전송 폭 자체가 CPU와 동일하게 되어 있는 경우가 많아서 CPU에 따라서 보드 및 카드도 달라져야 하는 경우가 있었는데요. 요즘은 CPU에서의 연산의 단위와 CPU와 메모리 혹은 카드간의 전송 단위가 다르기 때문에 CPU가 바뀐다고 해서 카드나 메모리가 바뀔 필요는 없습니다.
소프트웨어의 경우에는 64비트를 지원하는 소프트웨어를 사용하는것이 중요합니다. 실제로 OS를 64비트 지원하는 것을 설치하지 않으면 32비트 모드로만 동작하는 CPU도 있으니까요. 64비트 연산을 위한 명령어들을 사용한 소프트웨어를 사용하지 않으면 64비트 CPU를 사는 것이 별 의미가 없겠죠.

그런데 의문이 드는 부분이 있습니다. 카드에 대해서는 의문이 듭니다.
cpu가 64비트의 성능을 가지고 있다면, 특히나 그래픽의 경우는 그 막대한 데이터를 처리를 하려면 결국
cpu 보다는 그래픽카드의 gpu에 의존을 하게되는것은 당연한것인데
그래픽 카드가 32비트라면 그 부담을 당연히 cpu가 가져갔을때의 성능저하는 역시나 의심이 됩니다.

그래픽 카드는 필요에 따라 128비트나 256비트의 연산장치가 들어있을 것입니다. 범용기가 아니니까요. PCI나 AGP 버스만 해도 64비트 이상 아니었던가요? 게임기 같은 경우 수년 전부터 128 비트라고 홍보하고 있는 것으로..

익명 사용자의 이미지

전 현제 amd 64 x2듀얼코어 3800쓰는데
보통 52도네여 ㅡㅡ 이거 정상인가여?

익명 사용자의 이미지

한 29~41도정도유지되는군여 다시보니 ㅡㅡ

오리주둥이의 이미지

Anonymous wrote:
전 현제 amd 64 x2듀얼코어 3800쓰는데
보통 52도네여 ㅡㅡ 이거 정상인가여?

-_-;; 52도면 amd쪽에서는 낮은 발열입니다. -_-;

오리주둥이의 이미지

uriel wrote:
64비트로 올라가서 빨라지는 것은 OS와 어플리케이션이 모두 64비트로 되어 있을 때에 그래픽 랜더링 쪽 등에서 가장 쉽게 느낄 수 있습니다. 64비트 리눅스 배포판에서 김프를 띄워 보면 정말 빨리 뜨죠. (32비트 불여우보다 김프가 훨씬 더 빨리 뜹니다) 실제 동작 속도도 필터링이나 이미지 처리 쪽은 정말 빠릅니다.

P.S. OS가 64비트라면 하드 디스크의 데이타 억세스가 좀 더 빠르다는 이야기가 있긴 합니다.

역시 생각했던데로군요.
아직까지는 성급한 업글이나 구입이 필요없을것 같다는 생각이 드네요.

혹시나 다음 쓰레드가 어떻게 나올지는 모르겠지만..-_-;

IsExist의 이미지

AMD가 온도가 낮은거 동작 Mhz가 낮아서 그런게 아닌지.
소위 말하는 실 동작 클럭이 낮지요.

그에 비해서 동급의 Intel CPU들은 3.0 은 기본이니..

---------
간디가 말한 우리를 파괴시키는 7가지 요소

첫째, 노동 없는 부(富)/둘째, 양심 없는 쾌락
셋째, 인격 없는 지! 식/넷째, 윤리 없는 비지니스

이익추구를 위해서라면..

다섯째, 인성(人性)없는 과학
여섯째, 희생 없는 종교/일곱째, 신념 없는 정치

bus710의 이미지

역시, "이왕에 바꾸니까 64로 가자" 가 주된 이유되겠습니다^^

life is only one time

warpdory의 이미지

IsExist wrote:
AMD가 온도가 낮은거 동작 Mhz가 낮아서 그런게 아닌지.
소위 말하는 실 동작 클럭이 낮지요.

그에 비해서 동급의 Intel CPU들은 3.0 은 기본이니..

반대로 보면 인텔은 클럭만 높지 성능은 그것에 미치지 못한다고 볼 수도 있습니다.

정확한 비례는 아니지만, 바톤 2500+ 쓸 때 인텔 펜티엄 4 2.6G 보다 대체적으로 빨랐다고 느꼈었는데(실제로도 벤치 마크같은 것 말고도 시뮬레이션 동작 속도 같은 게 미미하나마 빨랐습니다.) 바톤 2500+ 의 클럭 속도는 1.8GHz 정도이니까요.


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.

익명 사용자의 이미지

kornet wrote:
jyoung wrote:
가장 기본적인 차이는 64비트 크기의 데이터가 있는 경우 기존의 32비트 CPU에서는 2번 혹은 그 이상의 계산이 필요한 일을 단 한번에 처리한다는 점입니다.(그렇다고 2배 빨라지는 것은 아닐겁니다. 한번의 64비트 계산은 한번의 32비트 계산보다 오래걸리니까요.)

궁금해서 그러는데요. 64비트 cpu라면 32비트 연산과 64비트 연산이 속도가 같지 않나요? 32비트의 경우, 많은 32비트 cpu들이 16비트나 8비트 정수의 덧셈을 16비트나 8비트끼리가 아닌 32비트 정수간의 덧셈으로 처리한다고 알거든요. 아니면 64비트 cpu는 64비트건 32비트건 cpu 자체가 연산이 더 느리다는 뜻인가요? 가산기 자체가 비트수가 높아진다고 느릴 이유는 없지 않나? 혹은 64비트 연산시에는 메모리에서 32비트가 아닌 64비트를 가져와야 하기 때문에 데이터 가져오는 속도가 느리다는 이야기? 아, 이것도 보통 32비트 cpu에서 메모리에서 8비트 데이터를 가져올 때 32비트짜리 한 개의 워드를 통째로 가져오듯이 64비트도 32비트를 64비트짜리 묶음으로 가져오지 않나요? 아니면 파이프라인과 클럭과 발열 문제까지 나오나요? 64비트가 더 느린 이유가 궁금합니다~.

흠.. 제가 좀 단순하게 생각했던걸지도 모르겠네요. 순수하게 ALU(arithmetic-logic unit)에 경우만 생각해 보면, 일단 덧셈의 경우에는 n-bit 덧셈을 ALU에서 하는데 걸리는 시간은 보통 log(n)에 비례합니다. 그래서 64bit 덧셈은 32bit덧셈에 비해서 다소(log이기 때문에 많이 늘어나지는 않습니다.) 늘어나게 되겠죠. ALU가 파이프라인에서 Bottleneck은 아닌것으로 알고 있습니다만, 만일 이 ALU의 연산에 걸리는 시간이 늘어나는 것 때문에 CLOCK을 늘려야 한다면 CPU의 동작 속도도 늦어지겠죠.
메모리와의 데이터 전송은 주로 Cache를 통해서 이루어지기 때문에 32비트에서 64비트로 바뀌는 것이 속도에 미치는 영향은 거의 미미할 거 같네요. CPU내부에서는 64비트 단위로 전송될테니까요.

owlet의 이미지

64bit라도 덧셈의 연산시간은 한클럭에 훨씬 못미칩니다.
따라서 32bit나 64bit모두 덧셈은 한클럭짜리 동작이고 동작속도에는 영향을 주지않습니다.

lacovnk의 이미지

전 무엇보다도, 4G memory의 한계가 일찍 오지 않을까.. 걱정&기대 됩니다 :)

익명의 이미지

분명 cpu의 입장에서 보면 다룰수 있는 데이터의 폭이 64비트가 된다면
32비트 두번 할일을 한번에 처리할수 있기때문에 2배의 성능이라고 봐야하는겁니다.

하지만, 문제는 cpu혼자서 그렇게 열심히 일을한다고 해도, 주위에선 놀고있다면 사정은 다르지요,
일종의 협동문제라고 본다면 그렇게 될까요, 이어달리기를 한다고 보면
무지빠른선수가 한바퀴 돌고 바톤을 넘겼는데, 바톤을 넘겨받은 선수가 느리다면
아무리 빠른 선수가 열심히 했다고 해도 무용지물이 되었다고 봐야하는겁니다.

cpu가 바뀌었으니,주변 놈들도 이젠 비트수를 늘려야 될때가 된것같습니다. 이제 시작이라고
봐야겠네요..

ps-폭이 넓어졌다고 해서 alu의 구조가 바뀐것은 아니고, 더 넓어졌고, cpu의 공정기술이 좋아졌다는
얘기지요, 서서히 좋아져야지 급격히 비트수 늘리면 지금의 규격이나 업체들이나 폭동일으킬지 모릅니다;
인텔도 그걸 아니까 비트늘리기보단 지 혼자서 성능높이는 기술 많이 모색한거라고 봐야죠.

moonhyunjin의 이미지

리눅스 끼리 웹서버 벤치마크 한것을 보니 64bit가 월등히 좋더군요.

<- 이거면 안되는 게 없어~
정품 소프트웨어 사용 캠패인

<- 이거면 안 되는 게 없어~
정품 소프트웨어 사용 캠패인

댓글 달기

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
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.