페도라 11. 20초 안에 부팅이 목표.

moonhyunjin의 이미지

https://fedoraproject.org/wiki/Releases/11/FeatureList

리눅스 자체가 커스더마이징만 한다면 10초 안으로도 가능하지만,

범용으로서 20초는 의미가 크다고 봅니다.

페도라 무거워서 우분투로 넘어 갔던 분들 많이 돌아오실듯 하네요..

이 소식이 뒷북만 아니였으면 하네요. ^^

kwon37xi의 이미지

저는 페도라가 무거워서가 아니라..
손쉬운 세팅과 무엇보다도 방대한 애플리케이션 저장소 때문에 우분투를 택한 것인데요..

페도라가 무거웠나보군요.

http://kwon37xi.egloos.com

송지석의 이미지

켜놓고 기다리면 하세월..
가상머신에서 쓰려면, 윈도 부팅시키고 하안참 기다려야 합니다.
우분투 만세 ^^
rommance.net

sheep의 이미지

저도 페도라가 무거워서가 아니라

우분투 한번 깔아보고 손쉬운 세팅과 repository 관리가 손쉬워서 바꿨는데...

그때부터 빨간모자나 페도라는 눈밖으로...

--------
From Buenos Aires, Argentina
No sere feliz pero tengo computadora.... jaja
닥치고 Ubuntu!!!!!
To Serve My Lord Jesus
blog: http://sehoonpark.com.ar
http://me2day.net/sheep

--------
From Buenos Aires, Argentina
No sere feliz pero tengo computadora.... jaja
닥치고 Ubuntu!!!!!
To Serve My Lord Jesus
blog: http://sehoonpark.com.ar
http://me2day.net/sheep

inhosens의 이미지


레드햇에서 -> 데비안

우분투까진 필요성을 못느끼고 있습니다. 데비안에 정착한거라 봐도 될 것 같습니다.

superwtk의 이미지

부팅을 빨리 하는걸 목표로 한다길래 SSD 관련 얘기가 나올줄 알았는데, 예상이 빗나갔군요 =)

--------------------------------------------------------------------------------
http://blog.sumin.us

whitelazy의 이미지

전 패키지 관리고 뭐고 없이... 그냥.. yum이 너무 느렸어요....
돌릴때마다 업데이트시켜서.... 이것저것깔때 생각안나서 하나하나 깔면 환장하더군요...

moonhyunjin의 이미지

페도라 기본 미러 서버는 느려서 ftp.sayclub.com으로 바꾸면 빠릅니다.

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

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

지리즈의 이미지

리눅스의 부팅속도를 가속시키는 해결책으로 두가지인데...

init의 병렬화 => init-ng

다음 하나는 ...
하드디스크에 메모리를 저장하는 기술을 이용하는 것인데...
이게 모듈로딩시 충돌같은 많은 문제점을 가지고 있습니다.
이거 보다는 종료시 디스크 캐시 내용만을 swap에 저장했다가...
부팅시 이 내용을 읽어 들이는 방식을 이용하는 겁니다.

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

평양선봉의 이미지

저는 부팅이 빠르다는 것보다,
관리가 편리한게 더 메리트가 있는것 같습니다.
저 역시 RPM(YUM)이 싫어서 DEB(APT)로 왔습니다.

http://www.debian-administration.org/articles/620 - Booting Debian in 14 seconds

Ext4가 기본 파일시스템으로 채택된게 흥미롭네요.
얼마나 안정적일지.. 얼마만큼의 성능을 보여줄지.. :)

----
웹페이지 : http://bzpalm.net/

----
웹페이지 : http://bzpalm.net/

shame2의 이미지

데비안 계열쓰면 레드헷은 구질해서 못쓰겠더라고여 ㅎ

프비 매니아~

Scarecrow의 이미지

페도라 vs 데비안(우분투) 구도의 댓글들이 보입니다만...

오픈소스의 좋은 점은...
페도라에서 저렇게 부팅시간단축을 위해 새로운걸 개발하면...
그걸 데비안(우분투)에도 적용할 수 있다는 점입니다.

어느게 더좋다고 하기보다 응원해주는게 좋을듯...

Necromancer의 이미지

페도라 부팅속도 느린건 인정하지만 우분투 쓰는건 부팅속도보다는 편하게 깔고 편하게 쓰는거죠.
페도라는 이것저것 다 들어간 범용 배포본으로 보시는게 맞습니다.
그만큼 귀찮은 세팅거리들도 많고요.

근데 20초내에 그 많은 데몬들은 다 띄운다는건 대단한거네요.
예전에 LFS에 부팅스크립트 최소화시켜서 Bios Post 직후부터 5초 만에 부팅한적 있습니다.
3초 정도 커널이 로드되고, 1초동안에 하드웨어 초기화메시지뜨고, 나머지 1초는 부팅스크립트 수행하고 로긴메시지 뜨는 시간

이제 윈도맛스타가 쓰는 터보메모리를 리눅스에서 쓸 수 있게 되겠군요.

Written By the Black Knight of Destruction

Written By the Black Knight of Destruction

altromondo의 이미지

Fedora 9에서 10으로 올리면서 이미 엄청난(?) 부팅 속도 개선이 있었지요. 꽤 오래된 제 랩탑을 기준으로, GRUB 화면에서 로그인 매니저(gdm 또는 e17의 entrance) 뜨기까지 80s -> 50s 로 개선되었습니다. 이렇게 부팅 속도가 1 분 이내로 짧아지게 되면서 랩탑 업그레이드의 유혹을 뿌리칠 수 있었죠 ㅎ

아무튼 여전히 Windows XP의 40s에는 못 미치지만, F11에선 어쩌면 새로운 기록을 세울 수도 있겠네요.

moonhyunjin의 이미지

예전부터 RPM가지고 놀던 버릇이 있어서 yum이 더 편하고 제 맘대로 구성을 할 수 있어 좋다라고요.

ubuntu는 그냥 지웠다 깔았다만 하는 수준..

역시 자기가 잘 다루는 게 제일 좋겠죠. ^^

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

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

jj의 이미지

11.20 초 안에 부팅으로 읽었네요...;;
--
Life is short. damn short...

--
Life is short. damn short...

koseph의 이미지

젠투를 주로 써서인가요?

제겐 둘 다 느려터졌더군요.

페도라는 좀 불리하죠. rpm 패키지가 i586이라.... 동일한 코드라도 gcc로 이렇게 패키징 하면 상위기종에선 더 느린게 당연합니다. 아직도 classic Pentium을 돌리고 있는 리눅스 사용자가 세계에 몇 명이나 있을런지.....

gcc를 쓰면서도 gcc의 최적화 루틴을 못 믿겠다는 듯한 이 태도는....

아마 돈이 없어서 Pentium 코어를 쓰고 있다면 그런 나라는 전기가 부족해서라도 리눅스 못 쓸거 같습니다.
인터넷은 말도 못하겠죠. 당연히....

우분투 역시 미시적 수준에서 본다면 최적화 하곤 거리가 멀죠.

제가 이런 말을 꺼내면 잘못해서 또 flame을 유발할 수도 있을 거 같아서....

그나저나 덥군요. 젠투 컴파일 하기엔 정말 덥습니다.
---------------------------------
There's always another way, dear.

---------------------------------
There's always another way, dear.

송효진의 이미지

더운날 좀 더 더울만한 떡밥을 드리죠.
참조
cat /proc/cpuinfo 에서 sse4_1 sse4_2 sse4 cx16 이 있는지 보시고,

flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall lm constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm tpr_shadow vnmi flexpriority

CFLAGS="-march=core2 -O2 -pipe -msse4.1 -mcx16"
이런식으로 세팅해 주세요.
주의할 점은 4_1 이 있다고 해도 msse4 는 하면 안된다는 것입니다.
이것때문에 불여우가 자꾸 죽는 문제가 있었네요.

딱 맞추고 emerge -e --keep-going world; revdep-rebuild -p ㅎㅎ

cpu 혹사시키는 최고의 배포판.

emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇 개 안돼요~
http://xenosi.de/

koseph의 이미지

집에서 쓰고 있는 컴퓨터는 A사의 CPU를 탑재한 관계로 주신 팁은 I당원들 중에서도 고급 당원들이 즐길 특별 메뉴네요.

아직 core2 플래그를 쓸만 컴퓨터는 제가 가지고 있질 않습니다. ㅋㅋㅋ
---------------------------------
There's always another way, dear.

---------------------------------
There's always another way, dear.

sangu의 이미지

cflags 최적화가 부팅속도, 로딩속도에 얼마나 영향을 끼치나요?

참고로 말씀들이면 GCC, glibc 메인테이너들이 Fedora(RedHat) GCC/glibc 패키지를 관리합니다.

https://fedoraproject.org/wiki/Features/F12X86Support - Fedora 12부터는 i686이 기본.
With Fedora 11, we moved the base architecture to i586. With Fedora 12, we are changing the base architecture to i686, and optimizing for current 32-bit processors.

송효진의 이미지

gcc/glibc 패키지를 관리하는것과 rpm 을 최적화 해서 빌드하는것은 별개로 봐야겠죠.

emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇 개 안돼요~
http://xenosi.de/

sangu의 이미지

GCC/glibc 패키지를 관리한다는 것이 패키지"만" 관리하는 것이 아니구요.
rawhide(fedora development)에 GCC/glibc 새 버전이나 스냅샷이 패키지 되서 올라 올때
GCC/glibc에 새로운 기능을 위해서 모든 패키지들의 다시 빌드할 시점을 알려준다거나
새로 발표할 배포판의 기본 cflags을 관리합니다.

젠투의 환상적인 cflags 옵션에 대한 요구가 fedora 메일링에서 종종 나오기는 하지만
fedora(GCC/glibc/kernel) 개발자들은 현재 fedora의 cflags 옵션은 사용하기에
"충분"하다고 생각합니다

송효진의 이미지

그렇다는건 -msse4 같은 옵션이 영향을 줄 수 있는 코드가 거의 없다는거겠네요.
연산을 위한 명령어셋이라고 알고 있는데,
db 에서도 안쓰려나요?
적어도 cairo 에서는 쓰는것 같더군요.

emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇 개 안돼요~
http://xenosi.de/

sangu의 이미지

http://cgit.freedesktop.org/pixman/tree/configure.ac
컴파일 시점에서 sse2까지 체크.

다양한 instruction sets을 이용하기 위해서 jit 필요.
* http://cairographics.org/summerofcode/ideas/ -
We know that we want something that is more dynamic than the current approach of hand-writing optimized MMX/SSE2 functions for special cases.
- http://lists.cairographics.org/archives/cairo/2009-January/016229.html
- http://lists.cairographics.org/archives/cairo/2009-January/016246.html

송효진의 이미지

sse4_1 인데 -msse4.1 에 -msse4 까지 설정했다가 불여우가 죽는 문제가 발생해서 고생했었습니다.
그 때 gdb 로 찍어보면 libcairo 에서 죽었었어요.
관련이 있겠죠?

emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇 개 안돼요~
http://xenosi.de/

정태영의 이미지

사실 sse2, sse3, sse4 같은 스트리밍 인스트럭션들은 명령어 자체가 사용되면서 빨라진다기 보다, 여러 명령어를 동시에 실행시킬 수 있다는 것이 장점입니다.

add 4개를 한꺼번에 처리한다거나 하는 것이 그런 것인데요. 그렇게 하기 위해서는 pack, unpack 등의 과정이 필요하며, 숙달된 사람이 하기에도 그리 간단한 작업들이 아니다보니 컴파일러에서 저런 수준의 최적화를 한다는 것은 아닐거라 생각합니다.

대신 fpu를 사용할 부분에 저런 인스트럭션을 사용하는 것을 생각해볼 수 있겠는데요. 그 정도로는 아주 큰 차이를 보일 순 없을거라 생각합니다. :)

--
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

koseph의 이미지

메인테이너 한테 할 말이긴 한데요........

i586 패키지 헐~~~~ 무슨 석기 시대도 아니고.........

상업용 RHEL은 i686, community OS는 i586 일종의 차별화 인가요?

F12 부터 한다구요???

제가 보기엔 할 수 있는데도 안하고 있었던게 아닌가 싶을 정도 입니다.
---------------------------------
There's always another way, dear.

---------------------------------
There's always another way, dear.

sangu의 이미지

Fedora 11 x86 기본 cflags는 -march=i586 -mtune=generic 입니다.

gcc info에 나온 mtune=generic 옵션에 대한 설명입니다.

Quote:

As new processors are deployed in the marketplace, the
behavior of this option will change. Therefore, if you
upgrade to a newer version of GCC, the code generated option
will change to reflect the processors that were most common
when that version of GCC was released.

GCC 버전이 나올 시점에 시장에 나온 cpu의 인스트럭션 sets을 반영하는 옵션입니다. 님의 오해하시는 것처럼 i386, i586 패키지가 i386, i586 IA instruction sets만을 포함하는 것은 아닙니다.

참고로 Fedora12 x86 기본 cflags는 -march=i686 -mtune=atom
GCC 4.4.x에 - -march=atom/-mtune=atom support from ix86/atom branch를 적용시켰습니다.

koseph의 이미지

저는 페도라를 쓸 때도 src.rpm 가져다가 제가 빌드해서 씁니다.

이유는요??? 제가 다른 글에 적었던 것과 동일합니다. 전 가능한 제 CPU에게 native instruction sets을 주고 싶기 때문이죠. 정 바쁘면 kernel, glibc 그리고 자주 사용하는 서비스는 모두 다시 빌드합니다. 시간이 충분하면 죄다 빌드하죠. 어려운 일도 아니구요.

info gcc에 있는 것을 제가 활용하는 것 뿐입니다.
---------------------------------
There's always another way, dear.

---------------------------------
There's always another way, dear.

sangu의 이미지

1~2% 성능을 위해서 그런한 작업을 원한다면 해야 겠죠.
그리고 그러한 작업이 편한 배포판이 gentoo라고 알고 있습니다.

koseph의 이미지

누가 1~2% 성능을 위해서 그러한 작업을 원한다고 하던가요?

직접 해보고 비교해 봤습니까?

님이 말하는 대로 하자면 RHEL은 겨우 1~2% 성능을 올리기 위해 i686으로 발표하는 미친 짓거리를 하고 있군요.

SUSE도 그렇구요.

왜??

호환성을 위해 아예 i386으로 발표하지요??? 기업은 다 i686 아키텍처 이상만 쓰라는 법이 있나요?

그리고 Fedora 프로젝트에 대해 불만을 표시하면 안됩니까?

어디 GPL에 그러면 안된다고 나와 있나요?

무슨 RedHat이 GNU의 신도 아니고 그들도 사업체일 뿐입니다.

Fedora 역시 말이 듣기 좋아서 community OS 하고들 있지만 팔리고 있는 OS보다 community OS가 더 좋아진다면 RedHat도 모순에 빠지겠죠.

구체적인 증거는 없지만 정황이 그렇네요. (제가 검찰에 제출할 보고서 작성하는 것도 아니고 제 주장을 할 수는 있다고 봅니다.)

사실 이런 오해를 들어 먹어도 싸죠.

예전에 Pentium Pro 코어가 대세이던 시절에도 i386 패키징 해서 말이 많았던 것인데 IT가 정치판도 아니고 아닌 건 아닌거죠.

10년도 더 된 이야기지만 i386 패키지만 있었을 때 PGCC로 glibc와 다른 패키지를 다시 빌드하는 것이 시스템 성능을 올리는 팁이고 초보자들은 알려줘도 못 먹는 기술이었습니다.

이때도 1~2% 빠르게 하려고 이 짓을 한 줄 아시나 보군요.

그리고 직접적인 증거는 아닐 수 있지만 유럽 국가나 심지어 미국 내에서도 레드햇 보다 앞서서 i686 전용 리눅스 배포판이 만들어진 것은 님께서 말씀하신 1~2% 빠르게 하기 위해서 그런게 아닙니다.

만약 님의 주장이 맞다면,

인텔이 새로운 CPU를 릴리즈 할 때마다 자랑하는 고급 쓰레딩 instruction sets은 허우대만 있는 광고 문구이고 실제 이득이 미미한 거네요.

그 뿐만이 아니죠. 사실 i586으로 한정지은 패키지는 지구상에 존재하는 수많은 AMD 사용자에 대한 철저한 무시하는 행위입니다.

GCC 개발팀은 뭐하러 매번 이런 CPU 아키텍처에 맞도록 컴파일러를 개정합니까?

성능 차이가 미미하다면 그냥 있던 걸로 쓸 일이지.

일단 서로 관점이 좀 다른 건 사실인데 괜히 제대로 쓰고 있는 것을 실익이 없는 헛짓거리를 하고 있다고 근거도 없는 주장 마시기 바랍니다.

어쨌거나 저도 글타래를 그만 접을까 생각했는데 아무리 생각해도 아닌 건 아닌 거 같아서 글 남깁니다.
---------------------------------
There's always another way, dear.

---------------------------------
There's always another way, dear.

cwryu의 이미지

흔히들 최적화를 따질 때 확실히 보이는 명확하고 단순한 무언가를 찾기 쉬운데요.

차라리 안 쓰는 기능을 USE 플래그를 이용해 빌드에서 제외해서 얻는 이득이라면 모를까, gcc의 CPU 의존적인 옵티마이즈로 얻는 성능 향상은 젠투의 비밀이 아닙니다. 옛날에 젠투에서 측정해서 슬래시닷에도 올라온 적이 있었는데 바이너리 배포판들과 차이가 나지 않았습니다.

송효진의 이미지

CFLAGS 가 속도에 영향이 없다면 그게 더 큰 문제 아닐까요?
CPU 에는 점점 고급 명령셋도 많아지고 있는데 소프트웨어는 여전히 활용을 못하고 있다면 아주 큰 문제라고 생각됩니다.
조금 억지를 쓰자면 아까운 CPU 자원이 낭비되고 있다고 할 수 있겠죠.
옛날에 측정한 벤치가 32bit 였다면 CPU 발전이 멎었으니 거의 비슷한 벤치였을거라 생각되고,
64bit 였다면 64bit CPU 종류가 많지 않았을 때라서 이 역시 비슷했을거라 생각됩니다.

누가 벤치좀 해주세요~

emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇 개 안돼요~
http://xenosi.de/

정태영의 이미지

사실 기본 명령어 셋인 x86 instruction set은 변화가 없습니다. 내부적으로 좀 더 효율적으로 구현되는 식으로 발전해나가고 있긴 하지만 명령어 자체는 그대로 있고, extension 인 mmx, sse, sse2, sse3, sse4 등이 있는데요.

이런 extension은 대부분 streaming instruction입니다. fpu register를 이용해서 여러개의 add, mul, div, sub 등을 한꺼번에 처리할 수 있도록 하는 것이 mmx이고, fpu register보다 2배 큰 sse register를 사용해서 더 많은 add, mul, div, sub 등을 한꺼번에 처리할 수 있도록 하는 것이 mmx+입니다.

mmx는 정수 연산만이 가능했지만 이를 부동 소숫점까지 확장한 것이 sse, sse2등이고, 여기서 순서를 바꾼다거나(suffle)하는 확장 동작들을 정의한 것이 sse3, 4 등입니다.

문제는 이 인스트럭션들을 제대로 활용하기 위해서는 마치 퍼즐을 푸는 것 같은 최적화 과정이 있어야 한다는거죠. 기계적으로 간단히 처리할 수 있는 부분이 아닙니다. 아직 이런 최적화를 수행하기에 컴파일러의 인공지능은 부족하다고 생각합니다.

--
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

blkstorm의 이미지

일단, 제 경험상 cflags에 따른 성능 차이는 있다고 봅니다.

슬래시닷에 올라온 것이 언제, 어떤 플랫폼에서 어떤 어플리케이션으로 측정한 것인지는 모르겠습니다만, 젠투 cflag 위키 페이지에

이런게 올라와있더군요. Atom330프로세서의 cflag에 관한 언급입니다. (여담입니다만, 이놈 제법입니다)

64 bit profile (amd64) & GCC 4.3.2, core2 gives ~15% more performance & yields stable builds.

같은 컴파일러(gcc 4.3.2)를 가정했을 때, core2와 nocona사이에서 이정도의 성능 차이라면 분명히 의미가 있단 말이겠죠.

개인적인 의견입니다만,

- 최신 프로세서로 올 수록
- 코어수가 많아질 수록
- 캐시 성능이 좋아질 수록

cflags에 의한 영향은 조금씩 커지고, 어느 단계에 가서는 유의미한 성능차이를 가져올 것 같습니다.

koseph의 이미지

사실 gcc가 하드웨어 플랫폼에 맞도록 코드를 생산하고 그에 대한 최적화 기능을 제공하고 있지 않다면 젠투도 없었을 것입니다.

말씀 하신대로 이것은 결코 젠투만의 비밀이 아닙니다. 어떤 배포판에서도 맘만 먹으면 이를 구현할 수 있습니다.

중요한 것은 안하고 있다는 데 있었고(지금도 대부분은 이 부분을 크게 생각하지 않고 있죠) 젠투는 다른 배포판이 하지 않던 시도를 했습니다.

혹시 젠투의 성능에 대해서 설마 무슨 차이가 있을라구 하고 의심하는 분들도 계실지도 모릅니다만

저같은 경우에 서버 장비를 신형으로 업그레이드 할 여력이 없는 회사라면 젠투를 권합니다.

듣보잡이라서 싫다면 할 수 없지만 데모를 보여주면 거진 다 넘어옵니다.

언제적 기사를 보셨는지 모르겠지만 사실 i386 패키지가 한참 설치던 시절(지금도 설쳐대고 있지만)부터 젠투는 영양가 있는 배포판이었습니다.

상식적으로 생각해 보겠습니다.

Pentium 4 Core에서 i386 instruction set으로 실행하는 게 더 효율적일까요?

아님 P4 instruction set으로 실행하는 것이 더 효율적일까요?

항상 그렇다고 못을 박을 순 없겠지만 대개는 CPU가 업그레이드 되면 예전에 서너가지 명령을 조합해야 할 수 있었고 여러 클럭을 소모하던 작업을 하나의 명령으로 한 클럭에도 끝내 버리는 코드가 들어가기 마련입니다. 아니면, 같은 명령이라도 처리 속도를 개선하는 것이 일반적이지요.

조금 더 쉽게 말하자면, 서울 토박이가 갑자기 부산에 내려가서 부산말로 의사소통을 하는 것과 다름이 없다고 생각합니다.

그리고 소비자의 입장에서도 비용을 들여 장만한 장비에 구형 아키텍처를 기반으로 하는 바이너리를 써야 할 이유가 굳이 없는거지요.

glibc와 모든 바이너리를 제대로 아키텍처에 맞도록 바꾸면 그 장비는 새로 태어나는 것과 진배가 없습니다.
(저는 여기서 glibc와 모든 바이너리라고 했습니다. 달랑 하나의 패키지만 따로 컴파일한다면 그 차이를 느끼지 못하겠지요.)

실례로 예전에 Tom's hardware에서 AMD 코어와 Intel 코어 사이에 벤치마크 경쟁이 심하게 붙어서 MPEG encoder을 이용해서 어떤 CPU가 더 빨리 인코딩을 하나 하는 기사가 있었습니다.

당시에 AMD가 Intel을 살짝 앞섰습니다.

그 후 1주일도 안되어서 인텔에서 상업용 컴파일러인 ICC로 컴파일한 MPEG encoder가 실험 목적으로 Tom's hardware에 전달 되었고 그 저자는 새로운 바이너리로 다시 벤치마크를 했습니다.

결과는 인텔이 30%이상 빨라진 결과가 나왔습니다. 시스템 라이브러리를 다시 컴파일한 것도 아니고 인코더 하나만 컴파일 했는데도 성능 차이가 난 것입니다.

물론 이 경우를 gcc에도 그대로 적용하기엔 문제가 있지요. 하지만, 위의 예처럼 분명히 차이가 존재한다는 것입니다.

어쨌든 중요한 것은 패키지를 빌드할 때 컴파일 프로파일을 적절히 조절해서 최대한 성능을 이끌어 내도록 해야 하는 게 당연한 것인데도 이것이 더 많은 혼란을 야기할 수 있기 때문인지 귀찮아서인지 여전히 generic packaging을 하고 있습니다.

1년 내내 서버에서 매일 서비스 하고 있는 httpd가 어떻게 패키징 된 것인지도 모르고 그저 ./configure ; make ; make install을 해서 쓰는 관리자와 이를 꼼꼼하게 점검해서 단 1 마이크로초라도 빠르게 하겠다는 관리자는 시스템을 바라보는 관점 자체가 다르다고 생각합니다.

누가 잘 났고 못 났고가 아니고 관점이 다르다는 것이죠.
---------------------------------
There's always another way, dear.

---------------------------------
There's always another way, dear.

cwryu의 이미지

CPU 의존적인 최적화가 속도 향상이 있을 것이다, 눈꼽만큼이든 얼마든 빨라질 가능성이 높다는데 이견이 없습니다. 하지만 구체적으로 얼마나 되는가, 의미 있는 수준이라고 측정한 경우는 보지 못했습니다. 배포판 개발자들은 그게 소스 컴파일의 단점을 감수할 만한 의미가 있는 수준으로 빨라진다고 생각하지 않습니다.

ICC로 컴파일한 결과는 성격이 다릅니다. 같은 컴파일러에서 옵션만 다르게 한다면 몰라도 완전히 다른 컴파일러로 컴파일했을 때 성능 향상이 있는 사실을 갖고 CPU 의존적인 최적화의 결과라고 생각할 수는 없습니다. ICC는 인텔 CPU뿐만 아니라 AMD의 CPU에서도 웬만한 다른 컴파일러보다도 더 나은 결과를 보일 겁니다.

게다가 동영상 코덱은 매우 특이한 케이스로 I/O보다 CPU를 월등히 많이 사용하는 상황이고 최적화할 여지가 많습니다. 그 외에 이미지 필터나 컴파일러 따위의 CPU 중심 프로그램도 마찬가지로 빨라질 여지가 높습니다만 그 속도만 떼 놓고 벤치마크의 결과로 쓴다면 불공정하죠. (애플이 과거에 ppc로 x86보다 빠르다고 주장하면서 포토샵의 특정 필터 속도 벤치마크를 사용했었습니다.) 이 스레드의 주제인 부팅 속도나 웹 서버 로드 따위의 일상적인 리눅스 프로그램 사용에서 구체적으로 속도 향상이 있을 것 같지는 않군요.

koseph의 이미지

앞서 하신 말씀은 저도 패키지 최적화와 관련한 다른 리눅스 커뮤니티에서 열띤 논쟁을 일으킨 것을 본 적이 있습니다. 그리고 국내에서도 비슷한 번역글 논쟁이 있는 것도 보았구요.

얼마나 구체적인가 그리고 의미있는 수준으로 빨라지는가는 직접 해보시면 아신다고 밖에는 말씀을 드릴 수가 없군요.

가끔 플래그를 잘못 조작하고 불필요한 기능을 집어 넣는 경우라면 젠투도 여지없이 더 느려집니다.

제가 말씀 드린 것은 자신의 요구에 맞는대로 최적화 한다는 의미인데 이렇게 글로 써봐야 아무런 의미도 없고 실제로 구현하지 않고서는 너무 피상적이라고 밖에는 표현 못하겠군요.

눈꼽만큼이 얼마만큼인지는 모르겠습니다. 제 생각에는 무시해도 될만큼으로 보이는데 저는 그 차이가 결코 무시할 만큼은 아니다고 생각합니다.

이것은 실제 사이트를 죄다 젠투로 바꾸어 보고 제가 실제로 경험한 것을 토대로 말씀 드리는 것입니다.

특히 X86보다는 AMD64와 X86_64에서 인상적인 충격을 경험했습니다.

가장 내세울 만한 것은 서버에 과부하가 걸릴 때입니다. DDoS 공격의 경우도 해당이 되겠죠.

로드가 상당히 많이 걸렸을 때도 response가 여전히 날카롭고 서버가 knock-out 되는 경우를 7년이 넘게 단 한번도 경험하지 못했습니다. 실제로 서버가 다운된 경우는 전원공급장치의 팬이 죽어서였습니다. 이것 역시 HA로 극복해 둔 상태였죠.

덕분에 핫시즌에도 휴가를 갈 수 있게 되었다고 하더군요.

이걸 만약 CentOS로 구현했다면??????

휴가는 지금도 못가고 있을 겁니다.

결국 이야기가 소스 컴파일로 돌아가는 젠투의 Portage 시스템에 국한되는 것 같은데 그것은 젠투의 실제 패키징 능력의 10분의 1도 보지 않고 겉으로 들어나는 것만 본 아주 근시안적인 평가입니다.

젠투 머신을 10대를 돌릴 때 어떤 멍청한 관리자가 10대 모두에서 동일한 패키지를 building 한다면 젠투를 오용하고 있는거지요.

Deployment 할 때 기존의 *.deb이든 *.rpm이 훨씬 단순하고 빠르다고 생각할 지 모르겠지만 젠투가 여러 대가 되기 시작하면 이야기는 패키지의 구성과 빌드부터 시작해서 빌드 방법, 배포방법 등이 기존의 다른 배포판과는 시나리오 자체가 바뀝니다.

이건 해보지 않은 분들에게는 설명이 불가한 부분입니다.

물론 패키지 관리를 직접 하는 부분이 생기기 때문에 다른 배포판에 비해 신경써야 할 일은 그만큼 더 생기고 관리자의 역량이 그대로 발휘되느냐 마느냐 하는 배포판이 바로 젠투라고 말씀드릴 수 있습니다.

그리고, 이렇게 패키지를 직접 관리하다 보면 특유의 노하우가 생기기 시작합니다. 리눅스에 대해 더 많은 걸 알게 됩니다. 물론 많은 삽질이 동반되는 경우도 있지만.......

가끔 이런 답변을 보면 시간이 나는대로 진짜 새로운 머신에서 두 개의 배포판을 깔고 부팅 시간을 정확하게 재서 올려버리고 싶은 맘도 들지만..... 제가 지금 시간이 없군요.

제가 없는 말을 지어낸 것도 아니고 실제로 적용하면 동일한 하드웨어에서 젠투가 훨씬 빠릅니다.

경험에 의하면 빠른 하드웨어 일수록 그 격차는 더 크게 벌어집니다.

그리고, 포티지가 업글되면 그 때 또 빨라지는 것을 볼 수 있습니다.

특이하죠? 다른 배포판은 패키지를 업글하면 속도가 떨어지는데 젠투는 더 빨라지는 경우가 더 많으니까요?

단순히 부팅 몇 초 더 빠른게 중요한 게 아니라는 걸 저는 말하고 싶었던 것입니다.

이야기가 나온 김에 좀 더 하죠.

부팅의 경우 젠투는 일반적인 배포판과 원리는 동일하나 세부사항은 관리자가 얼마든지 조정할 수 있습니다. 마치 데비안과 CentOS의 차이처럼 젠투의 색깔도 아주 분명합니다. 근데 굳이 서로 비교를 하겠다고 젠투를 Ubuntu나 Fedora처럼 만든다고 한들 더 느릴 이유가 전혀 없습니다.

현실은 젠투 사용자들은 결코 이들 배포판과 흡사하긴 하나 동일한 구성을 하지 않는다는 것에 주목할 필요가 있습니다. 왜냐? 좀 고리타분 하거든요. 기존의 배포판들이 하고 있는 걸 보면........ 저같은 경우 참조는 합니다만 절대 따라하지 않습니다. 불필요하다고 생각하는 것은 과감히 빼버리니깐요.

물론 제 의견이 일반적이라고는 생각하지 않습니다.

젠투를 쓴다는 것 자체가 일반적이지 않으니까요. 하지만, 눈꼽만큼 빨라진다 혹은 질수도 있다에는 동의할 수 없군요. 제가 장담하는데 결코 그렇지 않습니다. 그 차이는 휴가가 있느냐 없느냐 하는 아주 현실적인 결과로 나타나니까요.

소스 컴파일이 큰 부담일 수도 있지만 이걸 감내할 수 있는 환경이고 적용이 용이한 경우라면(네이버나 다음처럼) 잘 만든 마스터 머신 하나가 회사의 경비를 엄청나게 줄일 수 있습니다.

사실 어떤 서비스를 구축하는 데 결과적으로 그것을 달성하고 그것을 관리할 수 있으면 그만이지 꼭 많이 쓰는 배포판을 써야 한다고 생각하지 않습니다. 이것은 선택의 문제이니까 각자가 알아서 할 일이구요.

한 가지 명확한 것은 처음에 긴가민가 했던 제 고객이 지금은 젠투 왕팬이 되어서 열심히 배우더니 제 할일을 자신이 하고 있다는 것입니다.
---------------------------------
There's always another way, dear.

---------------------------------
There's always another way, dear.

cwryu의 이미지

CPU 의존 최적화 외에 젠투의 여러가지 측면을 갖고 좋냐 아니냐 논쟁할 생각이 없고요.

그래서 구체적으로 얼마나 빨라졌다는 건지 없고, 그게 CPU 의존적인 최적화 때문인지 다른 조치 때문인지 증거가 없죠.

슬래시닷의 그 벤치마크에서는 같은 하드웨어에서 CPU heavy한 동작을 실행했을 때 (커널 컴파일, GIMP) 옵티마이즈 옵션을 있는대로 넣은 젠투가 i386 컴파일한 데비안보다 10% 정도의 빠른 결과가 나왔었습니다. 전체적으로 10%라면 충분히 의미 있다고 하겠습니다만 그런 CPU를 많이 쓰는 작업을 컴퓨터에서 얼마나 쓸까 생각해 보면 호환성을 희생할 만한 가치가 없죠.

정태영의 이미지

부연하자면 x264등과 같은 비디오 코덱들은 대게 어셈블리 레벨의 최적화 코드를 생성합니다. (컴파일러가 아닌 개발자들이) 그렇기 때문에 컴파일 타임에 최적화된 어셈블리 코드를 사용하도록 하면 빨라질 수밖에 없죠.

--
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

sangu의 이미지

Quote:

Pentium 4 Core에서 i386 instruction set으로 실행하는 게 더 효율적일까요?

F11 x86 기본 cflags는 -march=i586 -mtune=generic 입니다.
i386 instruction set만 지원하지 았습니다.

Quote:

어쨌든 중요한 것은 패키지를 빌드할 때 컴파일 프로파일을 적절히 조절해서 최대한 성능을 이끌어 내도록 해야 하는 게 당연한 것인데도 이것이 더 많은 혼란을 야기할 수 있기 때문인지 귀찮아서인지 여전히 generic packaging을 하고 있습니다.

바이너리 배포판 개발자들은 어떤 특정 하드웨어만을 위해서 배포판을 개발하지 않습니다.

Quote:

결과는 인텔이 30%이상 빨라진 결과가 나왔습니다. 시스템 라이브러리를 다시 컴파일한 것도 아니고 인코더 하나만 컴파일 했는데도 성능 차이가 난 것입니다.

GCC가 ICC보다 좋지 않다는 결과를 나타내는 군요. 이 논의와 상관이 없어보입니다.

koseph의 이미지

짜증이 확 나는군요.

icc가 gcc보다 낫다는 것을 지금 말하고 있는 게 아닙니다.

마치 어린 애가 논지를 파악 못하고 헛소리 하고 있다는 식으로 인용을 하시는데.......

더운 날씨에 고생이 많으십니다.

---------------------------------
There's always another way, dear.

sangu의 이미지

초기 논의에서 벗었난 이야기일 뿐입니다.

바라미의 이미지

전 최적화 따윈 필요 없어요~
컴파일해서 설치하는거 귀찬아서 바이너리 배포판 선호할 뿐이고.
예전에 RPM에 데인적 있어서 우분투를 접했고, 그래서 익숙한 deb 계열이 더 좋을 뿐이고.
그런데 우분투 쓰다보니 데비안의 방대한 패키지가 아쉬워서 데비안으로 온거 뿐이고.

페도라가 좀 더 예쁘긴 해서 끌리긴 하지만 전 그냥 데비안 쓸래요... :)