드디어.. 내놓습니다. T.T

http://annyung.oops.org/?m=data&p=rel20

AnNyung LInux 2 스포일러를 흘린지 2달정도가 지났습니다. 여지 없이 또 뻥카치는구나 하시는 분들도 있을거라 생각되고, 수많은 뻥카질에 이미 내놓든 말든 하시는 분들도 많아졌으리라 생각 됩니다.

일단 스포일러를 내놓은지 2달이 지난 시점에서, 아직 발표되지 않는 이유에 대해서는 공개가 필요할 것 같습니다.

일단, 배포본 공정은 약 90% 정도가 진행이 된 상황입니다. 진행이 좀 늦은 이유는 회사 업무상 3월말, 4월초에 큰 프로젝트 D-Day가 잡혀 있어서 약간 늦춰진 상황이며, 발표를 못하는 가장 큰 이유는 급하게 작업을 진행하다보니 문서화가 되어 있지 못하다는 것입니다.

일단, Repository는 "http://mirror.oops.org/pub/AnNyung/2/"에 이미 공개가 되어 있는 상황이고, APM package가 이미 준비가 되어 있기 때문에, 위 URL의 문서를 보시고 설치를 하실 수 있는 분들이라면 사용을 하셔도 무방하다고 말씀 드릴 수 있을 것 같습니다. (일종의 베타 테스트를 요청하는 것일 수도 있습니다. 문서도 없이 말이죠 ^^)

약 10%의 작업은 안녕 1.3에 포함 되었던 기능들의 porting과 문서화 작업, 그리고 혹시나 Installer 작업 (물론 ISO 버전을 제공하지는 않을 것이고, PXE initrd.img 의 수정 정도가 제공)이 있을 수 있습니다.

오랜만의 포스팅 이네요. 오늘은 AnNyung LInux 2의 스포일러를 살짝 흘릴까 합니다.

정말 죄송스럽게도 안녕리눅스 로드맵에서 안녕 2를 2007년 3/4분기에 내놓겠다고 뻥을 치고선 5년이 흘렀습니다. 아마도 Debian의 업데이트 주기보다 더 악랄한 뻥을 친것이나 다릅이 없습니다.

정말 죄송스럭베도 아직까지도 안녕 2를 기다려 주시는 분들이 있다는 것은 더 송구 스럽군요 ^^;

변명을 해 보자면, 네오위즈 재직 기간동안 정말 바쁘게 일을 했던것 같습니다. 이 기간동안에는 내가 과연 오픈소스 활동을 계속 할 수 있을지에 대한 의문을 가진적도 있었고, 누구처럼 이젠 슬슬 잠수를 타야하는가 하는 생각도 많았던 것 같습니다.

그러다 극적으로 제가 네오위즈를 퇴사를 하게 되었습니다. 그리고는 시간이 남아돌게 되었네요. (실은 뻥입니다. 시간이 남아돌지는 않습니다. ^^) 이직을 하면서, 시스템에 대한 전적인 권한이 제게 오다보니, 드디어 안녕 리눅스 작업을 할 수 있게 되었다고 할까요.

현재 안녕 리눅스 작업은 작년말 부터 실제 패키징이 시작된 상태이며, 2월말 정도에 베타든 정식 버전이든 모습을 보일 예정입니다. 일단 제가 회사에서 사용을 하려고 작업을 하는 관계로 아마 틀림없이 나오지 않을까 싶습니다. (다른일 때문에 늦어져도 3월에는 안녕리눅스로 서비스를 들어가야 하므로.. 최소한 베타의 모습으로라도 모습을 보이지 않을까 싶습니다.)

현재, CentOS 6.2 기반으로 작업을 하고 있으며, 안녕 1.x에서 2로 넘어가지 못한 가장 큰 이유인 Installer는 안녕에서는 제공하지 않을 예정입니다. 일단은, Yum repository 기반으로 제공을 할 예정이며, Yum repository를 등록하면, CentOS가 안녕 리눅스로 변신을 하도록 하게 할 예정입니다. 일단 Installer 작업이 없으니 아마 안녕 3은 보다 쉽게 발표가 가능하지 않을까 싶습니다.

주절주절 길게 쓰고 있는 동안에도 열심히 패키징 작업 중이랍니다. :-)

AnNyung LInux의 특징 중에 하나가, stack overflow를 방지하기 위한 patch가 되어 있다는 것입니다. 현재 안녕 리눅스는 이 stack overflow patch가 되어 있는 버전과 되어 있지 않은 2가지 버전을 제공해 왔으나, 6월 중순, no stack overflow 빌드를 담당하던 oops.org의 서버가 "인터넷 제국"의 서비스 종료로 더이상 가동을 할 수 없게 되었습니다.

이에 공식적으로 no stack overflow version에 대해서는 더이상 업데이트를 제공하지 못하게 되었음을 알려 드립니다. 혹시 (아마 없을거라 생각이 되지만..) no stcok overflow 버전으로 운영을 하시는 분들은 srpm를 받으셔서 rebuild를 하셔서 운영을 하시면 되겠습니다.

oops.org 가 호스팅 하고 있는 한와이어리스(인터넷 제국)의 서비스 단절로 인하여 안녕 리눅스 build server로 이전을 하고 있습니다. 이로 인하여 oops.org의 서비스가 이전 완료시까지 정상적으로 서비스 되지 않을 수 있습니다.

안녕 리눅스 update는 단절이 없도록 할 계획이나, 패키지 업데이트 등은 지연될 수 있으니 참조 하시기 바랍니다.

현재 일부 sub site들과 DNS는 이전이 완료된 상태 입니다.

한와이어리스의 서비스가 6/19 0시까지 이므로, 이 전에 정상화가 되도록 할 예정입니다.

만 10년동안 서버/회선를 제공해 준 인터넷 제국 관계자들께 그동안 감사 인사를 이자리를 빌어 감사드립니다.

요즘 슬슬 CVS를 SVN으로 옮겨 보려고 하고 있다. 괜찮은 svn interface가 뭐가 있난 찾다 보니 websvn이라는 놈이 깔끔하고 괜찮아 보였다. 다른 web interface들은 기존에 사용하던 cvsweb의 기능 중 지원하지 못하는 것들이 많아 좀 불편해 보였는데, 이 놈은 기존 사용하던 기능을 대부분 지원 하는 듯 하다.

그런데, 내가 주로 많이 사용하던 기능 중 diff시에 raw text를 출력해 주는 unified diff가 없다는 것이 꽤 답답했다. 웹에서 확인을 하고 mouse로 확 긁어서 붙이는 행위를 가끔 하는데, 이 놈이 이게 없는 것이다. 뭐 그래서 만들었다.

필요한 사람은 잘 사용하시도록.. (국내에서도 websvn 꽤 사용하는 듯..)

이 글을 올리는 이유는 patch를 제출하려고 했더니.. 첨부 파일이 없어서.. --;

Websvn Unified diff patch file

며칠전 마눌님이 GAP.com이 접근이 안된다고 해서 봤더니 tempary service error가 있어서 일본 지진 영향으로 해외라인에 문제가 있는 줄 알았다. 그런데 기사를 보던 중, '한국 차단'이라는 기사가 있어 분석을 해 보니, 차단이 맞는 것 같다.

그래서 좀 더 검색을 해 보니, 이미 몇몇 우회 방법에 대해서 포스팅이 되어 있었다. 일단 포스팅 된 것을 보니

1. proxy program을 설치해서 우회
2. proxy site를 이용해서 우회
3. http://mnm.gap.com 을 이용해서 우회

등등의 방법을 제시하고 있었다. 1번은 귀찮고, 2번은 결재를 하는데 anonymous proxy를 사용하는 건 영 꺼림칙하다. 3번은 SSL로 넘어갈때 인증서 에러가 너무 귀찮다. 그래서 가만히 분석을 해 봤다.

일단, gap에 접속해 보면 이따구로 나온다.



음.. Akamai cache를 사용하고 있다. 그리고 redirec 주소로 보아서.. akamai에서 한국 IP를 막고 있다는 것이 명확히 보인다. 그래서 DNS lookup을 해 보았다.



일단 캐시로는 www.gap.com만 Akamai로 넘기고 있다. 그리고 gap.com은 다른 IP를 가지고 있다. 이 얘기는 www.gap.com의 origin이 gap.com 이라는 얘기가 된다. mnm.gap.com 역시 gap.com과 동일한 IP를 가지고 있다.

짜잔 결론이 나온다.

1. tor를 이용하자. 단 단점은 내 tree에 한국 IP가 포함이 되어 있다면 잘 되다가 한번 막힐 수도 있다. 결재 순간이면 좀 critical할 수 있다.

2. hosts 파일에

70.42.14.161 www.gap.com

라고 따악 밖아 버리자. hosts 파일에 박으면 그냥 아무런 일이 없었다는 듯이 진행이 된다.

다만... 다른 모든 포스팅이 그렇듯.. 접속은 되지만 실제 결재가 잘 된다는 얘기는 없다. 나도 물론 마찬가지이다. 결재하고 싶지는 않다. :-)

Tor를 막을일이 생겼다 기록 차원에서 남긴다.

http://www.torproject.org/faq-abuse.html.en
https://check.torproject.org/cgi-bin/TorBulkExitList.py

금일 일지..

1. 아빠 회사 태그를 광속에 숨김. (찾는데 1시간 걸림)
2. 소아과 가서 감기약 받아온 것을 잠시 안보는 사이에 원샷함. 지금 위세척하러 응급실로 출발 T.T

출처: http://forums.parallax.com/showthread.php?114807-Fast-Faster-Fastest-Code-Integer-division

page 없어질 까봐 스크랩 함.

Hi All,

A code or algorithm must be correct. When it is, after some debugging, we can make a compromise between its code size and speed. There is always a compromise, but sometimes it does not matter. When either speed or size is a factor, there are methods to boost performance. There might be a 'Small, Smaller, Smallest' flavor of coding for a given language/hardware combination, but in this kind of thread I am looking for very fast codes. As, we have these days the luxury of more and more code space, but of time, we don't.

Even when divide hardware is available, it is quite common to find that divide instructions take more than twice as long as multiply instructions. When division and multiplication are done by software, dividing is usually slower than multiplying, too. However, we can improve speed by noticing, that many integer division operations found in real programs involves division by a constant. When we know the numbers we are dividing by in advance, we can substitute the divisions with multiplications and with some bit shifts.

When the constant to divide by is a power of two, we can shift the number to be divided to the right by the exponent, and that will complete division



This bit shift is only one operation, four ticks with the Propeller. Can we do something similar when the constant is not a power of two? Yes. The·basic idea is to approximate the ratio (1/constant) by another rational number (numerator/denominator) with a power of two as the denominator. Instead of dividing, we can then multiply by the numerator, and shift by the exponent in the denominator. In case of 10, for example, the (1/10) ratio can be substituted with· (205/2048). The (some_integer/10) division can be calculated with a multiplication (some_integer*205), then the product is shifted right 11 bits to get the result of the division by 10. In short notation



To divide with 100, the rational number (41/4096) works nicely



For 1000 we can realize that it is 8*125. So, if we first shift 'some_integer' to the right by 3, we only need to divide the result by 125. When (1/125) is approximated as (67109/2^23)=(67109/8388608), then the simple formula



works for integers up to almost 400_000 with high accuracy.

To figure out the (numerator/denominator(=2^N)) approximation for an arbitrary (1/constant) factor, first we have to fix the required relative accuracy of the division. When 1% relative accuracy is adequate for the application
- we multiply the constant with 100.
- Then we find the smallest power of two, that is bigger than the product.·For (1/2009), 262144 is that, so the denominator is 2^18.
- Then, we·obtain the numerator by dividing 2^18 by the constant 2009. That gives 130.48. After rounding to the nearest integer, we have··the·rational approximation·of (1/2009) as (130/2^18).·

It goes, in short



Or, doing an evident simplification, it is



For a ten times better relative accuracy of 0.1%, the formula is



After simplification, it is



The previous simplications decrease the numerator and are useful, since the (some_integer*numerator) product has to be smaller than 2^32, to avoid overflow with the 32-bit multiplication.· 2009 is an odd number. For even constants we can shift out the power of two factor from their primes, before the division. So, to divide with 2010 at 0.1% accuracy, one can use



The initial right shift for an even constant increases the range of validity of the algorithm at the cost of an additional operation.I wonder wether all these beat unrolled division?

We have just substituted a division by a multiplication, but elimination of multiply instructions is itself desirable. For example, according to the Pentium instruction timings, the base time for a 32-bit integer add or subtract on that processor (discounting operand fetch and other overhead) is 1 clock cycle, and both can sometimes be paired with other instructions for concurrent execution. In contrast, a 32-bit multiply takes 10 cycles and a divide takes 41 cycles, and neither can be paired. Clearly, these instructions should be avoided wherever possible.

In case of multiplication with a constant we may ask, that
- Can we can do faster integer multiplication with a constant with only· bit shifts and additions? (The answer is probably: yes. And remember, numerators were contants...)
- Can the (1/constant) ratio be calculated even faster with only bit shifts and additions?

I think the answer for the 2nd. question answers the 3rd, too.··

Trespassing the Regime of Fixed-point math (or not?)...
-------------------------------------------------------------
Fixed-point representations, in which the point is implicitly placed between any bits of the binary representation of a number, have been used since the dawn of the computer age. In the PC world fixed-point arithmetic has become a lost art among programmers. Since the introduction of the 486 CPU, a fast floating-point processor is an integrated part of the CPU, and therefore there is rarely a need to work with fixed-point numbers anymore. In embedded applications fixed-point arithmetic has still its places, and there is no excuse to use inefficient or imprecise methods with those limited resources. Moving away from integer arithmetic to fixed-point numbers is one step forward to close the gap between the speed of integer math and the ease of use of floating point arithmetic.

When fixed-point numbers are used, all arithmetic operations use integer arithmetic, and this leads to a considerable performance advantage. This comes from that a binary fixed point number is, for all purposes, an integer number. You simply cannot tell the difference by looking at it, and neither can the machine level math functions. For those math functions, the numbers are just integers. That's the beauty of it: you use the same machine level functions you would for integer math, plus a little bit of housekeeping for the point at multiplications and divisions. (John Von Neumann said once, that a competent programmer never needs floating point hardware because he should always be able to keep the point in his head. Well, his words are just remembered by others, he never wrote them down...)

With fixed-point arithmetic we can choose the precision of the numbers, because we can distribute bit usage between fractional and integer parts of a fixed number in any way we like. So, we can adapt a very fast code to very different accuracy demands.

In fixed-point, the simple integer division is the worst basic operation, because it loses precision the most. To somewhat remedy that, we can use multiplication by the reciprocal of that number (1/number) instead. To whet your appetite for fast and effective fixed point ASM code, I show a way to divide by 10 with faster, more efficiently and·more accurately, than·with the discussed acceleration method.



To make it even faster



If you know other tricks or methods to speed up integer or fixed-point division or multiplication, let us know, too. SPIN or PASM test codes to check, improve or maybe to bust these ideas, are welcome.

Cheers,

istvan

Post Edited (cessnapilot) : 7/29/2009 7:10:30 PM GMT