C++Builder  |  Delphi  |  FireMonkey  |  C/C++  |  Free Pascal  |  Firebird
볼랜드포럼 BorlandForum
 경고! 게시물 작성자의 사전 허락없는 메일주소 추출행위 절대 금지
분야별 포럼
C++빌더
델파이
파이어몽키
C/C++
프리파스칼
파이어버드
볼랜드포럼 홈
헤드라인 뉴스
IT 뉴스
공지사항
자유게시판
해피 브레이크
공동 프로젝트
구인/구직
회원 장터
건의사항
운영진 게시판
회원 메뉴
북마크
볼랜드포럼 광고 모집

헤드라인 뉴스
[365] Delphi/C++Builder XE3, 네이티브 버리고 LLVM 대변신?
박지훈.임프 [cbuilder] 11197 읽음    2012-06-08 04:45
얼마전의 C++빌더 로드맵에 이어, 엠바카데로 일본 지사에서 며칠 전 개최된 '디벨로퍼 캠프' 행사에서, 델파이/C++빌더 XE3 버전에 대한 좀 더 구체적인 정보들이 흘러나왔습니다.

이 행사에서 나온 정보들 중, 가장 핵심적이고 놀라운 것은, 델파이와 C++빌더의 컴파일러가 LLVM 기반으로 바뀐다는 것입니다. 이건 델파이와 C++빌더, 아니 터보 파스칼과 터보 C 이래 가장 큰 사건입니다. 왜 그런지 알아보시죠.

아래는, 일본 개발자 한분이 블로그에 올린 글을 구글 번역기로 돌린 후 문맥을 손본 내용입니다.

Owl's perspective: 第22回エンバカデロ・デベロッパーキャンプ(東京)まとめ
http://owlsperspective.blogspot.kr/2012/06/embarcadero-devcamp-22-tokyo-summary.html



2012 년 6 월 7 일
제 22 회 엠바카데로 디벨로퍼 캠프 (도쿄) 정리

제 22 회 엠바카데로 디벨로퍼 캠프 (도쿄)의 개인적인 요약입니다. 또한 아래의 내용은 보증하는 내용이 아니므로 주의하시기 바랍니다 .
[G1] 키노트 세션 "엠바카데로 2012년 제품 전략"

2011년 실적은 호조로 매출 10 % 성장하여 약 75 억 엔. 보유 자금이 넉넉하다.

2012년 이후를 위한 3 가지를 생각하고 있다.
기존 제품 : RAD Studio XE3, ER / Studio ㅖPortal
인수 : 자금적인 여유가 있고, 경기 침체로 인해 상대적으로 저렴하게 인수를 할 수 있기 때문에 연내에 1~3 개 정도의 인수를 목표로 하고 있다.
AppWave

2012년 제품 계획
차세대 컴파일러 아키텍처
LLVM을 기반으로, 델파이 F/E 또는 C++ F/E (= Clang + PME) → LLVM IR → LLVM Intel / ARM / Other CPU Code Gen 하는 구성에서 컴파일러를 다시 구축. (컴파일러의 프론트 엔드, 백 엔드에 대해서는 wikipedia 컴파일러의 설계 섹션 참조)
XE3
Delphi / C++ : iOS에 네이티브 대응
C++Builder : x64 지원
FireMonkey : Hyper-Real 3D UI, 홀로 그래픽 3D UI
HTML5 : 비주얼 HTML5/CSS3 클라이언트 개발 - Delphi / C++Builder / RadPHP

C++Builder 2012 로드맵
64bit 툴 체인 : IIS 쉘 확장, SQL Server 인터페이스, 64bit 디바이스 드라이버
C++11 : Boost 및 ACE 에 대응
ARM : iOS / Andriod 지원 ARMv7 바이너리 출력 FireMonkey 장치 (GPS, 가속도계 등의 센서)에 대한 기본 지원
일정 :
현재 베타 1, 곧 베타 2가 시작
2012 년 하반기 (Q3) : C++11, x64 Hyper-Real Holographic (HRH)
2013 년 초 : ARM iOS / Android

ER / Studio
데이터 거버넌스, 모델 간 추적
메타데이터 소셜라이즈
Social Portal
최대 경쟁 업체인 CA(ERWin)이 올해부터 일본어 지원을 종료하기 때문에 기회로 생각하고 있다. (주: 사실 여부는 확인되지 않음)

AppWave : 올해도 적극적으로 버전 업을 진행

[T2]​​ Delphi / C++Builder 기술 세션 "RAD Studio 차기 버전 미리보기 - 64 bit화를 추진 C++Builder"
C++Builder
C99 , C++11 표준 준수도 향상
LLVM 기반 (베타 1에서는 아직 x64 전용)
ARM에서는 GDB 디버깅하게 된다
STL (Dinkumware) Boost (BoostPro), ACE (ADAPTIVE Communication Environment), CORBA (TAO)를 지원할 예정
Windows x64, iOS (뮬레이터 장치), Android

Delphi XE3
FireMonkey 강화
작업 목록
제스처
앵커
레이아웃 매니저
Audio / Video : DirectShow / QuickTime
물리 엔진
Indy for iOS
dbExpress for iOS
FPC 베이스에서 LLVM 베이스로 마이그레이션

C++11 : C++에서 추가된 유용한 기능 소개 - auto의 형식 유추 와 lambda 등

[T3] Delphi / C++Builder 기술 세션 "FireMonkey 클래스"
FireMonkey 프로그래밍의 데모 관련 정보:
Team Japan≫개발자 캠프 FireMonkey3D 애플리케이션 프로젝트 for Windows / MacOSX
Embarcadero Discussion Forums : OSX 애플리케이션 종료 처리 코드

[T4] Delphi / C++Builder 기술 세션 "애플리케이션 비대화, 팀 구성원 증가 등의 프로젝트 확대, RAD 환경에서 어떻게 대응할 것인가?"
정리도 두서도 없는 패널 토론. 좀 더 교육이 필요하지... 문서·지역 관리자 아라이 씨의 엠바카데로 테크놀로지 내부 개발 과정의 해설도 있어, 이쪽은 여러가지 재미있는 이야기였습니다.

여기서 이야기가 나왔던 FireMonkey   (일본어 문서 wiki)에 대해서는, Delphi에서 빌드하는 방법을 모처 씨가 쓴 블로그 글들이 있습니다.
모처 - Delphi에서 Jenkins을 사용하려면 (1)
모처 - Delphi에서 Jenkins을 사용하려면 (2)
모처 - Delphi에서 Jenkins를 사용하려면 (3)
모처 - Delphi에서 Jenkins을 사용하려면 (4)

[G5] Q & A 세션 "아무거나 질문! 엠바카데로에게 물어보자"
엠바카데로 테크놀로지 전세계 매출에서 일본의 매출 비율은 8 % 정도.
Clang / LLVM은 아마도 오픈소스 프로젝트부터 포크하여 독자적인 버전이 될 것. (그런 뉘앙스로 발언)
PC에서 IDE의 점유율은 Microsoft가 80%, Embarcadero가 10%, 그 이외가 10% 정도라고 파악하고 있다.
(이하 생략)



여기서 F/E라고 쓰인 것은 컴파일러의 프론트 엔드(Front End)를 말합니다.

위에서 LLVM이란, 여러 언어 컴파일러의 집합체이자 버추얼머신, 그리고 JIT 컴파일러로 이루어진, '컴파일러 인프라스트럭처' 입니다. 여기에 포함된 프로그래밍 언어들은 LLVM을 위한 중간 언어(LLVM IR)로 컴파일되고, 이것을 각 OS 플랫폼별로 다시 컴파일하여 네이티브 코드가 나옵니다.



즉, 위 본문에서 말하는 컴파일러 프론트 엔드란 1차적인 언어 컴파일러로서 LLVM IR 코드를 만들어내는 역할을 하고, 이것을 OS별 네이티브 바이너리로 컴파일해내는 것이 백 엔드입니다. 또 위에서 거론되는 Clang은 LLVM의 C/C++/Objective C 프론트엔드입니다.

LLVM 홈페이지에 따르면 현재 LLVM에는 파스칼이 포함되어 있지 않으므로, 엠바카데로는 LLVM에 독자적으로 델파이 컴파일러를 구현하고, 그렇게 완성된 엠바카데로 버전의 LLVM에서 C++빌더와 델파이 양쪽의 프론트 엔드를 통해 IR 코드를 생성하고 다시 OS별 네이티브 코드를 컴파일해내는 방식으로 가려는 것으로 보입니다. 이렇게 되면 C++빌더와 델파이의 경계가 전보다도 더욱 모호해지겠습니다.

(LLVM은 현재 자바와 포트란도 지원하므로, IDE나 라이브러리와의 연동만 해결한다면 Delphi for Java나 FortranBuilder 같은 것도 가능하겠군요. -.-;;)

또한, Clang을 통한다고 한 것을 보면, 기존의 오랫동안 유지되어온 터보 C, 볼랜드 C++ 계보의 컴파일러 자산을 포기하고 Clang으로 대체하려고 하는 것으로 보이네요. 약속했던 C++11, C99 지원도 기존의 볼랜드 C++ 컴파일러가 아닌 Clang이 지원하는 기능에 의존하는 듯 합니다. 마찬가지로, iOS나 안드로이드 지원도 엠바카데로의 자체 구현이 아니라 이런 LLVM의 기능에 기대어서 구현될 것으로 보이구요.

이런 변화는... 한마디로 말하자면, 개발툴의 심장을 갈아치우는 대작업입니다. 델파이와 C++빌더의 컴파일러는, 1980년대초 이후로 30년 가까이 업그레이드되면서 개발자들과 함께 해온, 역사 그 자체이면서 아이덴티티이기도 했는데요. 이런 엠바카데로의 대변신이, 어떤 결과를 가져올지... 개인적으로는 믿어보려고 노력을 해도, 기대보다는 불안감이 더 크게 다가오는 것이 솔직한 심정입니다.

또... LLVM이 최종 바이너리를 OS별 네이티브로 내놓는 것은 틀림없는 사실이지만, 전통적으로 우리가 알고 있는 네이티브 컴파일러와는 거리가 상당한 것도 부인할 수 없는 사실입니다. LLVM이 최적화가 대단해서 LLVM에서 만들어낸 바이너리 코드가 오히려 전통적인 네이티브 바이너리보다 더 빠를 수도 있다는 얘기들도 있지만, OS에 중립적인 중간 코드를 거쳐온 네이티브 코드가, 정말로 해당 OS와 해당 CPU 아키텍처를 제대로 활용하는 네이티브로서 최적으로 동작할지에 대해서는, 아무리 생각해도 의문스럽습니다. 자바나 자바스크립트 등 언어의 입장에서는 LLVM 코드의 성능이 놀라울 정도로 빠를 수 있겠지만, 이전부터 최고의 네이티브 성능을 자랑해온 델파이나 C++빌더에서도 과연 그럴까요.

물론, 엠바카데로가 LLVM을 지금의 디폴트 오픈소스 버전보다 얼마나 더 발전시키느냐도 중요한 변수입니다. 수십년간 발전시켜온 귀중한 자산을 뒤로 하고 오픈소스로 심장을 갈아치우겠다는 결심을 했으니, 엠바카데로의 개발팀들도 각오가 비장하리라 생각됩니다. 아무쪼록, 멋진 제품으로 만들어내서 이런 우려들을 불식시켜주길.
Lyn [tohnokanna]   2012-06-08 08:58 X
드디어 Turbo C++ 컴파일러의 대가 끊어지는구나.

바이바이 엠바카데로 두번다시 널 쓸일은 없겠지
김상구.패패루 [peperu]   2012-06-08 11:31 X
LLVM이 컴파일 성능은 gcc에 비해 분명 좋지만 런타임 성능은 아직까지는 gcc보다 다소 느린 듯 하더군요.
일단 애플이 스폰서로 있고 XCode도 LLVM으로 교체해서 성능 향상에 재미를 봤으니 앞으로 많이 발전하기는 하겠지만...
엠바카데로도 자사 컴파일러를 프론트엔드와 백엔드를 분리한 구조로 바꾸는 작업은 코드기어 시절부터 진행해 온 것으로 아는데 결국 LLVM으로 간다... 기대반 우려반... 결국 C++Builder는 gcc가 아닌 VC++와 런타임 성능을 비교당할텐데 우려쪽이 약간 더 큰게 사실입니다.
Lyn [tohnokanna]   2012-06-08 11:51 X
GCC건 LLVM 이건 VC++이나 ICC에 런타임 성능이 비교대상조차 되지 못하고있죠...

BCB도 VC++에 비해 2~3배 느린 결과가 흔히 나왔는데.
Lyn [tohnokanna]   2012-06-08 11:52 X
gcc처럼 정말 오픈소스라고할 수 있는놈도 아닌 사실상 애플의 프로젝트에 가까운 LLVM이라니 ..
박지훈.임프 [cbuilder]   2012-06-08 12:54 X
Lyn님, LLVM의 원 개발자가 애플에 가면서 애플의 직간접 영향력이 커진 것은 사실이긴 하지만, 그렇다고 '진정한 오픈소스'가 아니라고 말할 수 있는 건 아니죠. 여러 기업들 중 애플이 가장 많이 쓰고 있을 뿐... 애플 바깥의 오픈소스 개발자들의 공헌도도 애플 내부 못지 않게 큰 만큼, 제가 보기에 LLVM의 오픈소스 성격 자체에는 별 문제가 없다고 생각됩니다.

자바의 경우엔 오픈소스가 아니었음에도 썬의 아래에서 사실상 많은 개발자들에게 오픈소스와 비슷한 감성으로 받아들여지면서 발전했죠. 물론 자바에 대한 소유욕을 드러내는 지금의 오라클 시절은 제외하고 말이죠.
박지훈.임프 [cbuilder]   2012-06-08 13:10 X
그리고... VC++이나 인텔 C++의 성능은 이제 관심 밖의 문제입니다. 식사의 메인 메뉴로 크로스컴파일을 식탁에 올려버렸으니, 플랫폼 벤더 의존성이 너무 강한 VC++이나 인텔 C++은 성능이 높건 말건 이슈 자체가 안되게 됩니다. 이 판이 더 커지게 되면 VC++과 인텔 C++은 거의 왕따 당할 수도 있죠.

아쉽게도 거기에 기존의 C++빌더 컴파일러도 도매금으로 휩쓸려가게 되어버렸습니다만...
Lyn [tohnokanna]   2012-06-08 14:58 X
VC++이나 ICC가 크로스컴파일러가 아닌게 아니잖아요.

ICC는 윈도우, 리눅스, MacOS를 다 지원하고 있고(단 x86계열 한정)
VC++도 x86, MIPS, ARM 등을 다 지원 하고 있죠.(단 윈도우 한정)

오히려 크로스 컴파일러가 아닌놈이 메이저 C++컴파일러가 BC++이 거의 유일햇죠.
VC++과 인텔C++이 왕따  당할 이유는 어디에도 안보이는것 같은데요. 그저 궂이 MS는 윈도우 외의 OS용 컴파일러를 만들 이유가 없을 뿐이고 인텔은 x86 이외의 아키텍쳐용 컴파일러를 만들 이유가 없을뿐이죠
Lyn [tohnokanna]   2012-06-08 14:59 X
그리고 성능이 중요하지 않은 시장은 이미 다 非Native 계열에 털렷죠. 이제와서 Native 컴파일러를 고집해야 하는 이유는 오직 하나 성능이죠
Lyn [tohnokanna]   2012-06-08 15:06 X
그리고 엠바카데로가 크로스컴파일이라는 뷔페에서 어떤 요리를 접시에 담더라도 MS나 Intel보다 종류가 다양할거란 생각은 별로 안드네요
박지훈.임프 [cbuilder]   2012-06-08 15:16 X
허허~ 암만 그래도 VC++은 윈도우 개발툴이고, 인텔 C++은 x86 컴파일러죠.
린님 스스로도 말씀하셔놓고 왕따 당할 이유가 안보인다니요.

물론 저도 크로스컴파일이 주요 이슈로 부상한다는 것을 전제로 한 얘기입니다만, 주목받는 플랫폼의 가지수가 너무 많아지고 있어서 적어도 당분간.. 적어도 10년 정도까지는 제대로 된 크로스컴파일이라면 큰 주목을 받을 것은 당연해보입니다.

엠바카데로가 기존의 심장을 버리고 LLVM을 선택하는 것도 당연히 쉽지 않은 선택이었을텐데도 그랬던 이유도, 이런 전망 때문이었을 겁니다. 윈도우 온리와 x86 온리는 이제 고립되어버릴 수밖에 없으니까요.
박지훈.임프 [cbuilder]   2012-06-08 16:16 X
LLVM으로의 전환에서 아쉬운 건... 엠바카데로가 여러차례 크로스플랫폼에 대한 크고 작은 설문조사를 했으면서도, LLVM에 대해서는 언급조차 안한 채로 iOS 네이티브 지원, 안드로이드 네이티브 지원, 이런 거 원하냐 아니냐만 조사했다는 겁니다. 개발자들은 엔드 유저가 아니라서 최종적인 기술 구현 여부에만 신경쓰는 게 아닌데.... 쩝.....
Lyn [tohnokanna]   2012-06-08 16:57 X
특히... Native 개발자들은 컴파일 과정에 관여해야할 경우가 있으니까요...
김도완 [purplecofe2]   2012-06-08 18:36 X
VC++이니 ICC하는 것은 x86에서나 최적화가 강하지 ARM쪽으론 문제가 있지 않을까요? 지금 ARM 서버도 곧 나올 예정이고 모바일 쪽에서는 x86은 전기먹는 하마의 낙인이 쉽게 벗겨지지 않고 있죠. 미래를 위해서 나은 결정이라고 생각됩니다.
Lyn [tohnokanna]   2012-06-09 13:31 X
VC++로 ARM 코딩해본게 꽤 예전일이긴 한데...

그래도 gcc의 성능보단 압도적으로 좋았었습니다. ARM서버는 가망이 없다고 생각하구요 개인적으로.
아무리 CPU가 전기 효율이 좋아도 1머신의 절대적인 성능이 딸리는 상황에선 서버 대수가 한참 늘어나게 되니까요. CPU 효율이 좋아도 다른 부품 수가 그만큼 늘어나면 의미가 없죠.
박지훈.임프 [cbuilder]   2012-06-09 19:48 X
원래의 논의와는 다른 얘기이긴 하지만...

저도, 인텔 CPU들의 전력 소모가 빠른 속도로 떨어지고 있어서, 단지 전력 소모만의 강점을 갖는 ARM 서버가 크게 확산되기는 어려울 거라고 생각합니다. ARM의 특성과 장단점에 맞도록 기존의 각종 서비스들을 뜯어고쳐야 하는 비용도 만만치 않을 거 같고요..

장기적으로는, ARM의 확산은 모바일에서도 어느 정도 저지되지 않을까 관측하고 있습니다. PC 윈도우 머신이 ARM 머신과 완전히 동등한 수준까지는 아니더라도 비교 가능한 수준... 그러니까 뭐 60~70% 정도의 전력 효율 수준으로만 따라가더라도 태블릿 등의 기기에서 PC 윈도우가 상당한 수준으로는 성장할 수 있을 것으로 생각하고 있습니다. 특히 IT 시장은 소비자 시장과 기업 시장으로 나뉘어지는데, 기업 시장에서는 기존의 인텔 CPU 기반의 직간접적인 인프라들이 워낙 크기 때문에 기업시장에서 반길 것으로 보는 거죠.
남병철.레조 [lezo]   2012-06-12 00:17 X
범용 네이티브 성능의 크로스 컴파일 제품이면 그 쓰임이나 시장이 가장 넓을 것입니다.
사실상 기존 시장에 범용적인 수준이라도 네이티브의 속도라는 매력은 충분할 것입니다.
그리고 각 플랫폼별 최적화 라이브러리가 준비된다면,... 최적화란 이슈에 크로스플랫폼이란 이슈가 부함되는지가 의문이지만,
시간이 지나면서 몇몇 인기있는 라이브러리 정도가 지원되도 사실상 전략은 충분히 희망적이지 않을까요?
이번 이슈는 어릴때 호기심으로 자극됬다 석화되기 시작한 스터디근을 자극하기에 충분한듯 합니다. ㅋㅋ
강재호.만해 [greenuri]   2012-06-15 16:08 X
다수의 Linux, Unix를 지원하는 크로스 컴파일로로 성장할 가능성은 있나요?
java의 장점인 포팅이슈를 C++에서 해결 할수 있을런지..
mixxer [mixxer]   2012-06-17 13:20 X
Arm 서버는 이미 가상화 이슈와 연계 되고 있습니다. I/O 대기시간이 비교적으로 많은 애플리케이션이라면 소비 전력당 퍼포먼스에서는 Arm 서버가 더 효율적이라는 논문도 있고요,
얼마전에 2U Rack 에 Quadcore Arm 48개가 들어간 서버도 출시 되었습니다 소비전력인 300W라네요..

http://wiki.xen.org/wiki/XenARM
http://blog.ahems.co.kr/archives/363
아제나 [azena]   2012-06-25 17:20 X
지금와서 어중간한 포지션을 잡다가 아예 잊혀지는게 아닌지 걱정이 되는군요.

ARM  서버의 발전 가능성이 높은 이유는 멀티프로세스를 하기에 설계가 복잡하지 않습니다.
CISC처럼 캐쉬 의존적이지도 않고, 좀 느려도 많이 꼽아 놓으면 장땡이죠;;;;;;;
고흥식 [revofu]   2012-08-04 05:30 X
제 개인적 생각으로는 엠바카데로의 역량과 관련 된 문제로 보입니다. LLVM의 효용성이나 성능 문제를 떠나 LLVM을 사용하면 frontend나 backend 모두 엠바카데로가 직접 만들 필요가 없어집니다. 오픈소스를 그냥 주워 먹겠다는 생각으로 밖에 안 보입니다. 앞으로 컴파일러 개발사라기 보다는 IDE와 framework개발사라는 칭호가 더 어울릴 것 같습니다. 문제는 IDE도 엠바카데로가 인수한 이후에 발전이 안보인다는 점입니다.

+ -
이전글:  
다음글:  
Google
Copyright © 1999-2015, borlandforum.com. All right reserved.