안드로이드 개발 질문/답변
(글 수 45,052)
NDK의 경우는 크로스컴파일을 하는게 맞는지요...??
toolchain 쪽에 보니 arm-eabi-4.2.1 이라고 있는데..
이것이 NDK에서 제공한 컴파일러인가요 ??
혹시 이걸 다른 컴파일러로 바꾸고자하려면 어떻게 해야하나요 ??
몇몇 mk파일에서 설정해 준 부분이 많은거 같은데.. 그걸 일일이 바꾸면 될까요 ?
2009.11.23 16:35:22
현재 리눅스 상에서 잘 구동하는 라이브러리가 있는데, 이걸 이용해서 안드로이드 어플을 만들었습니다.
근데 응답속도가 상당히 오래걸려서요;;
Android.mk에 컴파일옵션을 훅훅 주면서 시간을 단축시키긴 했으나, 리눅스와는 차이가 심하게 많이나네요
혹시나 컴파일러 문제가 아닐까 싶어서 바꿔보려고 생각중입니다.^^;;
근데 응답속도가 상당히 오래걸려서요;;
Android.mk에 컴파일옵션을 훅훅 주면서 시간을 단축시키긴 했으나, 리눅스와는 차이가 심하게 많이나네요
혹시나 컴파일러 문제가 아닐까 싶어서 바꿔보려고 생각중입니다.^^;;
2009.11.23 19:17:49
"리눅스와 차이가 난다"는 말의 의미를 잘 모르겠네요. 어떤 리눅스를 뜻하시는지...
하지만 컴파일러 옵션으로 시간을 단축할 수 있다는 뜻은, 인스트럭션문제로 보이고, 가장 가능성이 높은 실수연산관련 문제로 들리네요.
혹 그렇다면, 그리고 뭔가 새로운 사실을 발견하시거든 알려주시면 감사. 저도 암 플랫폼에서 실수연산과 관련된 이슈들이 깨끗이 해결되지 않고 있어서요.
댓글 편집기의 위에 있는 "알림" 채크박스가 메일통보 기능일까 해서 사용해 보겠습니다. 혹 다른 기능이고, 재편집이 안된다면 그냥 무시해주시면 감사하겠습니다.
하지만 컴파일러 옵션으로 시간을 단축할 수 있다는 뜻은, 인스트럭션문제로 보이고, 가장 가능성이 높은 실수연산관련 문제로 들리네요.
혹 그렇다면, 그리고 뭔가 새로운 사실을 발견하시거든 알려주시면 감사. 저도 암 플랫폼에서 실수연산과 관련된 이슈들이 깨끗이 해결되지 않고 있어서요.
댓글 편집기의 위에 있는 "알림" 채크박스가 메일통보 기능일까 해서 사용해 보겠습니다. 혹 다른 기능이고, 재편집이 안된다면 그냥 무시해주시면 감사하겠습니다.
2009.11.24 09:24:03
음...cygwin에서 소스를 빌드하고 실행파일을 만들경우와 JNI를 입혀서 so파일로 만들고 android 어플에서 불렀을 때의 경우를 비교한것입니다.
비교하기가 좀 그렇긴하다만....빌드한 결과가 exe파일과 so파일의 차이? 정도라고 해야하나요 ..?
실수연산 해결하기 위한 옵션을 추가해서 시간을 절반정도 단축시켰어요. -mfpu=vfp -mfloat-abi=softfp 를 썼습니다.
2배가량 빨라지는거 같더라고요.
비교하기가 좀 그렇긴하다만....빌드한 결과가 exe파일과 so파일의 차이? 정도라고 해야하나요 ..?
실수연산 해결하기 위한 옵션을 추가해서 시간을 절반정도 단축시켰어요. -mfpu=vfp -mfloat-abi=softfp 를 썼습니다.
2배가량 빨라지는거 같더라고요.
2009.11.24 10:19:46
제 짐작이 맞는지 보세요.
1. exe 확장자로 보아 프로그램 A는 cygwin 에서 빌드한 윈도우즈용 x86 실행파일이다. 당연히 x86 실수연산이 적용되었다.
2. android 어플에서 부른 것으로 보아 프로그램 B 는 cygwin 또는 linux에서 NDK로 빌드한 linux 용 ARM 공유 라이브러리다. FPU 인스트럭션(-mfpu=vfp )과 soft calling convention (-mfloat-abi=softfp ) 을 사용했다.
3. 프로그램 A 는 데스크탑 x86 에서 실행했고, 프로그램 B 는 같은 데스크탑에서 실행되고 있는 QEMU 에뮬레이터에서 실행했다.
4. 두 실행 시간에 커다란 차이가 보인다. 프로그램 A 가 훨씬 빠르다.
만일 맞다면 말씀하신 리눅스는 어떤 것을 가리키는 것인가요?
1. exe 확장자로 보아 프로그램 A는 cygwin 에서 빌드한 윈도우즈용 x86 실행파일이다. 당연히 x86 실수연산이 적용되었다.
2. android 어플에서 부른 것으로 보아 프로그램 B 는 cygwin 또는 linux에서 NDK로 빌드한 linux 용 ARM 공유 라이브러리다. FPU 인스트럭션(-mfpu=vfp )과 soft calling convention (-mfloat-abi=softfp ) 을 사용했다.
3. 프로그램 A 는 데스크탑 x86 에서 실행했고, 프로그램 B 는 같은 데스크탑에서 실행되고 있는 QEMU 에뮬레이터에서 실행했다.
4. 두 실행 시간에 커다란 차이가 보인다. 프로그램 A 가 훨씬 빠르다.
만일 맞다면 말씀하신 리눅스는 어떤 것을 가리키는 것인가요?
2009.11.24 13:31:54
잘 짐작하셨네요 ;;; ;무서울만큼;;
한 가지만 다르네요. 큰 차이는 없겠지만 QEMU 에뮬레이터가 아닌 android 포팅된 타겟보드(A)를 쓰고 있습니다.
에뮬과 보드, 둘 다 실행시켜봤는데 에뮬보단 보드가 조금 더 빠르게 반응하네요.
제가 말한 '리눅스'라는 것은, cygwin을 말한것이었습니다. 윈도상에서 리눅스 환경을 제공해주기 때문에...
그리고 또 다른 리눅스 환경에서도 작업이 이루어진 적이 있습니다.
그 작업은 안드로이드가 포팅되지 않은 타겟보드(B)이고.. 정확히 어떤 식으로 동작하는지는 잘 모르겠지만...
공유라이브러리를 만들고 그걸 호출하는 프로그램인듯 합니다.
(A)와 (B)의 스펙은 비슷합니다. 같은 CPU를 탑재하고 있구요.
(B)에서 작업할 때는 cygwin이 아닌, 리눅스 서버에서 라이브러리를 빌드했네요.
요점은 여기 있습니다. 같은 소스를 같은 스펙의 다른 타겟에 사용하는 것이 목표였습니다.
차이점은 android의 포팅유무와 JNI의 적용 유무입니다.
어떤 분들은 JNI가 성능저하를 일으킬 수도 있다고 하셨고, 또 어떤 분들은
android는 OS이고 중간에 VM을 거쳐야 하기 때문에 시간을 지체할 수도 있다고 하시네요.
두 가지 다 맞는 말일 수도 있겠지만, 지금만큼 많은 시간을 소요한다고 보기는 어려울듯 싶네요.
한 가지만 다르네요. 큰 차이는 없겠지만 QEMU 에뮬레이터가 아닌 android 포팅된 타겟보드(A)를 쓰고 있습니다.
에뮬과 보드, 둘 다 실행시켜봤는데 에뮬보단 보드가 조금 더 빠르게 반응하네요.
제가 말한 '리눅스'라는 것은, cygwin을 말한것이었습니다. 윈도상에서 리눅스 환경을 제공해주기 때문에...
그리고 또 다른 리눅스 환경에서도 작업이 이루어진 적이 있습니다.
그 작업은 안드로이드가 포팅되지 않은 타겟보드(B)이고.. 정확히 어떤 식으로 동작하는지는 잘 모르겠지만...
공유라이브러리를 만들고 그걸 호출하는 프로그램인듯 합니다.
(A)와 (B)의 스펙은 비슷합니다. 같은 CPU를 탑재하고 있구요.
(B)에서 작업할 때는 cygwin이 아닌, 리눅스 서버에서 라이브러리를 빌드했네요.
요점은 여기 있습니다. 같은 소스를 같은 스펙의 다른 타겟에 사용하는 것이 목표였습니다.
차이점은 android의 포팅유무와 JNI의 적용 유무입니다.
어떤 분들은 JNI가 성능저하를 일으킬 수도 있다고 하셨고, 또 어떤 분들은
android는 OS이고 중간에 VM을 거쳐야 하기 때문에 시간을 지체할 수도 있다고 하시네요.
두 가지 다 맞는 말일 수도 있겠지만, 지금만큼 많은 시간을 소요한다고 보기는 어려울듯 싶네요.
2009.11.24 14:29:03
아... 그러면 보드(B) 에 비해 안드로이드 환경인 보드 (A) 에서의 속도가 현저히 느리다는 뜻이군요.
보드 (B)에서는 C 로만 구성된 프로그램이고, 보드 (A) 는 JNI 를 통해 Java 로 한겹 둘러싼 프로그램이고요.
루프는 JNI 경계를 가로지르지 않고, 시간 측정도 C 함수 내부에서 이루어졌음에도 불구하고 현저한 차이가 난다는 뜻이지요?
JNI 없이 NDK로 보드 (A) 용 실행 파일을 만들어 비교하시면 변수 하나가 줄지 않을까요? 큰 차이가 없어야 맞지만, 사람이 하는일이라.
어떤 CPU를 쓰시는지 알 수 있을까요?
보드 (B)에서는 C 로만 구성된 프로그램이고, 보드 (A) 는 JNI 를 통해 Java 로 한겹 둘러싼 프로그램이고요.
루프는 JNI 경계를 가로지르지 않고, 시간 측정도 C 함수 내부에서 이루어졌음에도 불구하고 현저한 차이가 난다는 뜻이지요?
JNI 없이 NDK로 보드 (A) 용 실행 파일을 만들어 비교하시면 변수 하나가 줄지 않을까요? 큰 차이가 없어야 맞지만, 사람이 하는일이라.
어떤 CPU를 쓰시는지 알 수 있을까요?
2009.11.24 14:53:43
두 타겟 모두 armv6 를 사용하고 있습니다. (arm1176 계열)
H/W 스펙을 검색해보면 실수연산은 지원한다고는 나와있습니다만...
NDK로 실행파일을 만들어볼 수 있나요 ??
얕은 지식인지라.. 구글이 제공한 예제를 따라하는 수준밖에 되지않아 so파일밖에.....ㅠㅠ;;
크로스컴파일에 대해 조금 더 공부를 해봐야할 것 같네요.;;;
H/W 스펙을 검색해보면 실수연산은 지원한다고는 나와있습니다만...
NDK로 실행파일을 만들어볼 수 있나요 ??
얕은 지식인지라.. 구글이 제공한 예제를 따라하는 수준밖에 되지않아 so파일밖에.....ㅠㅠ;;
크로스컴파일에 대해 조금 더 공부를 해봐야할 것 같네요.;;;
2009.11.24 15:13:12
삼성 s3c6410 인가요?
실행파일을 만들려면 Android.mk 파일의 BUILD_SHARED_LIBRARY 를 BUILD_EXECUTABLE 로 바꿔주고 main() 함수 제공하시면 됩니다. 문서에는 나와있지 않은 것으로 알고 있습니다.
NDK 1.6 기준으로 말씀드리고 있습니다. 1.5는 확인해본바가 없습니다.
실행파일을 만들려면 Android.mk 파일의 BUILD_SHARED_LIBRARY 를 BUILD_EXECUTABLE 로 바꿔주고 main() 함수 제공하시면 됩니다. 문서에는 나와있지 않은 것으로 알고 있습니다.
NDK 1.6 기준으로 말씀드리고 있습니다. 1.5는 확인해본바가 없습니다.
2009.11.24 16:25:04
휴우.... 말씀하신대로 실행파일을 만들어서 해봤는데도 응답시간이 개선되지는 않네요 ㅋㅋ
뭣땜에 이런건지 모르겠습니다.;;;
컴파일러를 바꿔서 해결되는거면 좋으련만..ㅠㅠ
혹시 실수연산을 제외한 다른 부분에서 의심가는 부분은 없을까요 ??
지금 소스가 실수버전과 정수버전 두 가지가 있어서 두개를 비교해가면서 진행중인데,
옵션적용한 실수버전과 정수버전에서의 시간차이가 비슷비슷하게 나오고 있습니다.ㅠㅠ
뭣땜에 이런건지 모르겠습니다.;;;
컴파일러를 바꿔서 해결되는거면 좋으련만..ㅠㅠ
혹시 실수연산을 제외한 다른 부분에서 의심가는 부분은 없을까요 ??
지금 소스가 실수버전과 정수버전 두 가지가 있어서 두개를 비교해가면서 진행중인데,
옵션적용한 실수버전과 정수버전에서의 시간차이가 비슷비슷하게 나오고 있습니다.ㅠㅠ
2009.11.24 17:06:28
뭔가 공개해도 좋을만한 수준의 단순한 코드로 실험한 결과를 알려주시면 좋지 않을까 생각됩니다. 가령 -O0 옵션에서의 실수 연산 반복같은 것 말입니다. 시간 측정법과 측정 결과값도 명확히 밝혀 주시면 더 좋고요.
그런데 정수 버전역시 시간차가 난다는 뜻인가요? 그냥 CPU clock이 다른건 아니지요? :)
뭔가 원격 의견 교환으로는 해결하기 힘든 곳으로 가고 있다는 느낌이 드네요.
그런데 정수 버전역시 시간차가 난다는 뜻인가요? 그냥 CPU clock이 다른건 아니지요? :)
뭔가 원격 의견 교환으로는 해결하기 힘든 곳으로 가고 있다는 느낌이 드네요.
2009.11.24 18:29:36
소스 자체가 제가 개발한 것이 아니라 어느 부분을 공개할 수 있을지를 모르겠습니다.;;
정수버전도 역시 오랜 시간이 걸린다는 뜻입니다.
실수버전에 비해 향상된 속도를 기대했지만 그러지를 못했네요.
시간측정은 clock()을 이용해서 체크했습니다.
보드(B)에서는 1초 이내의 시간이 소요되고, 보드(A)에서는 12초 가량의 시간이 걸리네요.ㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠ
정수버전도 역시 오랜 시간이 걸린다는 뜻입니다.
실수버전에 비해 향상된 속도를 기대했지만 그러지를 못했네요.
시간측정은 clock()을 이용해서 체크했습니다.
보드(B)에서는 1초 이내의 시간이 소요되고, 보드(A)에서는 12초 가량의 시간이 걸리네요.ㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠ
2009.11.24 21:17:47
개발 중인 제품의 소스 코드를 말씀드린 것이 아니라, 같은 상황이 재현되는 최소한의 코드 영역만을 뽑아낸 코드를 준비할 수도 있지 않을까요? 그런 것이 없다면 이제 디버깅에 대한 일반론을 펴는 수밖에는 없을듯. 현재 까지의 사실들을 종합해볼 때 남은 아이디어들은
1. 정수 연산역시 현격한 시간차를 보인다. => FPU 문제는 아닙니다. 적어도 FPU 만의 문제는 아닙니다.
2. 컴파일러의 최적화 옵션이 동작하고 있다면 모두 끄고 비교해야 한다.
3. 정수 연산 도중 wait 가 삽입될 가능성이 있는가?
3.a If Yes => 어떤 wait 인가? RAM? IO? 로그?
3.b If No => 두 보드의 MIPS 가 다르다. 측정할 수 있는가? 원인은? 전압?
4. 두 컴파일러가 만들어낸 어셈블리 코드를 읽고, 인스트럭션의 사이클 수를 계산할 수 있는가?
5. 수행 시간의 차이가 나기는 하지만 결과는 동일한가?
별 도움이 안되지요?
1. 정수 연산역시 현격한 시간차를 보인다. => FPU 문제는 아닙니다. 적어도 FPU 만의 문제는 아닙니다.
2. 컴파일러의 최적화 옵션이 동작하고 있다면 모두 끄고 비교해야 한다.
3. 정수 연산 도중 wait 가 삽입될 가능성이 있는가?
3.a If Yes => 어떤 wait 인가? RAM? IO? 로그?
3.b If No => 두 보드의 MIPS 가 다르다. 측정할 수 있는가? 원인은? 전압?
4. 두 컴파일러가 만들어낸 어셈블리 코드를 읽고, 인스트럭션의 사이클 수를 계산할 수 있는가?
5. 수행 시간의 차이가 나기는 하지만 결과는 동일한가?
별 도움이 안되지요?
2009.11.25 11:24:17
1. 저도 FPU 뿐만 아니라 다른 문제도 있을 것이라 짐작됩니다.
2. 최적화옵션을 제외할 경우는 실수버전의 반응속도가 느려집니다. (약 2배가량)
3. 이건 잘 모르겠네요 ;; 다른 분들과 상의를 해봐야할 것 같아요.
4. 이건 한 번 조사해볼만한 내용인 것 같습니다.
5. 시간은 차이가 나지만 결과는 동일합니다.
코드 관련한 부분은 해당 개발자분과 상의를 해보아야 할 듯 합니다.;;
많은 관심 가져주셔서 감사합니다. ^^ 여러 방면에서의 경우를 생각해주신 것만으로도 저에게는 큰 도움이 되네요.
공부를 하면 할수록, 더 어려워지는 신비한 세계군요 ㅠㅠ
2. 최적화옵션을 제외할 경우는 실수버전의 반응속도가 느려집니다. (약 2배가량)
3. 이건 잘 모르겠네요 ;; 다른 분들과 상의를 해봐야할 것 같아요.
4. 이건 한 번 조사해볼만한 내용인 것 같습니다.
5. 시간은 차이가 나지만 결과는 동일합니다.
코드 관련한 부분은 해당 개발자분과 상의를 해보아야 할 듯 합니다.;;
많은 관심 가져주셔서 감사합니다. ^^ 여러 방면에서의 경우를 생각해주신 것만으로도 저에게는 큰 도움이 되네요.
공부를 하면 할수록, 더 어려워지는 신비한 세계군요 ㅠㅠ
arm-eabi-4.2.1 아래에 컴파일러가 들어있는 것도 맞습니다.
이론적으로는 시스템 mk 파일들을 수정하시면 컴파일러를 바꿀 수 있습니다. 하지만 NDK가 그런 사용을 지원하지는 않습니다.
혹시 다른 컴파일러로 바꾸고자하시는 이유를 알 수 있을까요?