February 2009 Archives

MS의 PowerShell은 UNIX의 쉘에 비해서 떨어지는 윈도우즈의 쉘환경을 개선하기 위해 MS에서 새로만든 .NET기반의 shell이다. PowerShell은 현재는 별도로 설치해야 사용할 수 있으나 근래에 출시된 Windows 2008부터는 포함되어 배포된다.

어쨌든 PowerShell은 배치파일과,VBScript의 다음을 잇는 MS의 주력 쉘이 될 것이고 관련 서적들도 많이 나오고 있다. PowerShell은 Cmdlet이라는 것과 .NET객체들과 결합해서 손쉽게 윈도우 운영체제 내부의 정보에 접근해서 다룰 수 있는 이점이 있으며

<예 - 프로세스들에서 워킹셋(Working Set)이 20MB 이상인 것 표시>

Get-Process | Where-Object { $_.WS -ge 20MB }

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName
-------  ------    -----      ----- -----   ------     -- -----------
    270      14    18776      34160    92    13.69   4792 AcroRd32
   4350      68   771580     701472  1150 6,778.64   4248 firefox

일반적인 문법을 보면 unix 쉘과 Perl의 중간쯤 문법이라는 느낌이다. 일단 Perl과 비슷한 점을 몇 가지를 들어보면 다음과 같다.

* 변수에 sigil을 사용
<powershell>
$var =1
$array = @(1,2,3)
$hash = @{a=1;b=2;c=3}

<perl>
$var=1;
@array = (1,2,3);
%hash = (a=>1, b=>2, c=>3);

$var 처럼 $를 붙이는 sigil을 사용한다는 점이 Perl과 비슷하나 Perl과는 달리 무조건 $을 쓴다.  이것은 sigil로 변수의 내용을 유추할 수 있는 Perl이 훨씬 진보된 방식이다.

*슬라이스(slice) 문법
<powershell>
(1,2,3,"test")[0,2]

<perl>
(1,2,3,"test")[0,2];

*범위연산자
<powershell>
$array = 1..5

<perl>
@array = 1..5;

* $_ 기본변수
<powershell>
1,2,3 | foreach { Write-host $_ }

<perl>
foreach (1,2,3) { print $_,"\n" }

* 보간(interpolation)
<powershell>
"var is $var. ${var}th"

<perl>
"var is $var. ${var}th"


* 익명함수 선언과 호출
<powershell>
$func = { return $args[0]*2 }
&$func(2)

<perl>
$func = sub { return $_[0]*2 };
&$func(2)
$func->(2)

이외에도 PowerShell을 살펴보면 Perl과 비슷한 점이 많다. PowerShell은 일반적 범용 프로그래밍 언어가 아니라 시스템관리 같은 한정된 특정도메인에 맞게 설계된 언어라고 하지만, 대충 훑어보니 끼워 맞춘듯한 문법 같은 것들과 문법의 모호성 같은 것이 느껴졌다. 일례로 배열을 선언할 때

$a=1,2,3
$a=(1,2,3)
$a=@(1,2,3)
$a=$(1,2,3)

가 다 같은 결과이며 변수와 리터럴의 구분이 모호하다. 그리고 hash자료구조에서

$hash=@{a=1;b=2;c=3}

라는 해시를 선언했으면 해시키 a에 대한 값(1)은 $hash['a'] 혹은 $hash.a 로 얻을 수 있다.
그리고 $hash내의 key,value쌍 갯수를 얻으려면 $hash.Count 키들의 목록을 얻으려면 $hash.Keys 값들의 목록을 얻으려면 $hash.Values 의 빌트인 함수를 사용할 수 있다. 위 해시에 이것들을 적용하면
$hash.Count 는 3
$hash.Keys 는 a b c
$hash.Values 는 1 2 3
이 된다.

그러면 해시를 다음과 같이 선언하고 $hash의 Count,Keys,Values를 보기위해 똑같이 해보자

PS D:\temp> $hash=@{a=1;b=2;c=3;Count=0;Keys=0;Values=0}
PS D:\temp> $hash.Count
0
PS D:\temp> $hash.Keys
0
PS D:\temp> $hash.Values
0

이런 해시의 경우 Count, Keys, Values가 Key가 빌트인 함수로 해석되지 않고 key로 해석되며 문제는 Count,Keys,Values 빌트인 함수를 호출할 방법조차 없어진다는 것이다.

그리고 PowerShell의 성능도 아직까진 그렇게 좋은 것 같지 않다. 어떤 사람이 IIS로그들 중에 필요한 부분을 정규식을 통해 뽑아내는 프로그램을 Perl과 PowerShell로 짜서 돌려봤는데 ( http://bohdanszymanik.blogspot.com/2007/03/powershell-versus-perl.html ) Perl은 12초 걸린 것이 PowerShell은 20분이 걸렸다고 한다.

PowerShell은 현재 1.0버젼이며 2.0도 개발이 진행중이라고 하니 앞으로 어떻게 발전해갈지 지켜봐야 겠지만 Cmdlet등으로 Windows 운영체제 내부의 정보에 쉽고 편하게 접근해서 사용할 수 있다는 장점은 있으나 언어 그 자체의 견고함과  완성도에 있어서는 아직까지 부족한 점이 많은 듯 하다.

윈도우용 비상업적 Perl 배포본인 Strawberry Perl의 Portable 버젼이 베타 딱지를 떼고 정식으로 출시되었다.

참고: http://use.perl.org/~Alias/journal/38533
다운로드 링크: http://strawberry-perl.googlecode.com/files/strawberry-perl-5.10.0.4-1-portable.zip

Portable 버젼은 일반적인 설치 버젼과 달리 따로 설치 없이 USB같은데 넣어 다니면서 쓸 수도 있고 복사해서 바로 쓸 수도 있다.

위 파일을 받아서 압축을 풀어서 strawberry-perl-5.10.0.4-1-portable 디렉토리로 풀렸고( 이 기반이 되는 디렉토리 이름은 다른 이름으로 바꿔도 상관없다.) 이것을 USB에 복사해서 USB가 F:드라이브로 잡혔다면 다음과 같이 perl을 실행하면 된다.( 드라이브 경로와 기반 디렉토리 이름은 상황에 맞게 수정 )

F:\strawberry-perl-5.10.0.4-1-portable\perl\bin\perl myscript.pl
(myscript.pl은 실행하고자 하는 Perl 스크립트)

이것은 Portable의 특성상 Perl 바이너리의 Path가 잡혀 있지 않기 때문인데 Perl스크립트 실행 시 Perl 바이너리의 Full path를 다 치기 귀찮으면 다음과 같은 꼼수를 쓸 수 있다.

기반이 되는 F:\strawberry-perl-5.10.0.4-1-portable\  디렉토리에 다음과 같은 batch파일을 하나 만든다.

<start.bat>
.\perl\bin\perl -e "$basepath=$^X; $basepath=~ s/perl\\bin\\perl\.exe//;print q/set PATH=/,map {$basepath.$_.q/;/} qw/c\bin perl\bin/" > setenv.bat
echo %PATH% >> setenv.bat
echo set TERM=dumb >> setenv.bat
call setenv.bat
del /f setenv.bat
start cmd.exe


이렇게 만들고서 파일 탐색기에서 start.bat 파일을 더블클릭해서 실행시키면 임시로 환경변수를 세팅하는 setenv.bat을 만들어 환경변수를 세팅하고 나서 지우고 새로운 cmd창을 하나 호출하여 띄우게 된다. 이제 새로 뜬 cmd 창에서는 환경변수가 적용된 상태이므로 그냥

perl myscript.pl

하면 실행되며, cpan등 다른 perl\bin에 있는 명령들도 Full Path를 적지 않고 바로 실행시킬 수 있다.


과거 클럭스피드를 높여서 성능을 향상해오던 CPU가 어느 순간 발열,에너지소비 등등의 물리적 한계상황에 부딪치자 칩의 집적도를 높여 여러 개의 core를 넣어서 성능 향상을 도모한 multi core CPU가 등장했다.

얼핏 생각하기에는 core수를 늘이면 성능이 core수에 따라 선형적으로 향상될 것이라고 생각하기 쉬운데 미국의 Sandia 연구소에서 1->4코어 까지는 눈에 띄는 성능향상이 있으나 4->8코어는 그 향상이 미미하며 8코어를 넘어가면 오히려 성능이 떨어진다는 연구결과를 내놓았다.

참고: http://www.sandia.gov/news/resources/releases/2009/multicore.html

이런 성능저하는 CPU와 메모리 간 bus의 대역폭이 충분하지 않거나 프로세서들간의 메모리 자원접근을 위한 경쟁상황 때문에 발생하는데 이는 메모리 콘트롤러를 사용하여 어느 정도 완화할 수 있다. 그래서 high performance computing 분야나 대규모 온라인게임(MMORPG) 서비스 분야에서는 multi core CPU가 등장하기 시작할 시기 CPU내에 메모리 콘트롤러를 내장하여 동일 core 수 에서도 INTEL사의 CPU보다 더 나은 성능을 보여주던 AMD사의 CPU가 선호되었다. (지금은 인텔도 투퀼라와 네할렘  아키텍쳐 부터는 CPU내에 메모리 컨트롤러를 내장하기 시작했지만.)

이 연구에 대한 기사에서는 이런 성능저하 과정을 수퍼마켓의 종업원에 비유하여 설명했는데 나는 오락실의 농구기계를 떠올렸다.

농구기계는 혼자서 하면 공을 잡아 던지는 시간보다 굴러나오는 공의 공급이 더 빠르다. 그래서 점수를 높이기 위해 친구랑 2명이서 하면 공을 링에 던지는 순간 딴 사람은 밑에서 공을 잡고, 공을 던진 사람이 공을 잡을 때 다른 사람은 잡은 공을 던지고 하는 식으로 하면 같은 시간에 더 많은 슛 시도를 할 수 있다. 하지만 3명이 되면 오락기의 폭은 3사람이 서서 손을 넣어 공을 잡기도 비좁고 3사람이 제대로 스케쥴이 되지 않아 굴러나오는 공을 서로 먼저 잡으려고 하다가 손이 꼬이고 해서 오히려 효율이 떨어진다. 지금 multi core CPU의 상황이 오락실의 농구기계와 같은 상황이다. 따라서 각각의 코어들이 제성능을 발휘할 수 있는 주변 아키텍쳐의 개선 없이는 코어수를 늘이는 것이 곧 성능향상을 뜻하는 것이 아니라는 것이다.

"코어수가 늘어서 성능이 향상되었습니다!" 이런류의 마케팅 슬로건을 그냥 곧이곧대로 믿으면 안 된다는 얘기.

About this Archive

This page is an archive of entries from February 2009 listed from newest to oldest.

January 2009 is the previous archive.

March 2009 is the next archive.

Find recent content on the main index or look in the archives to find all content.

Creative Commons License
This weblog is licensed under a Creative Commons License.
Powered by Movable Type 4.21-en