[SYCL 입문 #1] SYCL 소개 및 개발 환경 준비, Hello SYCL 예제

SYCL 입문 시리즈의 첫 번째 글입니다. 이번 글에서는 SYCL이란 무엇이며, 왜 SYCL을 사용할 때 NVIDIA GPU나 Qualcomm GPU에서도 동일한 코드를 실행할 수 있는지 기본 개념을 소개합니다. 또한 개발 환경 설정, CMake 빌드 시스템 활용, 그리고 가장 기본적인 “Hello SYCL!” 예제를 통해, 독자가 실제로 코드를 컴파일하고 실행해보는 과정을 안내하겠습니다.이 글은 SYCL에 완전히 처음 입문하는 독자를 대상으로 하며, 모든 단계에 대해 가능한 한 자세히 설명하여, 글을 따라만 해도 실제 코드를 실행할 수 있도록 하였습니다.왜 SYCL인가?SYCL은 Khronos 그룹에서 정의한, C++ 기반의 이식성 높은 병렬 프로그래밍 모델입니다. CUDA는 NVIDIA GPU 전용이..

• format_list_bulleted SYCL (시클)
• · 2024. 12. 19.
• textsms

[모던 C++로 다시 쓰는 GoF 디자인 패턴 총정리 #26] 플라이웨이트(Flyweight) 패턴: 값 기반 공유와 Ranges로 효율적 메모리 관리하기

이전 글에서는 퍼사드(Facade) 패턴을 모던 C++ 관점에서 재해석하며, 상속 없이 람다와 함수 합성으로 복잡한 서브시스템을 단순한 인터페이스로 감싸고, std::expected, std::format, coroutine, Ranges 등을 활용해 비동기 처리나 조건부 처리, 로깅, 에러 처리 등 다양한 요구사항에 쉽게 대응할 수 있음을 확인했습니다. 이번에는 구조적 패턴 중 플라이웨이트(Flyweight) 패턴을 다룹니다.플라이웨이트 패턴은 많은 수의 유사한 객체를 효율적으로 관리하기 위해 객체들이 공유할 수 있는 상태를 중앙에서 관리하는 패턴입니다. 예를 들어, 텍스트 처리기에서 각 문자를 개별 객체로 표현하면 메모리 낭비가 심하므로, 공유 가능한 폰트 정보나 형태 정보를 플라이웨이트 객체로 한 ..

• format_list_bulleted C++
• · 2024. 12. 16.
• textsms

[모던 C++로 다시 쓰는 GoF 디자인 패턴 총정리 #25] 퍼사드(Facade) 패턴: 람다와 Concepts로 복잡한 서브시스템 단순화하기

이전 글에서는 데코레이터(Decorator) 패턴을 모던 C++ 관점에서 재해석하며, 상속 없이도 람다 합성을 통해 객체에 동적으로 기능을 추가하는 방법을 살펴봤습니다. 이번에는 구조적 패턴 중 퍼사드(Facade) 패턴을 다룹니다.퍼사드 패턴은 복잡한 서브시스템을 단일하고 단순한 인터페이스로 감싸, 클라이언트가 시스템을 쉽게 사용할 수 있게 하는 패턴입니다. 전통적으로는 Facade 클래스를 만들어 서브시스템 객체들을 정적 호출 계층으로 감싸았으나, 이는 서브시스템 변경 시 Facade 수정 필요, 에러 처리나 비동기 처리 시 복잡성 증가 등의 문제를 야기합니다.C++20 이상에서는 Concepts, 람다, std::function, std::expected, std::format, coroutine,..

• format_list_bulleted C++
• · 2024. 12. 16.
• textsms

[모던 C++로 다시 쓰는 GoF 디자인 패턴 총정리 #24] 데코레이터(Decorator) 패턴: 함수 합성과 람다로 기능 동적 추가하기

이전 글에서는 컴포지트(Composite) 패턴을 모던 C++ 관점에서 재해석하며, std::variant와 std::visit를 통해 상속 없이 부분-전체 구조를 값 기반으로 표현하고, Ranges, coroutine, std::expected, std::format 등을 활용해 조건부 처리, 비동기 연산, 로깅 등 다양한 요구사항에도 쉽게 대응할 수 있음을 확인했습니다. 이번에는 구조적 패턴 중 데코레이터(Decorator) 패턴을 다룹니다.데코레이터 패턴은 객체에 동적으로 새로운 기능을 추가하기 위한 패턴이며, 전통적 구현에서는 컴포넌트를 상속한 데코레이터 클래스 계층을 통해 기능을 장식(Decorate)해야 했습니다. 그러나 이는 클래스 증가와 유지보수 어려움을 초래합니다. C++20 이상에서는 ..

• format_list_bulleted C++
• · 2024. 12. 16.
• textsms

[모던 C++로 다시 쓰는 GoF 디자인 패턴 총정리 #23] 컴포지트(Composite) 패턴: std::variant와 Ranges로 부분-전체 트리 구조 간단히 표현하기

이전 글에서는 브리지(Bridge) 패턴을 모던 C++ 관점에서 재해석하며, 상속 기반 추상/구현 분리 없이도 람다, Concepts, std::expected, coroutine, Ranges, std::format 등을 활용해 추상과 구현을 유연하게 연결할 수 있음을 확인했습니다. 이번에는 구조적 패턴 중 컴포지트(Composite) 패턴을 다룹니다.컴포지트 패턴은 객체를 트리 구조로 구성해, 개별 객체(Leaf)와 복합 객체(Composite)를 동일하게 다룰 수 있게 하는 패턴입니다. 전통적으로는 Component 추상 클래스, Leaf, Composite 클래스 상속 계층을 정의했으나, 이는 클래스 증가와 유지보수 어려움을 야기합니다.C++20 이상에서는 std::variant, std::vis..

• format_list_bulleted C++
• · 2024. 12. 16.
• textsms

[모던 C++로 다시 쓰는 GoF 디자인 패턴 총정리 #22] 브리지(Bridge) 패턴: 추상과 구현을 함수 합성과 Concepts로 독립 확장하기

이전 글에서는 어댑터(Adapter) 패턴을 모던 C++ 관점에서 재해석하며, 기존 인터페이스를 원하는 다른 인터페이스로 변환하기 위해 상속 없이도 람다, Concepts, std::expected, std::format, coroutine, Ranges 등을 활용할 수 있음을 확인했습니다. 이번에는 구조적 패턴 중 브리지(Bridge) 패턴을 다룹니다.브리지 패턴은 추상(Abstraction)과 구현(Implementation)을 분리하여 둘을 독립적으로 확장 가능하게 만드는 패턴입니다. 전통적으로는 추상 클래스 계층과 구현 클래스 계층을 상속 기반으로 구분하고, 추상 클래스가 구현 객체를 참조하는 구조를 사용했습니다. 이 방식은 새로운 추상이나 구현 타입 추가 시 클래스 증가와 복잡성 상승을 초래합니..

• format_list_bulleted C++
• · 2024. 12. 16.
• textsms

[모던 C++로 다시 쓰는 GoF 디자인 패턴 총정리 #21] 어댑터(Adapter) 패턴: 함수 합성과 Concepts로 인터페이스 변환하기

이전 글에서는 비지터(Visitor) 패턴을 모던 C++ 관점에서 재해석하며, std::variant와 std::visit를 통해 이중 디스패치 없이도 다양한 요소 타입별 로직을 처리하는 법을 살펴보았습니다. 이제는 구조적(Structural) 패턴 중 하나인 어댑터(Adapter) 패턴을 다룹니다.어댑터 패턴은 기존 클래스나 함수 인터페이스를 클라이언트가 원하는 다른 인터페이스로 변환하는 패턴입니다. 전통적으로는 어댑터 클래스를 상속 기반으로 정의하고, 기존 인터페이스를 변환하는 메서드를 구현했지만, 이 방식은 클래스 증가, 상속 기반 구조로 인한 유지보수 어려움을 야기합니다.C++20 이상에서는 Concepts로 원하는 인터페이스 요구사항을 명시하고, 람다나 함수 합성으로 변환 로직을 구현하면 상속 ..

• format_list_bulleted C++
• · 2024. 12. 16.
• textsms

[모던 C++로 다시 쓰는 GoF 디자인 패턴 총정리 #20] 비지터(Visitor) 패턴: std::variant와 std::visit로 이중 디스패치 없이 방문 로직 구현하기

이전 글에서는 템플릿 메서드(Template Method) 패턴을 모던 C++ 관점에서 재해석하며, 상속 없이도 람다, Concepts, std::expected, std::format, coroutine, Ranges 등을 활용해 알고리즘 골격을 선언적이고 타입 안전하게 표현할 수 있음을 확인했습니다. 이번에는 행동(Behavioral) 패턴 중 비지터(Visitor) 패턴을 다룹니다.비지터 패턴은 객체 구조(예: 복합 구조나 노드 트리)를 순회하면서, 각 요소 타입에 따라 다른 연산을 수행할 수 있게 하는 패턴입니다. 전통적으로는 각 요소 클래스에 accept(Visitor&) 메서드를 정의하고, 비지터 인터페이스에 각 요소 타입별 visit() 메서드를 두어 이중 디스패치를 실현했으나, 이는 클래스..

• format_list_bulleted C++
• · 2024. 12. 16.
• textsms

[모던 C++로 다시 쓰는 GoF 디자인 패턴 총정리 #19] 템플릿 메서드(Template Method) 패턴: 알고리즘 골격을 Concepts와 람다로 선언적으로 표현하기

이전 글에서는 메멘토(Memento) 패턴을 모던 C++ 관점에서 재해석하며, 상속 없이 값 기반 상태 스냅샷과 std::expected, coroutine, Ranges 등을 활용해 Undo/Redo, 비동기 복원, 로깅 등의 요구사항에 대응할 수 있음을 확인했습니다. 이번에는 행동(Behavioral) 패턴 중 템플릿 메서드(Template Method) 패턴을 다룹니다.템플릿 메서드 패턴은 상위 클래스에서 알고리즘의 골격(템플릿)을 정의하고, 하위 클래스에서 일부 단계를 오버라이드하여 구체화하는 패턴입니다. 그러나 전통적 접근은 상속 기반 구조로, 알고리즘 변형 시 하위 클래스 증가, 유지보수 어려움 등이 발생합니다. C++20 이상에서는 Concepts, 람다, std::expected, std:..

• format_list_bulleted C++
• · 2024. 12. 16.
• textsms

[모던 C++로 다시 쓰는 GoF 디자인 패턴 총정리 #18] 메멘토(Memento) 패턴: 상태 스냅샷을 값 기반으로 캡슐화하고 복원하기

이전 글에서는 미디에이터(Mediator) 패턴을 모던 C++ 관점에서 재해석하며, 상속 기반 구조 없이도 Concepts, std::function, std::expected, coroutine, Ranges 등을 활용해 객체 간 상호작용을 유연하고 타입 안전하게 구현할 수 있음을 확인했습니다. 이번에는 행동(Behavioral) 패턴 중 메멘토(Memento) 패턴을 다룹니다.메멘토 패턴은 객체 상태를 캡슐화(스냅샷)하여, 이후 필요할 때 원래 상태로 복원하는 기법을 제공합니다. 전통적으로는 Originator(원본 객체), Memento(상태 저장), Caretaker(메멘토 관리) 클래스를 정의하고, Memento 클래스로 상태를 저장/복원하는 상속 기반 구조를 사용했습니다. 그러나 모던 C++2..

• format_list_bulleted C++
• · 2024. 12. 16.
• textsms