Offcanvas

������������

“목표는 C++ 현대화”··· 실험적 컴파일러 ‘Cpp프론트’ 공개돼

‘Cpp프론트(Cppfront)’는 유서 깊은 프로그래밍 언어를 ‘10배 더 간단하고, 안전하며, 도구를 사용하기 쉽게’ 만드는 대체 C++ 구문용 실험적 컴파일러다.    C++ 언어가 ‘Cpp프론트’라는 제안에 따라 더 간단하고 안전해질 예정이다. 이는 유명 C++ 개발자 허브 셔터가 제안한 실험적인 C++ 프론트엔드다. 그는 ISO C++ 위원회 의장, C++ 기능 설계자, 마이크로소프트 소프트웨어 아키텍트 등을 맡고 있다.  셔터는 해당 프로젝트의 깃허브 리포지토리에서 이를 C++의 중요한 발전이라고 언급하면서, “Cpp프론트는 C++이 10배 더 간단하고, 안전하며, 쉽게 도구를 사용할 수 있게 진화할 수 있는지 탐구하도록 설계된 실험적인 컴파일러다”라고 설명했다.  그에 따르면 대체 C++ 구문은 ‘오늘날 존재하지 않는 새로운 코드의 거품’을 제공하여, C++ 언어 설계자가 기본값을 변경하거나, 안전하지 않은 파트를 제거하거나, 언어를 문맥에서 자유롭거나 순서 독립적으로 만드는 등 임의적인 개선을 할 수 있게 한다. 유형 및 메모리 안전은 기본으로 지원된다.  이어 셔터는 “또한 두 번째 구문을 통해 파서(parser), 리팩토링 및 기타 도구를 쉽게 작성할 수 있도록 한다. 아울러 구문이 현 C++보다 2배로 줄어들어 C++ 20 모듈과 C++ 23 import std를 기본값으로 만든다”라고 전했다.  Cpp프론트 컴파일러는 현재 진행 중인 프로젝트다. 이 프로젝트 자체는 지난 7년 동안 개발돼 왔지만 지난주 미국 콜로라도주 오로라시에서 열린 컨퍼런스(CppCon)에서 일종의 ‘데뷔 파티’가 있었다. Cpp프론트는 MSVG, GCC, Clang을 포함한 메이저 C++ 20 컴파일러로 빌드된다. 지침은 깃허브에서 확인할 수 있다.  한편 지난 7월 말 구글은 C++의 후계자를 목표로 개발 중인 카본(Carbon)을 공개한 바 있다. 카본을 통해 C++와의 원활한 양방향 상호...

C++ 프로그래밍 언어 개발 언어 컴파일러 Cpp프론트 소프트웨어 개발 개발 도구

2022.09.22

‘Cpp프론트(Cppfront)’는 유서 깊은 프로그래밍 언어를 ‘10배 더 간단하고, 안전하며, 도구를 사용하기 쉽게’ 만드는 대체 C++ 구문용 실험적 컴파일러다.    C++ 언어가 ‘Cpp프론트’라는 제안에 따라 더 간단하고 안전해질 예정이다. 이는 유명 C++ 개발자 허브 셔터가 제안한 실험적인 C++ 프론트엔드다. 그는 ISO C++ 위원회 의장, C++ 기능 설계자, 마이크로소프트 소프트웨어 아키텍트 등을 맡고 있다.  셔터는 해당 프로젝트의 깃허브 리포지토리에서 이를 C++의 중요한 발전이라고 언급하면서, “Cpp프론트는 C++이 10배 더 간단하고, 안전하며, 쉽게 도구를 사용할 수 있게 진화할 수 있는지 탐구하도록 설계된 실험적인 컴파일러다”라고 설명했다.  그에 따르면 대체 C++ 구문은 ‘오늘날 존재하지 않는 새로운 코드의 거품’을 제공하여, C++ 언어 설계자가 기본값을 변경하거나, 안전하지 않은 파트를 제거하거나, 언어를 문맥에서 자유롭거나 순서 독립적으로 만드는 등 임의적인 개선을 할 수 있게 한다. 유형 및 메모리 안전은 기본으로 지원된다.  이어 셔터는 “또한 두 번째 구문을 통해 파서(parser), 리팩토링 및 기타 도구를 쉽게 작성할 수 있도록 한다. 아울러 구문이 현 C++보다 2배로 줄어들어 C++ 20 모듈과 C++ 23 import std를 기본값으로 만든다”라고 전했다.  Cpp프론트 컴파일러는 현재 진행 중인 프로젝트다. 이 프로젝트 자체는 지난 7년 동안 개발돼 왔지만 지난주 미국 콜로라도주 오로라시에서 열린 컨퍼런스(CppCon)에서 일종의 ‘데뷔 파티’가 있었다. Cpp프론트는 MSVG, GCC, Clang을 포함한 메이저 C++ 20 컴파일러로 빌드된다. 지침은 깃허브에서 확인할 수 있다.  한편 지난 7월 말 구글은 C++의 후계자를 목표로 개발 중인 카본(Carbon)을 공개한 바 있다. 카본을 통해 C++와의 원활한 양방향 상호...

2022.09.22

아줄, ‘클라우드 네이티브 컴파일러’ 출시··· “클라우드에 자바 컴파일 제공”

‘클라우드 네이티브 컴파일러(Cloud Native Compiler)’ 서비스는 JVM 전체에서 이전에 최적화된 컴파일을 재사용하여 자바 애플리케이션 성능을 향상시킨다.    자바 소프트웨어 업체 아줄(Azul)이 JVM의 성능 및 시작 속도를 높이는 클라우드 기반 컴파일 서비스 ‘클라우드 네이티브 컴파일러’를 출시했다. 이를 통해 자바(Java), 스칼라(Scala), 코틀린(Kotlin), 클로저(Clojure), 그루비(Groovy), 제이루비(JRuby) 등 JVM 기반 언어의 성능이 향상됐다고 회사 측은 밝혔다.  회사에 따르면 아줄 인텔리전스 클라우드(Azul Intelligence Cloud) 플랫폼의 제품으로 공개된 클라우드 네이티브 컴파일러는 연결되는 모든 JVM의 성능 및 시작 속도를 강화하기 위해 JVM 전체에서 이전에 최적화된 컴파일을 탄력적으로 확장 및 축소하고 재사용한다. 또한 모든 자바 애플리케이션과 호환되는 클라우드 네이티브 컴파일러는 JVM(Java Virtual Machine)에서 JIT(Just-in-tim) 컴파일을 분리하며, 징(Zing)이라고 알려진 아줄의 고성능 자바 런타임 ‘플랫폼 프라임(Platform Prime Java)’과 함께 작동한다고 회사 측은 설명했다.    클라우드 네이티브 컴파일러는 전체 쿠버네티스 환경에서 클라우드 네이티브 애플리케이션으로 실행된다. 모든 클라우드에서 사용할 수 있다. 이 밖에 클라우드 네이티브 컴파일러로 얻을 수 있는 이점은 다음과 같다.  • JIT 컴파일을 클라우드 리소스로 전환해 운영 비용을 절감할 수 있다.  • 프론트엔드, 백엔드, API 게이트웨이, 컨테이너화된 애플리케이션, 마이크로서비스를 포함한 여러 애플리케이션의 처리량 및 응답성을 향상시켜 애플리케이션 성능을 개선한다.  • 아파치(Apache)의 카산드라(Cassandra) 데이터베이스, 솔라(Solr) 검색엔진, 카프카(Kaf...

자바 아줄 클라우드 컴파일러 스칼라 코틀린 클로저 그루비 제이루비 자바 애플리케이션 JVM JIT 쿠버네티스 컨테이너

2021.12.16

‘클라우드 네이티브 컴파일러(Cloud Native Compiler)’ 서비스는 JVM 전체에서 이전에 최적화된 컴파일을 재사용하여 자바 애플리케이션 성능을 향상시킨다.    자바 소프트웨어 업체 아줄(Azul)이 JVM의 성능 및 시작 속도를 높이는 클라우드 기반 컴파일 서비스 ‘클라우드 네이티브 컴파일러’를 출시했다. 이를 통해 자바(Java), 스칼라(Scala), 코틀린(Kotlin), 클로저(Clojure), 그루비(Groovy), 제이루비(JRuby) 등 JVM 기반 언어의 성능이 향상됐다고 회사 측은 밝혔다.  회사에 따르면 아줄 인텔리전스 클라우드(Azul Intelligence Cloud) 플랫폼의 제품으로 공개된 클라우드 네이티브 컴파일러는 연결되는 모든 JVM의 성능 및 시작 속도를 강화하기 위해 JVM 전체에서 이전에 최적화된 컴파일을 탄력적으로 확장 및 축소하고 재사용한다. 또한 모든 자바 애플리케이션과 호환되는 클라우드 네이티브 컴파일러는 JVM(Java Virtual Machine)에서 JIT(Just-in-tim) 컴파일을 분리하며, 징(Zing)이라고 알려진 아줄의 고성능 자바 런타임 ‘플랫폼 프라임(Platform Prime Java)’과 함께 작동한다고 회사 측은 설명했다.    클라우드 네이티브 컴파일러는 전체 쿠버네티스 환경에서 클라우드 네이티브 애플리케이션으로 실행된다. 모든 클라우드에서 사용할 수 있다. 이 밖에 클라우드 네이티브 컴파일러로 얻을 수 있는 이점은 다음과 같다.  • JIT 컴파일을 클라우드 리소스로 전환해 운영 비용을 절감할 수 있다.  • 프론트엔드, 백엔드, API 게이트웨이, 컨테이너화된 애플리케이션, 마이크로서비스를 포함한 여러 애플리케이션의 처리량 및 응답성을 향상시켜 애플리케이션 성능을 개선한다.  • 아파치(Apache)의 카산드라(Cassandra) 데이터베이스, 솔라(Solr) 검색엔진, 카프카(Kaf...

2021.12.16

코틀린 최신 로드맵 공개··· “컴파일러 및 모바일 기능 개선”

젯브레인에서 만든 JVM, 자바스크립트, 안드로이드 개발용 프로그래밍 언어 ‘코틀린(Kotlin)’의 최신 로드맵이 공개됐다. 해당 로드맵에 따르면 컴파일러 및 모바일 기능이 개선될 예정이다.  코틀린 1.7.0과 그 이후 버전에 대한 로드맵이 젯브레인 공식 블로그에서 지난 11월 10일(현지 시각) 발표됐다. 현재 사용할 수 있는 최신 버전은 코틀린 1.5.31이다(11월 17일 기준).    젯브레인은 컴파일러와 관련해 ‘K2 컴파일러 프론트엔드’ 작업을 알파 상태로 만드는 데 주력하고 있다고 밝혔다. K2는 코드 분석 그리고 IR(Intermediate Representation)로의 변환을 담당하는 프론트엔드와 함께, 컴파일 속도가 평균 2배 더 빠른 언어 컴파일러라고 코틀린 개발팀은 설명했다.  또한 K2 알파 릴리즈에서는 새로운 플러그인 인프라를 프리뷰로 제공할 계획이다. 아울러 K2 컴파일러로 멀티플랫폼 프로젝트를 구축할 수 있는 비-JVM 백엔드 지원에도 투자하고 있다고 개발팀은 덧붙였다.  이 밖에 최신 로드맵에 업데이트된 내용은 다음과 같다.  • iOS와 안드로이드를 포함한 플랫폼 간 코드 공유 기술 ‘KMM(Kotlin Multiplatform Mobile)’이 2022년 봄에 베타 릴리즈 단계로 진입한다. 해당 버전에서는 코드 강조 표시, 탐색 및 완성, 디버깅, 빌드 도구 안정성 문제가 수정되는 한편 동시성도 개선될 예정이다.  • 새로운 네임스페이스 개념의 프로토타입이 제공될 계획이다. 이를 통해 모든 클래스가 자동으로 소유하는 인스턴스 없이 임시 객체를 제공할 수 있다. 네임스페이스 멤버는 JVM의 정적 멤버로 컴파일된다. 이 계획은 자바(Java) 정적 메소드와의 상호 운용성을 개선하고, 모든 자바 유형에서 확장을 가능하게 하기 위해 고안됐다.  • 코드 커버리지를 측정하는 그래들(Gradle) 플러그인 ‘코버(Kover)’가 도입된다. ...

코틀린 프로그래밍 언어 개발 언어 젯브레인 모바일 개발 소프트웨어 개발 자바 JVM 자바스크립트 안드로이드 iOS 컴파일러

2021.11.17

젯브레인에서 만든 JVM, 자바스크립트, 안드로이드 개발용 프로그래밍 언어 ‘코틀린(Kotlin)’의 최신 로드맵이 공개됐다. 해당 로드맵에 따르면 컴파일러 및 모바일 기능이 개선될 예정이다.  코틀린 1.7.0과 그 이후 버전에 대한 로드맵이 젯브레인 공식 블로그에서 지난 11월 10일(현지 시각) 발표됐다. 현재 사용할 수 있는 최신 버전은 코틀린 1.5.31이다(11월 17일 기준).    젯브레인은 컴파일러와 관련해 ‘K2 컴파일러 프론트엔드’ 작업을 알파 상태로 만드는 데 주력하고 있다고 밝혔다. K2는 코드 분석 그리고 IR(Intermediate Representation)로의 변환을 담당하는 프론트엔드와 함께, 컴파일 속도가 평균 2배 더 빠른 언어 컴파일러라고 코틀린 개발팀은 설명했다.  또한 K2 알파 릴리즈에서는 새로운 플러그인 인프라를 프리뷰로 제공할 계획이다. 아울러 K2 컴파일러로 멀티플랫폼 프로젝트를 구축할 수 있는 비-JVM 백엔드 지원에도 투자하고 있다고 개발팀은 덧붙였다.  이 밖에 최신 로드맵에 업데이트된 내용은 다음과 같다.  • iOS와 안드로이드를 포함한 플랫폼 간 코드 공유 기술 ‘KMM(Kotlin Multiplatform Mobile)’이 2022년 봄에 베타 릴리즈 단계로 진입한다. 해당 버전에서는 코드 강조 표시, 탐색 및 완성, 디버깅, 빌드 도구 안정성 문제가 수정되는 한편 동시성도 개선될 예정이다.  • 새로운 네임스페이스 개념의 프로토타입이 제공될 계획이다. 이를 통해 모든 클래스가 자동으로 소유하는 인스턴스 없이 임시 객체를 제공할 수 있다. 네임스페이스 멤버는 JVM의 정적 멤버로 컴파일된다. 이 계획은 자바(Java) 정적 메소드와의 상호 운용성을 개선하고, 모든 자바 유형에서 확장을 가능하게 하기 위해 고안됐다.  • 코드 커버리지를 측정하는 그래들(Gradle) 플러그인 ‘코버(Kover)’가 도입된다. ...

2021.11.17

MS 파이썬용 컴파일러 ‘파이지온’, 버전 1.0 출시

닷넷 6(.NET 6) 런타임으로 컴파일되는 파이썬용 JIT(Just-In-Time) 컴파일 시스템 ‘파이지온(Pyjion)’의 버전 1.0이 공개됐다.  파이썬 소프트웨어 재단 펠로우이자 마이크로소프트 펠로우인 앤서니 쇼가 개발한 ‘파이지온’은 ‘파이파이(PyPy)’와 같은 독립실행형 런타임이 아니라 파이썬 3.10에서 실행되는 설치형 라이브러리다.    설치 후 파이지온 라이브러리를 가져와 활성화하면 프로그램에서 파이지온을 사용할 수 있다. 파이지온을 활성화한 후 가져오거나 정의하는 모든 파이썬 코드는 JIT 컴파일된다. 파이지온은 닷넷 EE(.NET EE) 컴파일러를 통해 파이썬 가상머신 명령 코드를 어셈블리 언어로 컴파일한다.  개발팀이 실시한 벤치마크 결과에 따르면 파이지온은 실제 작업에서 일반 파이썬보다 약 2~3배 더 빠른 것으로 드러났다. 일부 최적화는 최대 10배의 속도 향상을 보였다고 개발팀은 전했다. JIT 최적화에 적합한 일반 연산은 훨씬 더 빠를 수 있다.  With 블록 및 async/await 등의 일부 파이썬 기능은 아직 파이지온에서 구현되지 않았지만 둘 다 로드맵에 포함돼 있다고 개발팀은 언급했다. 파이지온에는 WSGI 애플리케이션이 파이지온에서 실행될 수 있도록 하는 미들웨어 계층도 지원된다.  여러 이유로 파이썬을 더 빠르게 만드는 것은 어려운 일이었다. 파이썬의 속도를 높이는 대부분의 방법이 호환성을 위해 파이썬 C API를 활용하고, 이는 성능을 제한시킬 수 있어서다. 그런 점에서 파이썬을 C로 컴파일하는 프로젝트인 ‘C파이썬’은 파이썬 C API를 전혀 활용하지 않는 코드로 최적의 성능을 달성한다.  파이지온은 파이썬 C API를 활용하긴 하지만 현재 및 향후 계획된 최적화(예: 배열 유형에 관한 액세스 최적화 등)는 파이지온 개발팀이 이를 해결할 방법을 고려하고 있음을 시사한다. ciokr@idg.co.kr  

마이크로소프트 파이썬 파이지온 닷넷 6 JIT 컴파일 컴파일러

2021.11.10

닷넷 6(.NET 6) 런타임으로 컴파일되는 파이썬용 JIT(Just-In-Time) 컴파일 시스템 ‘파이지온(Pyjion)’의 버전 1.0이 공개됐다.  파이썬 소프트웨어 재단 펠로우이자 마이크로소프트 펠로우인 앤서니 쇼가 개발한 ‘파이지온’은 ‘파이파이(PyPy)’와 같은 독립실행형 런타임이 아니라 파이썬 3.10에서 실행되는 설치형 라이브러리다.    설치 후 파이지온 라이브러리를 가져와 활성화하면 프로그램에서 파이지온을 사용할 수 있다. 파이지온을 활성화한 후 가져오거나 정의하는 모든 파이썬 코드는 JIT 컴파일된다. 파이지온은 닷넷 EE(.NET EE) 컴파일러를 통해 파이썬 가상머신 명령 코드를 어셈블리 언어로 컴파일한다.  개발팀이 실시한 벤치마크 결과에 따르면 파이지온은 실제 작업에서 일반 파이썬보다 약 2~3배 더 빠른 것으로 드러났다. 일부 최적화는 최대 10배의 속도 향상을 보였다고 개발팀은 전했다. JIT 최적화에 적합한 일반 연산은 훨씬 더 빠를 수 있다.  With 블록 및 async/await 등의 일부 파이썬 기능은 아직 파이지온에서 구현되지 않았지만 둘 다 로드맵에 포함돼 있다고 개발팀은 언급했다. 파이지온에는 WSGI 애플리케이션이 파이지온에서 실행될 수 있도록 하는 미들웨어 계층도 지원된다.  여러 이유로 파이썬을 더 빠르게 만드는 것은 어려운 일이었다. 파이썬의 속도를 높이는 대부분의 방법이 호환성을 위해 파이썬 C API를 활용하고, 이는 성능을 제한시킬 수 있어서다. 그런 점에서 파이썬을 C로 컴파일하는 프로젝트인 ‘C파이썬’은 파이썬 C API를 전혀 활용하지 않는 코드로 최적의 성능을 달성한다.  파이지온은 파이썬 C API를 활용하긴 하지만 현재 및 향후 계획된 최적화(예: 배열 유형에 관한 액세스 최적화 등)는 파이지온 개발팀이 이를 해결할 방법을 고려하고 있음을 시사한다. ciokr@idg.co.kr  

2021.11.10

웹어셈블리를 활용한 유망한 프로그래밍 언어 프로젝트 10가지

현재의 웹 애플리케이션은 속도와 응답성 측면에서 네이티브 데스크톱 애플리케이션에 비할 바는 아니다. 하지만 대등해진다면 어떨까? 그게 웹어셈블리(WebAssembly)의 약속이다.   웹어셈블리는 어셈블리와 비슷한 저수준 언어로, 웹 브라우저에서 네이티브에 근접한 성능으로 실행되는 간소한 바이너리 형식을 갖고 있다. 또한 웹어셈블리는 C/C++, 러스트, 고, 코틀린, 스위프트 및 기타 프로그래밍 언어에 대한 이식 가능한 컴파일 타겟도 제공한다.   웹어셈블리는 웹 애플리케이션 성능을 높이고 브라우저 앱 개발에서 자바스크립트 이외의 언어를 사용할 수 있게 해준다는 두 가지 측면에서 기대를 모으고 있으며 구글, 모질라, 애플, 마이크로소프트의 지지를 받고 있다. 4개 조직 모두 각자의 브라우저 엔진에서 웹어셈블리 기술을 지원한다.   웹어셈블리는 그 성능을 활용하는 완전히 새로운 프로그래밍 언어를 포함한 여러 신기술 개발로 이어졌다. 다음은 웹어셈블리에 '올라탄' 10개 언어 프로젝트다.   바이너리엔(Binaryen) 바이너리엔은 웹어셈블리를 위한 컴파일러 툴체인 인프라 라이브러리다. C++로 작성됐고 웹어셈블리 컴파일을 쉽고 효과적으로, 빠르게 하도록 고안됐다. 단일 헤더에 C API가 있으며 자바스크립트에서 사용할 수 있다. 입력은 웹어셈블리와 비슷한 형식으로 받지만 제어 그래프를 선호하는 컴파일러에 대해서는 일반 제어 그래프도 받는다.   바이너리엔의 내부 IR(Intermediate Representation)은 컴팩트한 데이터 구조를 사용하며 병렬 코드 생성과 최적화를 위해 모든 CPU 코어를 활용한다. IR도 기본적으로 웹어셈블리의 하위 집합이므로 손쉽게 웹어셈블리로 컴파일된다. 웹어셈블리를 위한 최적화는 코드 크기와 속도를 모두 개선하므로 바이너리엔은 그 자체로 컴파일러 백엔드로 유용하다.   깃허브에서 다운로드할 수 있다.   블레이저 웹어셈블리(Blazor WebAssembly) 블...

웹어셈블리 컴파일러 어셈블리 자바스크립트 프로그래밍언어

2021.06.07

현재의 웹 애플리케이션은 속도와 응답성 측면에서 네이티브 데스크톱 애플리케이션에 비할 바는 아니다. 하지만 대등해진다면 어떨까? 그게 웹어셈블리(WebAssembly)의 약속이다.   웹어셈블리는 어셈블리와 비슷한 저수준 언어로, 웹 브라우저에서 네이티브에 근접한 성능으로 실행되는 간소한 바이너리 형식을 갖고 있다. 또한 웹어셈블리는 C/C++, 러스트, 고, 코틀린, 스위프트 및 기타 프로그래밍 언어에 대한 이식 가능한 컴파일 타겟도 제공한다.   웹어셈블리는 웹 애플리케이션 성능을 높이고 브라우저 앱 개발에서 자바스크립트 이외의 언어를 사용할 수 있게 해준다는 두 가지 측면에서 기대를 모으고 있으며 구글, 모질라, 애플, 마이크로소프트의 지지를 받고 있다. 4개 조직 모두 각자의 브라우저 엔진에서 웹어셈블리 기술을 지원한다.   웹어셈블리는 그 성능을 활용하는 완전히 새로운 프로그래밍 언어를 포함한 여러 신기술 개발로 이어졌다. 다음은 웹어셈블리에 '올라탄' 10개 언어 프로젝트다.   바이너리엔(Binaryen) 바이너리엔은 웹어셈블리를 위한 컴파일러 툴체인 인프라 라이브러리다. C++로 작성됐고 웹어셈블리 컴파일을 쉽고 효과적으로, 빠르게 하도록 고안됐다. 단일 헤더에 C API가 있으며 자바스크립트에서 사용할 수 있다. 입력은 웹어셈블리와 비슷한 형식으로 받지만 제어 그래프를 선호하는 컴파일러에 대해서는 일반 제어 그래프도 받는다.   바이너리엔의 내부 IR(Intermediate Representation)은 컴팩트한 데이터 구조를 사용하며 병렬 코드 생성과 최적화를 위해 모든 CPU 코어를 활용한다. IR도 기본적으로 웹어셈블리의 하위 집합이므로 손쉽게 웹어셈블리로 컴파일된다. 웹어셈블리를 위한 최적화는 코드 크기와 속도를 모두 개선하므로 바이너리엔은 그 자체로 컴파일러 백엔드로 유용하다.   깃허브에서 다운로드할 수 있다.   블레이저 웹어셈블리(Blazor WebAssembly) 블...

2021.06.07

구글, V8 스파크플러그로 크롬 91 자바스크립트 성능 개선한다

구글이 스파크플러그 컴파일러를 이용해 크롬 브라우저의 자바스크립트 성능을 개선할 예정이다. 스파크 플러그는 바이트 코드를 기계 코드로 컴파일하는 '초고속' 비최적화 컴파일러이며 크롬 91에서 첫 선을 보이게 된다.  크롬 V8 자바스크립트/웹어셈블리 엔진의 일부분으로 소개된 스파크플러그는 ‘초고속’ 비최적화 컴파일러로 포지셔닝돼 있다. 5월 27일자 V8 블로그 글에 따르면, 스파크플러그는 컴파일러 파이프라인의 한 부분이며, 이그니션 인터프리터와 터보팬 최적화 컴파일러 사이에 자리잡고 있다.   스파크 플러그는 자바스크립트 소스가 아니라 바이트 코드를 토대로 컴파일한다. 달리 말해, 이미 바이트코드로 컴파일된 함수들을 컴파일한다. 스파크플러그에는 괄호가 실제로 화살표 함수인지 판정하고, 구조가 분해된 구문을 디슈거링(desugaring)하는 등의 다양한 해석 기능이 이미 탑재돼 있다.  대부분의 컴파일러와 달리, 스파크플러그는 중간 표현(intermediate representation)을 생성하지 않는다. 대신, 단일 선형 패스를 통해 바이트 코드를 기계 코드로 즉각 컴파일해 바이트코드를 실행하는 코드를 출력한다. 구글의 V8 개발자들은 2016년 이후 옥탄 등의 합성 벤치마크를 추적하는 데서 벗어나 자바스크립트의 실제 성능을 측정하는 쪽으로 방향을 바꿨다고 언급했다. 이에 따라, 개발자들은 파서, 스트리밍, 객체 모델, 컴파일된 코드의 캐싱 등 V8의 여러 측면들을 연구하고 있다. ciokr@idg.co.kr  

바이트코드 기계코드 스파크플러그 컴파일러 v8 크롬 91

2021.06.02

구글이 스파크플러그 컴파일러를 이용해 크롬 브라우저의 자바스크립트 성능을 개선할 예정이다. 스파크 플러그는 바이트 코드를 기계 코드로 컴파일하는 '초고속' 비최적화 컴파일러이며 크롬 91에서 첫 선을 보이게 된다.  크롬 V8 자바스크립트/웹어셈블리 엔진의 일부분으로 소개된 스파크플러그는 ‘초고속’ 비최적화 컴파일러로 포지셔닝돼 있다. 5월 27일자 V8 블로그 글에 따르면, 스파크플러그는 컴파일러 파이프라인의 한 부분이며, 이그니션 인터프리터와 터보팬 최적화 컴파일러 사이에 자리잡고 있다.   스파크 플러그는 자바스크립트 소스가 아니라 바이트 코드를 토대로 컴파일한다. 달리 말해, 이미 바이트코드로 컴파일된 함수들을 컴파일한다. 스파크플러그에는 괄호가 실제로 화살표 함수인지 판정하고, 구조가 분해된 구문을 디슈거링(desugaring)하는 등의 다양한 해석 기능이 이미 탑재돼 있다.  대부분의 컴파일러와 달리, 스파크플러그는 중간 표현(intermediate representation)을 생성하지 않는다. 대신, 단일 선형 패스를 통해 바이트 코드를 기계 코드로 즉각 컴파일해 바이트코드를 실행하는 코드를 출력한다. 구글의 V8 개발자들은 2016년 이후 옥탄 등의 합성 벤치마크를 추적하는 데서 벗어나 자바스크립트의 실제 성능을 측정하는 쪽으로 방향을 바꿨다고 언급했다. 이에 따라, 개발자들은 파서, 스트리밍, 객체 모델, 컴파일된 코드의 캐싱 등 V8의 여러 측면들을 연구하고 있다. ciokr@idg.co.kr  

2021.06.02

서버측 웹어셈블리 런타임 ‘와스머’, GA 버전 공개

빠른 컴파일과 프로덕션-준비 성능을 제공하는 ‘와스머(Wasmer)’ 버전 1.0을 사용하면 네이티브 코드에서 컴파일된 범용 바이너리를 여러 호스트 플랫폼의 경량 컨테이너에서 실행할 수 있다.  웹어셈블리 포터블 바이너리 포맷을 지원하는 서버측 오픈소스 런타임 ‘와스머’가 지난 1월 5일(현지 시각) GA 버전을 공개했다.    와스머는 소프트웨어 컨테이너화에 웹어셈블리를 활용하여 C++, 러스트, 고랭, 파이썬 및 다른 개발 언어로 컴파일된 범용 바이너리를 수정 없이 다른 운영체제와 웹 브라우저에서 실행할 수 있다.  와스머 개발팀의 사이러스 아크바리는 공식 블로그를 통해 “런타임과 컴파일러 성능이 굉장히 뛰어나다”라고 언급하면서, “웹어셈블리 또는 짧게 말해서 Wasm이 소프트웨어 실행 및 컨테이너화의 미래를 위한 중요한 구성요소가 될 것이다”라고 말했다.  와스머는 데스크톱부터 클라우드, IoT, 모바일 기기까지 다양한 플랫폼(리눅스, 맥 OS, 윈도우, 안드로이드, iOS)에서 웹어셈블리 기반 경량 컨테이너를 실행할 수 있으며, 이러한 컨테이너를 모든 프로그래밍 언어에 임베디드할 수 있다. 또한 와스머 런타임은 엔진엑스(Nginx) 웹 서버와 다른 웹어셈블리 모듈을 실행할 수 있다.  와스머 버전 1.0의 다른 기능은 다음과 같다.  • Wasm 파일을 미리 컴파일하기 위한 네이티브 개체 엔진 • IoT 사용 사례에 적합한 헤드리스 와스머(Headless Wasmer)  • 크로스 컴파일  • 확장 가능한 API • Wasm-C-API 지원 • 오류 처리 및 디버깅  • 프로덕션 준비 성능  • JIT ‘폭탄(bombs)’에 영향을 받지 않는 고속 컴파일 시간에 적합한 ‘단일패스(Singlepass)’ 컴파일러를 비롯해 크레인리프트(Cranelift)와 LLVM 등의 플러그형 인프라가 지원된다.  • ARM 기반 애플 실리콘 하드웨어 ...

웹어셈블리 컨테이너화 와스머 컴파일러

2021.01.08

빠른 컴파일과 프로덕션-준비 성능을 제공하는 ‘와스머(Wasmer)’ 버전 1.0을 사용하면 네이티브 코드에서 컴파일된 범용 바이너리를 여러 호스트 플랫폼의 경량 컨테이너에서 실행할 수 있다.  웹어셈블리 포터블 바이너리 포맷을 지원하는 서버측 오픈소스 런타임 ‘와스머’가 지난 1월 5일(현지 시각) GA 버전을 공개했다.    와스머는 소프트웨어 컨테이너화에 웹어셈블리를 활용하여 C++, 러스트, 고랭, 파이썬 및 다른 개발 언어로 컴파일된 범용 바이너리를 수정 없이 다른 운영체제와 웹 브라우저에서 실행할 수 있다.  와스머 개발팀의 사이러스 아크바리는 공식 블로그를 통해 “런타임과 컴파일러 성능이 굉장히 뛰어나다”라고 언급하면서, “웹어셈블리 또는 짧게 말해서 Wasm이 소프트웨어 실행 및 컨테이너화의 미래를 위한 중요한 구성요소가 될 것이다”라고 말했다.  와스머는 데스크톱부터 클라우드, IoT, 모바일 기기까지 다양한 플랫폼(리눅스, 맥 OS, 윈도우, 안드로이드, iOS)에서 웹어셈블리 기반 경량 컨테이너를 실행할 수 있으며, 이러한 컨테이너를 모든 프로그래밍 언어에 임베디드할 수 있다. 또한 와스머 런타임은 엔진엑스(Nginx) 웹 서버와 다른 웹어셈블리 모듈을 실행할 수 있다.  와스머 버전 1.0의 다른 기능은 다음과 같다.  • Wasm 파일을 미리 컴파일하기 위한 네이티브 개체 엔진 • IoT 사용 사례에 적합한 헤드리스 와스머(Headless Wasmer)  • 크로스 컴파일  • 확장 가능한 API • Wasm-C-API 지원 • 오류 처리 및 디버깅  • 프로덕션 준비 성능  • JIT ‘폭탄(bombs)’에 영향을 받지 않는 고속 컴파일 시간에 적합한 ‘단일패스(Singlepass)’ 컴파일러를 비롯해 크레인리프트(Cranelift)와 LLVM 등의 플러그형 인프라가 지원된다.  • ARM 기반 애플 실리콘 하드웨어 ...

2021.01.08

‘페이블 3 나가레야마’ 출시··· 사용 편의성 및 속도 향상

더 간단한 사용 방식, 더 읽기 쉬운 코드, 더 향상된 컴파일 속도를 지원하는 ‘페이블 3(Fable 3)’가 출시됐다. 이는 마이크로소프트의 함수형 개발 언어 F#으로 자바스크립트 애플리케이션을 작성할 수 있게 해주는 컴파일러 페이블(Fable)의 최신 릴리즈다.    회사에 따르면 일명 ‘나가레야마(Nagareyama)’로 불리는 페이블 3는 자바스크립트와의 프로세스 간 통신(IPC)을 제거하여 페이블을 사용하거나 이를 통해 개발하는 방식을 크게 단순화했다. 컴파일 속도도 향상됐다. 대부분의 경우, 컴파일링 프로세스가 절반으로 줄어들 것이라는 게 페이블 개발자의 설명이다.  지난 4일(현지 시각) 공개된 ‘페이블 3 나가레야마’의 개선 사항들은 다음과 같다.  • 페이블 컴파일러가 웹팩(Webpack) 등 특정 번들러와 더 이상 긴밀하게 결합되지 않는다. 개발자는 원하는 번들링 도구를 사용할 수 있다.   • 라이브러리 작성자의 플러그인을 허용할 수 있다.  • 페이블은 이제 대부분의 F# 프로젝트에 맞는 닷넷(.NET) 도구가 됐다.  • 주요 변경사항은 없다. 페이블 2 프로젝트는 그대로 컴파일해야 한다.  • 생성된 코드는 더 읽기 쉽고, 더 디버그하기 쉬워졌다.   한편 페이블 개발자는 이 최신 버전이 아마도 버그 없음(bug-free)을 의미하는 건 아니라고 언급했다. 단 정식판 이전의 RC(Release Candidate) 버전을 많은 프로젝트에서 테스트했고 눈에 띄는 모든 오류는 수정했다고 전했다. 자세한 내용은 이곳에서 확인할 수 있다. ciokr@idg.co.kr  

페이블 컴파일러 마이크로소프트 F# 자바스크립트 웹팩 번들러 닷넷

2020.12.08

더 간단한 사용 방식, 더 읽기 쉬운 코드, 더 향상된 컴파일 속도를 지원하는 ‘페이블 3(Fable 3)’가 출시됐다. 이는 마이크로소프트의 함수형 개발 언어 F#으로 자바스크립트 애플리케이션을 작성할 수 있게 해주는 컴파일러 페이블(Fable)의 최신 릴리즈다.    회사에 따르면 일명 ‘나가레야마(Nagareyama)’로 불리는 페이블 3는 자바스크립트와의 프로세스 간 통신(IPC)을 제거하여 페이블을 사용하거나 이를 통해 개발하는 방식을 크게 단순화했다. 컴파일 속도도 향상됐다. 대부분의 경우, 컴파일링 프로세스가 절반으로 줄어들 것이라는 게 페이블 개발자의 설명이다.  지난 4일(현지 시각) 공개된 ‘페이블 3 나가레야마’의 개선 사항들은 다음과 같다.  • 페이블 컴파일러가 웹팩(Webpack) 등 특정 번들러와 더 이상 긴밀하게 결합되지 않는다. 개발자는 원하는 번들링 도구를 사용할 수 있다.   • 라이브러리 작성자의 플러그인을 허용할 수 있다.  • 페이블은 이제 대부분의 F# 프로젝트에 맞는 닷넷(.NET) 도구가 됐다.  • 주요 변경사항은 없다. 페이블 2 프로젝트는 그대로 컴파일해야 한다.  • 생성된 코드는 더 읽기 쉽고, 더 디버그하기 쉬워졌다.   한편 페이블 개발자는 이 최신 버전이 아마도 버그 없음(bug-free)을 의미하는 건 아니라고 언급했다. 단 정식판 이전의 RC(Release Candidate) 버전을 많은 프로젝트에서 테스트했고 눈에 띄는 모든 오류는 수정했다고 전했다. 자세한 내용은 이곳에서 확인할 수 있다. ciokr@idg.co.kr  

2020.12.08

'애플 스위프트'가 '윈도우'로 온다··· 윈도우10용 툴체인 공개

애플의 프로그래밍 언어, 스위프트(Swift)의 윈도우 지원이 준비됐다. 물론 이식(porting) 작업이 아직 완전히 완료된 것은 아니다.    1년간의 이식 작업 끝에 드디어 애플의 프로그래밍 언어 스위프트를 윈도우에서 사용할 수 있게 됐다. 스위프트 코어(Swift Core) 팀의 살렘 압둘라술은 “스위프트로 윈도우 경험을 구축해볼 수 있는 단계에 도달했다”라고 밝혔다.  22일(현지 시각) 윈도우10용 스위프트 5.3 툴체인이 공개됐다. 현재 사이트에서 다운로드받을 수 있다. 스위프트 공식 사이트에 따르면 윈도우에서 스위프트의 전체 에코시스템을 사용할 수 있도록 이식 작업이 진행됐다. 여기에는 컴파일러, 표준 라이브러리를 비롯해 주요 라이브러리인 디스패치(dispatch), 파운데이션(Foundation), XC테스트(XCTest)가 포함된다.  개발자는 이러한 라이브러리를 통해 기본적인 시스템의 수많은 세부사항을 처리할 필요 없이 손쉽게 애플리케이션을 작성할 수 있다.  이번 지원은 시작에 불과하다. lldb 및 스위프트 패키지 매니저(Swift Package Manager)와 같은 에코시스템은 여전히 더 많은 이전 작업이 필요하다. 리들(Readdle) 등의 얼리어답터 업체들은 기존 스위프트 라이브러리를 윈도우로 가져오면서 스위프트로 작성된 크로스 플랫폼 애플리케이션을 실험하고 있다.  한편 2014년 6월, ‘오브젝티브-C(Objective-C)’의 후속으로 출시된 스위프트는 애플 맥OS, iOS, 워치OS, tvOS 및 리눅스를 대상으로 한다. ‘스위프트 5.3’은 9월 16일 공개됐다. 이는 상용구, 중복 코드, 런타임 메모리 사용량 등을 줄여 언어를 개선하는 데 초점을 맞췄다. ciokr@idg.co.kr  

애플 프로그래밍 언어 개발 언어 스위프트 오브젝티브-C 윈도우 윈도우10 툴체인 컴파일러 표준 라이브러리 디스패치 파운데이션 XC테스트 스위프트 패키지 매니저 리들

2020.09.25

애플의 프로그래밍 언어, 스위프트(Swift)의 윈도우 지원이 준비됐다. 물론 이식(porting) 작업이 아직 완전히 완료된 것은 아니다.    1년간의 이식 작업 끝에 드디어 애플의 프로그래밍 언어 스위프트를 윈도우에서 사용할 수 있게 됐다. 스위프트 코어(Swift Core) 팀의 살렘 압둘라술은 “스위프트로 윈도우 경험을 구축해볼 수 있는 단계에 도달했다”라고 밝혔다.  22일(현지 시각) 윈도우10용 스위프트 5.3 툴체인이 공개됐다. 현재 사이트에서 다운로드받을 수 있다. 스위프트 공식 사이트에 따르면 윈도우에서 스위프트의 전체 에코시스템을 사용할 수 있도록 이식 작업이 진행됐다. 여기에는 컴파일러, 표준 라이브러리를 비롯해 주요 라이브러리인 디스패치(dispatch), 파운데이션(Foundation), XC테스트(XCTest)가 포함된다.  개발자는 이러한 라이브러리를 통해 기본적인 시스템의 수많은 세부사항을 처리할 필요 없이 손쉽게 애플리케이션을 작성할 수 있다.  이번 지원은 시작에 불과하다. lldb 및 스위프트 패키지 매니저(Swift Package Manager)와 같은 에코시스템은 여전히 더 많은 이전 작업이 필요하다. 리들(Readdle) 등의 얼리어답터 업체들은 기존 스위프트 라이브러리를 윈도우로 가져오면서 스위프트로 작성된 크로스 플랫폼 애플리케이션을 실험하고 있다.  한편 2014년 6월, ‘오브젝티브-C(Objective-C)’의 후속으로 출시된 스위프트는 애플 맥OS, iOS, 워치OS, tvOS 및 리눅스를 대상으로 한다. ‘스위프트 5.3’은 9월 16일 공개됐다. 이는 상용구, 중복 코드, 런타임 메모리 사용량 등을 줄여 언어를 개선하는 데 초점을 맞췄다. ciokr@idg.co.kr  

2020.09.25

Vue.js 3.0, "더 빠른 속도와 향상된 타입스크립트 지원 제공할 것"

웹 UI 구축용 자바스크립트 프레임워크 Vue.js의 버전 3.0이 2020년 3분기에 공식 출시될 예정이다. 올해 초 공개된 베타 버전은 성능 및 타입스크립트(TypeScrpt) 지원 등에서 상당한 개선을 보여줬다. Vue 3.0 베타 버전은 기트허브에서 다운로드 받을 수 있다.    Vue 3.0은 재작성된 ‘가상 돔(Virtual DOM)’과 컴파일러 기반의 빠른 경로를 제공해 성능을 향상시켰다. 이를테면 일반적인 시나리오를 시뮬레이션하는 벤치마크를 기준으로 서버사이드 렌더링이 2~3배 더 빨라졌다. 구성 요소 초기화가 더 효율적으로 이뤄지며 업데이트 성능 또한 향상됐다.  파일 크기를 줄여 성능 전반을 향상시키는 ‘트리-셰이킹(Tree-shaking)’도 강화됐다. 양방향 데이터 바인딩을 지원하는 ‘v-model 디렉티브(v-model directive)’와 같은 대부분의 사용자 정의 기능에서 이제 트리-셰이킹이 가능하다.  가장 중요한 변화는 컴포지션 API(Composition API)다. Vue 3.0에 탑재된 컴포지션 API는 로직을 유연하게 구성하고, 컴포넌트 전체에서 재사용할 수 있는 일련의 함수 기반 API다. 옵션 API(Options API)와 함께 사용할 수 있다.  또한 Vue.js 3.0 코드베이스는 타입스크립트로 작성된다. 즉 자동 생성 타입 정의, 그리고 타입스크립트 및 자바스크립트와 동일한 API를 사용한다는 뜻이다. 클래스 구성 요소도 계속 지원된다.  Vue.js 3.0 베타에서 공개된 다른 기능들은 다음과 같다.  • SFC(Single File Component)의 탐색적 타입 검사 • 네이티브스크립트(NativeScript) 프레임워크와 통합되는 사용자 정의 렌더러 API(Custom Renderer API) • 다수의 루트 구성 요소가 허용되지 않는 문제를 해결하는 조각 기능(네이티브스크립트의 개발사 프로그레스 텔레릭은 조각 기능을 시맨틱에 ...

웹 UI 자바스크립트 프레임워크 Vue.js 타입스크립트 vue 가상 돔 컴파일러 트리셰이킹 양방향 데이터 바인딩 컴포지션 API 네이티브스크립트 기트허브

2020.07.14

웹 UI 구축용 자바스크립트 프레임워크 Vue.js의 버전 3.0이 2020년 3분기에 공식 출시될 예정이다. 올해 초 공개된 베타 버전은 성능 및 타입스크립트(TypeScrpt) 지원 등에서 상당한 개선을 보여줬다. Vue 3.0 베타 버전은 기트허브에서 다운로드 받을 수 있다.    Vue 3.0은 재작성된 ‘가상 돔(Virtual DOM)’과 컴파일러 기반의 빠른 경로를 제공해 성능을 향상시켰다. 이를테면 일반적인 시나리오를 시뮬레이션하는 벤치마크를 기준으로 서버사이드 렌더링이 2~3배 더 빨라졌다. 구성 요소 초기화가 더 효율적으로 이뤄지며 업데이트 성능 또한 향상됐다.  파일 크기를 줄여 성능 전반을 향상시키는 ‘트리-셰이킹(Tree-shaking)’도 강화됐다. 양방향 데이터 바인딩을 지원하는 ‘v-model 디렉티브(v-model directive)’와 같은 대부분의 사용자 정의 기능에서 이제 트리-셰이킹이 가능하다.  가장 중요한 변화는 컴포지션 API(Composition API)다. Vue 3.0에 탑재된 컴포지션 API는 로직을 유연하게 구성하고, 컴포넌트 전체에서 재사용할 수 있는 일련의 함수 기반 API다. 옵션 API(Options API)와 함께 사용할 수 있다.  또한 Vue.js 3.0 코드베이스는 타입스크립트로 작성된다. 즉 자동 생성 타입 정의, 그리고 타입스크립트 및 자바스크립트와 동일한 API를 사용한다는 뜻이다. 클래스 구성 요소도 계속 지원된다.  Vue.js 3.0 베타에서 공개된 다른 기능들은 다음과 같다.  • SFC(Single File Component)의 탐색적 타입 검사 • 네이티브스크립트(NativeScript) 프레임워크와 통합되는 사용자 정의 렌더러 API(Custom Renderer API) • 다수의 루트 구성 요소가 허용되지 않는 문제를 해결하는 조각 기능(네이티브스크립트의 개발사 프로그레스 텔레릭은 조각 기능을 시맨틱에 ...

2020.07.14

컴파일러 프레임워크 'LLVM 8' 발표··· 웹어셈블리 코드 생성 기능 기본 적용

LLVM 프로젝트가 LLVM 8을 정식 공개했다. LLVM은 클랭(Clang) C/C++ 컴파일러를 강화하는 컴파일러 프레임워크이자 러스트(Rust)와 스위프트(Swift) 같은 언어를 위한 컴파일러다.   이번 최신 버전의 가장 큰 특징은 웹어셈블리(WebAssembly) 코드 생성 기능이 테스트 상태에서 벗어나 기본으로 적용된 것이다. 이 컴파일러는 이미 LLVM의 웹어셈블리 코드 생성 툴을 임시로 사용해 왔다. 예를 들어 (일부 추가 작업이 필요하긴 하지만) 러스트를 웹어셈블리로 컴파일할 수 있었다. 그러나 이번에 웹어셈블리용 LLVM을 실제 기업 시스템에서 사용할 수 있음을 공식화했다. 물론 웹어셈블리 자체는 아직 초기 단계의 기술이다. 그러나 이번 발표는 자바스크립트 외에 다른 언어로 만든 코드를 자유롭게 컴파일해 브라우저에서 실행하는 단계로 나아가는 중요한 이정표가 될 전망이다.   이밖에 LLVM 8에서는 인텔 캐스케이드 레이크 칩셋으로 컴파일할 수 있고, 명령줄 플래그 방식을 추가로 지원한다. 이는 근본적으로 기존의 인텔 스카이레이크 칩셋에 대한 지원과 같다. 그러나 인텔 제온 파이와 제온 스케일어블 프로세서에서 사용할 수 있는 새로운 AVX-512 명령 세트의 일부인 VNNI(Vector Neural Network Instructions) 출력을 지원하는 것에 차이가 있다. VNNI는 그 이름에서 알 수 있는 것처럼 GPU 가속이 불가능한 인텔 시스템 환경에서 딥러닝 워크로드 처리 속도를 높이기 위한 명령어다.   LLVM 코드 생성은 CPU에 제한되지 않는다. LLVM 8은 AMDGPU 백엔드용 코드 생성 기능도 강화했다. 이를 이용하면 LLVM 코드를 오픈소스 라데온(Radeon) 그래픽 스택용으로 생성할 수 있다. 베가(Vega) 시리즈 같은 새 AMD GPU는 AMDGPU 지원이 가장 큰 혜택이 될 것으로 보인다. IBM 파워 프로세서, 특히 파워9에 맞춘 코드 생성도 개선됐다. LLVM의 MIPS/MIP64 ...

컴파일러 웹어셈블리 LLVM

2019.03.21

LLVM 프로젝트가 LLVM 8을 정식 공개했다. LLVM은 클랭(Clang) C/C++ 컴파일러를 강화하는 컴파일러 프레임워크이자 러스트(Rust)와 스위프트(Swift) 같은 언어를 위한 컴파일러다.   이번 최신 버전의 가장 큰 특징은 웹어셈블리(WebAssembly) 코드 생성 기능이 테스트 상태에서 벗어나 기본으로 적용된 것이다. 이 컴파일러는 이미 LLVM의 웹어셈블리 코드 생성 툴을 임시로 사용해 왔다. 예를 들어 (일부 추가 작업이 필요하긴 하지만) 러스트를 웹어셈블리로 컴파일할 수 있었다. 그러나 이번에 웹어셈블리용 LLVM을 실제 기업 시스템에서 사용할 수 있음을 공식화했다. 물론 웹어셈블리 자체는 아직 초기 단계의 기술이다. 그러나 이번 발표는 자바스크립트 외에 다른 언어로 만든 코드를 자유롭게 컴파일해 브라우저에서 실행하는 단계로 나아가는 중요한 이정표가 될 전망이다.   이밖에 LLVM 8에서는 인텔 캐스케이드 레이크 칩셋으로 컴파일할 수 있고, 명령줄 플래그 방식을 추가로 지원한다. 이는 근본적으로 기존의 인텔 스카이레이크 칩셋에 대한 지원과 같다. 그러나 인텔 제온 파이와 제온 스케일어블 프로세서에서 사용할 수 있는 새로운 AVX-512 명령 세트의 일부인 VNNI(Vector Neural Network Instructions) 출력을 지원하는 것에 차이가 있다. VNNI는 그 이름에서 알 수 있는 것처럼 GPU 가속이 불가능한 인텔 시스템 환경에서 딥러닝 워크로드 처리 속도를 높이기 위한 명령어다.   LLVM 코드 생성은 CPU에 제한되지 않는다. LLVM 8은 AMDGPU 백엔드용 코드 생성 기능도 강화했다. 이를 이용하면 LLVM 코드를 오픈소스 라데온(Radeon) 그래픽 스택용으로 생성할 수 있다. 베가(Vega) 시리즈 같은 새 AMD GPU는 AMDGPU 지원이 가장 큰 혜택이 될 것으로 보인다. IBM 파워 프로세서, 특히 파워9에 맞춘 코드 생성도 개선됐다. LLVM의 MIPS/MIP64 ...

2019.03.21

칼럼 | 혼란 속 거대한 흐름 있다··· 애널리틱스 동향 5가지

정보화 시대에서는 일찍 일어난 새가 아니라 데이터를 가진 새가 벌레를 잡는다. 구글, 페이스북, 애플 등 거대 기업들이 데이터를 병적으로 수집하는 이유도 이 시대에서 '정보가 곧 금'이라는 것을 알고 있기 때문이다. 그러나 데이터는 단순히 수집해 보유하는 것만으로는 가치가 없다. 더 중요한 것은 이런 데이터를 정제해 통합하고, 거기에서 유의미한 정보를 도출해 내는 과정이 필요하다. 그리고 그 과정이 끝난 후에야 의사 결정과 상품 제작에 데이터를 '활용'할 수 있게 된다. 그렇지만 오늘날 과포화 상태인 애널리틱스 시장 상황에서도 제대로 된 애널리틱스 전략을 세우는 것이 불가능하지만은 않다. 광활하고 복잡한 애널리틱스 분야에 대한 이해를 돕기 위해, 이 분야에 대해 개인적으로 생각하는 향후 5년 이내의 전망을 소개하려 한다. 어쩌면 이 예측 내용으로 좀 더 데이터 주도적인 기업으로 거듭나는 것이 가능해 질 지도 모른다. 1. 앱으로 이전하는 BI 지난 20여 년 동안 우리는 혁명을 목격해 왔다. 하루아침에 일어나는 혁명이 아니라, 오랜 시간을 두고 일어나는 혁명 말이다. 사실 너무 오랜 시간이 걸려서 혁명이 혁명인줄 모르는 사람들도 있다. BI는 죽어가고 있다. 아니, 좀 더 정확히 말하자면 다시 태어나고 있다. 창립 20주년이 넘은 기업 '태블로(Tableau)'는 마지막 'BI' 업체였다. 그리고 솔직히 말해 태블로는 주력 BI 솔루션도 아니다. 원래는 데이터 시각화 툴이었던 것이 충분한 BI 요소를 갖추게 됨에 따라 당시 업계를 호령하던 골리앗과 맞설 수 있게 된 것 뿐이다. 매년 사용자들은 허브스팟(HubSpot), 세일즈포스(SalesForce), 메일침프(MailChimp)와 같은 앱들을 통해 점점 더 많은 애널리틱스를 우겨넣고 있다. 애널리틱스는 비즈니스 애플리케이션의 구조 그 자체로의 이전이라고 할 수 있을 것이다. 핵심은 비즈니스 애플리케이션들이 자사의 데이...

BI 데이터 ETL 애널리틱스 머신러닝 컴파일러

2017.10.30

정보화 시대에서는 일찍 일어난 새가 아니라 데이터를 가진 새가 벌레를 잡는다. 구글, 페이스북, 애플 등 거대 기업들이 데이터를 병적으로 수집하는 이유도 이 시대에서 '정보가 곧 금'이라는 것을 알고 있기 때문이다. 그러나 데이터는 단순히 수집해 보유하는 것만으로는 가치가 없다. 더 중요한 것은 이런 데이터를 정제해 통합하고, 거기에서 유의미한 정보를 도출해 내는 과정이 필요하다. 그리고 그 과정이 끝난 후에야 의사 결정과 상품 제작에 데이터를 '활용'할 수 있게 된다. 그렇지만 오늘날 과포화 상태인 애널리틱스 시장 상황에서도 제대로 된 애널리틱스 전략을 세우는 것이 불가능하지만은 않다. 광활하고 복잡한 애널리틱스 분야에 대한 이해를 돕기 위해, 이 분야에 대해 개인적으로 생각하는 향후 5년 이내의 전망을 소개하려 한다. 어쩌면 이 예측 내용으로 좀 더 데이터 주도적인 기업으로 거듭나는 것이 가능해 질 지도 모른다. 1. 앱으로 이전하는 BI 지난 20여 년 동안 우리는 혁명을 목격해 왔다. 하루아침에 일어나는 혁명이 아니라, 오랜 시간을 두고 일어나는 혁명 말이다. 사실 너무 오랜 시간이 걸려서 혁명이 혁명인줄 모르는 사람들도 있다. BI는 죽어가고 있다. 아니, 좀 더 정확히 말하자면 다시 태어나고 있다. 창립 20주년이 넘은 기업 '태블로(Tableau)'는 마지막 'BI' 업체였다. 그리고 솔직히 말해 태블로는 주력 BI 솔루션도 아니다. 원래는 데이터 시각화 툴이었던 것이 충분한 BI 요소를 갖추게 됨에 따라 당시 업계를 호령하던 골리앗과 맞설 수 있게 된 것 뿐이다. 매년 사용자들은 허브스팟(HubSpot), 세일즈포스(SalesForce), 메일침프(MailChimp)와 같은 앱들을 통해 점점 더 많은 애널리틱스를 우겨넣고 있다. 애널리틱스는 비즈니스 애플리케이션의 구조 그 자체로의 이전이라고 할 수 있을 것이다. 핵심은 비즈니스 애플리케이션들이 자사의 데이...

2017.10.30

개발자의 마음을 차지하기 위한 전쟁 10가지

인간의 본능인지, 사회 형성의 불가피한 산물인지 몰라도 우리 삶의 많은 부분이 이원론을 통해 규정된다. 공산주의 대 자본주의. 세이보리 대 설탕. 패스 대 드리블. 어디를 보든 대립은 끝이 없다. 그래서 둘 중에 어느 편에 서는가로 우리 스스로를 정의할 수 있는 경우도 무수히 많다. 컴퓨터 업계에서는 이러한 현상이 더욱 두드러진다. 각종 기술들이 (사람들의 마음과 돈을 차지하기 위해 경쟁하면서) 경쟁 솔루션과 다른 고유한 장점을 통해 스스로를 정의한다. 한 편에 X가 있고, 그 반대편에는 X가 아닌 것이 있다. 그 뒤로 팬보이들이 줄을 서서 상대편을 조롱하고 깎아 내린다. 이러한 대립이 없다면, 치열한 논쟁과 선택권이 없다면 아마 오래 전에 코드 저장소는 하나로 통합되고 사람들은 사이 좋게 잘 지내게 되었을 듯하다. 다만 혁신도 그만큼 줄었을 것이다. 다음은 현재 개발자들 사이에서 볼 수 있는 가장 흥미로운 10가지 대립이다. 새로운 프로젝트를 수행할 때마다 우리는 이러한 기술이 갖는 차이점의 기저가 되는 근본적인 질문들에 직면한다. 간단함과 정확성 중 무엇을 선호하는가? 오픈소스냐, 기업 지원이냐? 대괄호냐, 공백이냐? 이러한 질문들은 마치 음과 양처럼 기업 개발자들 사이의 균형을 이룬다. 개발자 기술 대결 1: PHP 대 Node.js 컴퓨터 과학자들은 좋아하지 않는 PHP는 웹 사이트에 소소한 지능을 추가하고자 했던 사람들 사이에서 처음 도입됐다. 이들 덕분에 워드프레스(WordPress), 드루팔(Drupal), 줌라(Joomla)와 같은 빼어난 프레임워크들이 나왔다. 웹은 대부분 PHP를 기반으로 한다. 그런데 이 모델에 균열이 생겼다. 젊은 개발자들은 자바스크립트로 프로그래밍된 서버 측 메커니즘인 Node.js에 심취해 있다. 어느 순간부터 프로그래머들은 클라이언트 또는 서버에서 실행되는 코드를 작성할 수 있게 됐다. 두 개의 언어를 따로 배울 필요가 없어졌다. Node.js에도 나름의 단점은 있지만, 강력한 ...

데이터베이스 경쟁 언어 개발툴 선택 컴파일러

2014.10.15

인간의 본능인지, 사회 형성의 불가피한 산물인지 몰라도 우리 삶의 많은 부분이 이원론을 통해 규정된다. 공산주의 대 자본주의. 세이보리 대 설탕. 패스 대 드리블. 어디를 보든 대립은 끝이 없다. 그래서 둘 중에 어느 편에 서는가로 우리 스스로를 정의할 수 있는 경우도 무수히 많다. 컴퓨터 업계에서는 이러한 현상이 더욱 두드러진다. 각종 기술들이 (사람들의 마음과 돈을 차지하기 위해 경쟁하면서) 경쟁 솔루션과 다른 고유한 장점을 통해 스스로를 정의한다. 한 편에 X가 있고, 그 반대편에는 X가 아닌 것이 있다. 그 뒤로 팬보이들이 줄을 서서 상대편을 조롱하고 깎아 내린다. 이러한 대립이 없다면, 치열한 논쟁과 선택권이 없다면 아마 오래 전에 코드 저장소는 하나로 통합되고 사람들은 사이 좋게 잘 지내게 되었을 듯하다. 다만 혁신도 그만큼 줄었을 것이다. 다음은 현재 개발자들 사이에서 볼 수 있는 가장 흥미로운 10가지 대립이다. 새로운 프로젝트를 수행할 때마다 우리는 이러한 기술이 갖는 차이점의 기저가 되는 근본적인 질문들에 직면한다. 간단함과 정확성 중 무엇을 선호하는가? 오픈소스냐, 기업 지원이냐? 대괄호냐, 공백이냐? 이러한 질문들은 마치 음과 양처럼 기업 개발자들 사이의 균형을 이룬다. 개발자 기술 대결 1: PHP 대 Node.js 컴퓨터 과학자들은 좋아하지 않는 PHP는 웹 사이트에 소소한 지능을 추가하고자 했던 사람들 사이에서 처음 도입됐다. 이들 덕분에 워드프레스(WordPress), 드루팔(Drupal), 줌라(Joomla)와 같은 빼어난 프레임워크들이 나왔다. 웹은 대부분 PHP를 기반으로 한다. 그런데 이 모델에 균열이 생겼다. 젊은 개발자들은 자바스크립트로 프로그래밍된 서버 측 메커니즘인 Node.js에 심취해 있다. 어느 순간부터 프로그래머들은 클라이언트 또는 서버에서 실행되는 코드를 작성할 수 있게 됐다. 두 개의 언어를 따로 배울 필요가 없어졌다. Node.js에도 나름의 단점은 있지만, 강력한 ...

2014.10.15

자바스크립트 코딩을 즐겁게 해주는 9가지 프로그래밍 언어

자바스크립트는 IT 생태계에서 리눅스, 가상화 못지않게 광범위하게 확산되면서 필수적인 기술로 자리를 잡았다. 그러나 구문상의 함정, 이상한 설계 상의 특징, 그리고 여러 가지 제약으로 인해 숙련된 개발자들조차 넌더리를 내는 경우가 종종 있다. 다행히 자바스크립트 프로그래밍의 골치 아픈 문제를 해결하고자 다양한 자바스크립트 미니 언어가 생겨났다. 자바스크립트로 컴파일되는 이들 언어는 자바스크립트 자체에는 없는 기능을 제공하며, 자바스크립트보다 더 쉽게 코딩, 유지, 디버깅이 가능하다. 기존 언어를 자바스크립트로 컴파일해주는 트랜스파일러도 있지만, 여기서는 자바스크립트로 컴파일되도록 만들어진 언어만 살펴본다. editor@itworld.co.kr

자바스크립트 커피스크립트 카페인 컴파일러

2014.06.30

자바스크립트는 IT 생태계에서 리눅스, 가상화 못지않게 광범위하게 확산되면서 필수적인 기술로 자리를 잡았다. 그러나 구문상의 함정, 이상한 설계 상의 특징, 그리고 여러 가지 제약으로 인해 숙련된 개발자들조차 넌더리를 내는 경우가 종종 있다. 다행히 자바스크립트 프로그래밍의 골치 아픈 문제를 해결하고자 다양한 자바스크립트 미니 언어가 생겨났다. 자바스크립트로 컴파일되는 이들 언어는 자바스크립트 자체에는 없는 기능을 제공하며, 자바스크립트보다 더 쉽게 코딩, 유지, 디버깅이 가능하다. 기존 언어를 자바스크립트로 컴파일해주는 트랜스파일러도 있지만, 여기서는 자바스크립트로 컴파일되도록 만들어진 언어만 살펴본다. editor@itworld.co.kr

2014.06.30

IDG 설문조사

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.

10.4.0.31