음, Fil-C가 정말 중요한 의미를 가질 수 있을 것 같음. 오직 C 코드로만 존재하는 소프트웨어가 많아서, 이를 유지하는 접근법이 필요하다고 생각함. 기존 C 컴파일러들은 단일 코어 성능 극대화를 위해 큰 보안 위험을 감수하는데, 이런 트레이드오프는 이미 시대에 뒤떨어진 느낌임. CPython, SQLite, OpenSSH, ICU, CMake, Perl5, Bash 등 지원 리스트가 정말 대단함. 저 소프트웨어들 중 누구도 Rust로 다시 작성될 가능성은 낮다고 봄. Fil-C를 MMU 없는 환경에서 상호 신뢰할 수 없는 프로세스 간 멀티태스킹에도 활용 가능한지 궁금함. 권한 기반 보안, 논블로킹 동기화 등 적절하게 방향을 잡고 있는 것 같음. 누가 실제로 써본 경험 있는지 알고 싶음. 실제로는 최악의 경우에도 4배 정도 속도가 감소한다는 보고가 있는데, 이름이 정말 재밌음. 필쓰웨이! 필쓰웨이!
Fil-C로 MMU 없는 컴퓨터에서 신뢰할 수 없는 프로세스 간 멀티태스킹이 가능한지 궁금하다는 질문에 대해, 기본적으로 FUGC가 OS의 MMU 의존적 기능에 기반하긴 하지만, 이런 의존성을 제거한 버전도 만들 수 있을 거라고 봄. 성능 관련해선, 4배 느려지는 것은 최악의 상황이고 그 수치를 직접 보고했음. 항상 현실적으로 성능을 측정하고, 집요하게 성능 문제를 개선해야 하는 성향이 있음. 실제로 Fil-C 버전 소프트웨어로도 평소에 즐겨 사용하는 프로그램을 무리 없이 쓸 수 있음
지원 소프트웨어 리스트가 인상적이라 하셨는데, 일반론에는 동의하지만 예시로 든 소프트웨어는 약간 다르게 봄. CPython, Perl5 등은 원래 GC가 느리기로 유명한 언어의 런타임이라 여기에 GC를 하나 더 얹는 게 우아한 설계는 아닌 듯하고, 오히려 속도 저하가 클 수 있음. 그리고 Rust나 Go 등으로 다시 구현하거나 대체하려는 시도가 이미 일부 있고, 예를 들어 SQLite는 Turso가 있음. 또 이런 소프트웨어는 워낙 활발히 관리되는 근본적인 프로젝트라서 언젠가 자체적으로 리팩터링이나 Rust로의 포팅을 할 수도 있다고 봄. 오히려 Fil-C가 더 적합한 곳은 관리가 덜 되고, 성능에 덜 민감하면서도 계속 사용하는, 50년 전 C 프로그램처럼 누군가 종종 꺼내 쓰는 코드라 생각함
SQLite가 C로 작성된 강점은 비표준 OS로의 이식성이 큼임. 예를 들어 임베디드용 RTOS인 μC/OS-II에서 직접 사용한 경험 있음. 임베디드 환경 설계는 PC/서버와 꽤 달라서, 성능과 메모리 단편화 방지 목적으로 메모리 해제를 아예 하지 않고 오브젝트/구조체를 재사용하게 표시함. 커스텀 힙 할당이나 풀링 같은 개념임. SQLite의 VFS 문서, Micro-Controller OS 소개
예시로 든 리스트의 C 소프트웨어를 Rust로 다시 쓸 일은 없다고 하셨는데, 인공지능 기반 정적 분석 도구가 발전해서 C 코드의 문제점을 정확하게 찾아내고, “이 부분은 오류가 생긴다, 이렇게 고치면 된다”라는 피드백을 줄 수 있을 정도가 되기까지 앞으로 얼마나 남았는지 궁금함. 그런 도구가 진짜 나오면 그냥 계속 C를 써도 괜찮아질 수 있음
이런 프로젝트는 연구와 실용을 동시에 따라가는 드문 사례인 느낌임. 이런 일은 보통 대형 IT 기업에서 팀을 두고 광고 수익으로 운영되는 경우가 많은데, Fil-C는 무슨 배경에서 출발했는지 궁금함. 단순한 개인 열정 프로젝트가 아니라면, 누가 자금을 댔고 몇 년의 인력 투입이 있었는지, 그리고 최종 목표가 무엇인지 궁금함
개인적으로 봤을 때 이건 열정 프로젝트 같음
최종 목표를 묻는 질문에 대해, 프로젝트 저작권이 2024-2025 Epic Games, Inc.라고 명시됨
Fil-C의 존재 자체가 반가움. 이런 기술이 실제 프로그램에 효과적임에도 개발자들이 “그런 거 안 된다”고 믿는 경우가 많은데, 직접 구현이 가능하다는 사실만으로도 숱한 논쟁을 단숨에 끊어주는 역할이 있음
벤치마크 결과가 궁금함. 이런 접근법의 가장 큰 우려는 C/C++이 여전히 인기 있는 특정 용례에서 성능이 어마어마하게 떨어지는 게 아닐까 하는 점임. 처리량이나 레이턴시, 메모리 사용량이 Go 같은 언어와 너무 비슷해져버리면, 결국 선택할 이유가 별로 남지 않을 것 같음
프로그래밍 언어에서는 어셈블리 시절부터 성능 대 담론이 항상 존재했음. 다만 대부분의 개발자들은 Ivan Suntherland, Alan Kay, Steve Jobs, Bret Victor 같은 비범한 비전을 가진 사람이 아니고, 눈앞에서 직접 작동하는 것을 보고 신뢰하는 보통 사람임. 그래서 지금도 UNIX와 C의 복제판이 넘쳐나고, 새로운 것을 창조하기보다 과거의 비전을 그대로 답습하며 살아가는 경우가 많은 듯함. 물론 1970년대 당시 UNIX와 C를 만든 두 명도 대단한 비전가였음
advancing wavefront 방식 대신 왜 retreating wavefront 전략을 쓰지 않았는지 궁금함
기존 C 프로그램의 free(...) 호출들이 이미 적절하게 들어있고, 모든 포인터에 대해 별도 범위 정보까지 관리하고 있다면, 왜 전체 GC를 선택했는지 궁금함. 대신 lock-and-key 방식의 temporal checking 기법(참고자료: 논문 링크)이 메모리 사용량 예측이나 성능, 스케줄링 면에서 더 나을 수도 있다고 생각함. 아마도 key 저장 공간이 너무 크거나, 확인 시간이 오래 걸리거나, 멀티스레딩 환경에서 레이스 컨디션 문제가 생길 수도 있다고 추정함
lock and key 방식엔 Fil-C만의 똑똑한 특징이 없음. Fil-C의 capability 모델은 완전히 스레드 세이프하고, 대부분의 경우 특수한 atomics나 locking이 필요 없다는 점이 강점임
또 포인터 역참조가 없는 범위 밖 포인터 연산을 허용하는 점이 흥미로움. 컴파일러들이 종종 이런 부분의 UB를 노려 최적화를 하기도 하는데(Stack Overflow 관련 질문), Fil-C 내부 LLVM에서는 이런 최적화를 끄는지, 혹은 포인터를 “베이스 + 오프셋” 조합으로 관리해 아예 그런 가능성을 차단하는 것인지 궁금함. 혹시 그러면 일반 포인터에 적용되는 특정 최적화를 놓치게 되는 건 아닌지도 궁금함
정말 멋진 프로젝트로 보임. pollcheck의 fast path가 그냥 load-and-branch라는 것에 주목함. 이런 브랜치 대신 사용하는 흥미로운 기술이 있는데, 안드로이드 공식 블로그의 "암시적 suspend 체크" 문서에 잘 정리되어 있음
poll check에서는 저런 최적화를 흔히 씀. 실제로 대부분의 production JVM에서 이미 적용하고 있음. 하지만 나는 아직 저런 저수준 최적화까지 신경쓸 단계는 아님. 현재 남아있는 고수준의 기본적인 최적화들부터 해야 하는 상황임
GC가 붙은 동시성 지원 C, 그것도 non-moving GC라는 점이 정말 신기함. 만약 중형급 C 프로젝트를 2~3배의 런타임 성능 손해와 맞바꾸고 메모리 버그를 줄일 수 있다면, 충분히 감수할 의향이 있음. 점진적 도입이 얼마나 쉬운지 궁금함. 각 대상마다 가능한지, 아니면 전체 툴체인을 다 바꿔야 하는지 궁금함
나는 C와 성능, 그리고 보안을 모두 중요하게 여김. 이 GC와 capability 구조는 매력적임. “더 안전한 C”는 어떤 모습일지 여러 번 생각해 봤는데, capability 개념을 몇 번씩 검토하긴 했지만 난 컴파일러 코드는 잘 다루지 못함. Windows 지원이 힘든지 궁금함
사담이지만, 첫 문장에 Oxford comma가 없어서 무슨 뜻인지 이해하는데 꽤 오래 걸림. 이렇게 명확한 예시는 흔하지 않음
GC에서 루트 오브젝트를 어떻게 추적하는지 궁금함. GC가 스캔할 루트를 미리 표시하는 컴파일 단계라도 있는지, 혹시 아는 사람이 설명해줄 수 있는지 문의함
LLVM이 stack map을 채우기 위한 명령어를 삽입해서 해결하고 있음
이 프로젝트 정말 놀라움. 여태까지 들어본 적이 없던 게 이상할 정도임. 한번 직접 써보는 게 기대됨. 성능 한계로 실서비스에는 힘들 수 있지만, 일부 프로그램의 안전성을 직접 검증해볼 방법으로는 정말 유용해 보임. 평소에 사용하는 sanitizer보다는 더 포괄적인 느낌임
Hacker News 의견
음, Fil-C가 정말 중요한 의미를 가질 수 있을 것 같음. 오직 C 코드로만 존재하는 소프트웨어가 많아서, 이를 유지하는 접근법이 필요하다고 생각함. 기존 C 컴파일러들은 단일 코어 성능 극대화를 위해 큰 보안 위험을 감수하는데, 이런 트레이드오프는 이미 시대에 뒤떨어진 느낌임. CPython, SQLite, OpenSSH, ICU, CMake, Perl5, Bash 등 지원 리스트가 정말 대단함. 저 소프트웨어들 중 누구도 Rust로 다시 작성될 가능성은 낮다고 봄. Fil-C를 MMU 없는 환경에서 상호 신뢰할 수 없는 프로세스 간 멀티태스킹에도 활용 가능한지 궁금함. 권한 기반 보안, 논블로킹 동기화 등 적절하게 방향을 잡고 있는 것 같음. 누가 실제로 써본 경험 있는지 알고 싶음. 실제로는 최악의 경우에도 4배 정도 속도가 감소한다는 보고가 있는데, 이름이 정말 재밌음. 필쓰웨이! 필쓰웨이!
Fil-C로 MMU 없는 컴퓨터에서 신뢰할 수 없는 프로세스 간 멀티태스킹이 가능한지 궁금하다는 질문에 대해, 기본적으로 FUGC가 OS의 MMU 의존적 기능에 기반하긴 하지만, 이런 의존성을 제거한 버전도 만들 수 있을 거라고 봄. 성능 관련해선, 4배 느려지는 것은 최악의 상황이고 그 수치를 직접 보고했음. 항상 현실적으로 성능을 측정하고, 집요하게 성능 문제를 개선해야 하는 성향이 있음. 실제로 Fil-C 버전 소프트웨어로도 평소에 즐겨 사용하는 프로그램을 무리 없이 쓸 수 있음
지원 소프트웨어 리스트가 인상적이라 하셨는데, 일반론에는 동의하지만 예시로 든 소프트웨어는 약간 다르게 봄. CPython, Perl5 등은 원래 GC가 느리기로 유명한 언어의 런타임이라 여기에 GC를 하나 더 얹는 게 우아한 설계는 아닌 듯하고, 오히려 속도 저하가 클 수 있음. 그리고 Rust나 Go 등으로 다시 구현하거나 대체하려는 시도가 이미 일부 있고, 예를 들어 SQLite는 Turso가 있음. 또 이런 소프트웨어는 워낙 활발히 관리되는 근본적인 프로젝트라서 언젠가 자체적으로 리팩터링이나 Rust로의 포팅을 할 수도 있다고 봄. 오히려 Fil-C가 더 적합한 곳은 관리가 덜 되고, 성능에 덜 민감하면서도 계속 사용하는, 50년 전 C 프로그램처럼 누군가 종종 꺼내 쓰는 코드라 생각함
SQLite가 C로 작성된 강점은 비표준 OS로의 이식성이 큼임. 예를 들어 임베디드용 RTOS인 μC/OS-II에서 직접 사용한 경험 있음. 임베디드 환경 설계는 PC/서버와 꽤 달라서, 성능과 메모리 단편화 방지 목적으로 메모리 해제를 아예 하지 않고 오브젝트/구조체를 재사용하게 표시함. 커스텀 힙 할당이나 풀링 같은 개념임. SQLite의 VFS 문서, Micro-Controller OS 소개
예시로 든 리스트의 C 소프트웨어를 Rust로 다시 쓸 일은 없다고 하셨는데, 인공지능 기반 정적 분석 도구가 발전해서 C 코드의 문제점을 정확하게 찾아내고, “이 부분은 오류가 생긴다, 이렇게 고치면 된다”라는 피드백을 줄 수 있을 정도가 되기까지 앞으로 얼마나 남았는지 궁금함. 그런 도구가 진짜 나오면 그냥 계속 C를 써도 괜찮아질 수 있음
Fil-C가 아직 32비트(혹은 그 이하) 시스템을 지원하지 않는 점 참고해달라는 의견임. Fil-C에서 Invisicaps 관련 문서
이런 프로젝트는 연구와 실용을 동시에 따라가는 드문 사례인 느낌임. 이런 일은 보통 대형 IT 기업에서 팀을 두고 광고 수익으로 운영되는 경우가 많은데, Fil-C는 무슨 배경에서 출발했는지 궁금함. 단순한 개인 열정 프로젝트가 아니라면, 누가 자금을 댔고 몇 년의 인력 투입이 있었는지, 그리고 최종 목표가 무엇인지 궁금함
개인적으로 봤을 때 이건 열정 프로젝트 같음
최종 목표를 묻는 질문에 대해, 프로젝트 저작권이 2024-2025 Epic Games, Inc.라고 명시됨
Fil-C의 존재 자체가 반가움. 이런 기술이 실제 프로그램에 효과적임에도 개발자들이 “그런 거 안 된다”고 믿는 경우가 많은데, 직접 구현이 가능하다는 사실만으로도 숱한 논쟁을 단숨에 끊어주는 역할이 있음
벤치마크 결과가 궁금함. 이런 접근법의 가장 큰 우려는 C/C++이 여전히 인기 있는 특정 용례에서 성능이 어마어마하게 떨어지는 게 아닐까 하는 점임. 처리량이나 레이턴시, 메모리 사용량이 Go 같은 언어와 너무 비슷해져버리면, 결국 선택할 이유가 별로 남지 않을 것 같음
프로그래밍 언어에서는 어셈블리 시절부터 성능 대 담론이 항상 존재했음. 다만 대부분의 개발자들은 Ivan Suntherland, Alan Kay, Steve Jobs, Bret Victor 같은 비범한 비전을 가진 사람이 아니고, 눈앞에서 직접 작동하는 것을 보고 신뢰하는 보통 사람임. 그래서 지금도 UNIX와 C의 복제판이 넘쳐나고, 새로운 것을 창조하기보다 과거의 비전을 그대로 답습하며 살아가는 경우가 많은 듯함. 물론 1970년대 당시 UNIX와 C를 만든 두 명도 대단한 비전가였음
advancing wavefront 방식 대신 왜 retreating wavefront 전략을 쓰지 않았는지 궁금함
기존 C 프로그램의 free(...) 호출들이 이미 적절하게 들어있고, 모든 포인터에 대해 별도 범위 정보까지 관리하고 있다면, 왜 전체 GC를 선택했는지 궁금함. 대신 lock-and-key 방식의 temporal checking 기법(참고자료: 논문 링크)이 메모리 사용량 예측이나 성능, 스케줄링 면에서 더 나을 수도 있다고 생각함. 아마도 key 저장 공간이 너무 크거나, 확인 시간이 오래 걸리거나, 멀티스레딩 환경에서 레이스 컨디션 문제가 생길 수도 있다고 추정함
lock and key 방식엔 Fil-C만의 똑똑한 특징이 없음. Fil-C의 capability 모델은 완전히 스레드 세이프하고, 대부분의 경우 특수한 atomics나 locking이 필요 없다는 점이 강점임
또 포인터 역참조가 없는 범위 밖 포인터 연산을 허용하는 점이 흥미로움. 컴파일러들이 종종 이런 부분의 UB를 노려 최적화를 하기도 하는데(Stack Overflow 관련 질문), Fil-C 내부 LLVM에서는 이런 최적화를 끄는지, 혹은 포인터를 “베이스 + 오프셋” 조합으로 관리해 아예 그런 가능성을 차단하는 것인지 궁금함. 혹시 그러면 일반 포인터에 적용되는 특정 최적화를 놓치게 되는 건 아닌지도 궁금함
정말 멋진 프로젝트로 보임. pollcheck의 fast path가 그냥 load-and-branch라는 것에 주목함. 이런 브랜치 대신 사용하는 흥미로운 기술이 있는데, 안드로이드 공식 블로그의 "암시적 suspend 체크" 문서에 잘 정리되어 있음
GC가 붙은 동시성 지원 C, 그것도 non-moving GC라는 점이 정말 신기함. 만약 중형급 C 프로젝트를 2~3배의 런타임 성능 손해와 맞바꾸고 메모리 버그를 줄일 수 있다면, 충분히 감수할 의향이 있음. 점진적 도입이 얼마나 쉬운지 궁금함. 각 대상마다 가능한지, 아니면 전체 툴체인을 다 바꿔야 하는지 궁금함
나는 C와 성능, 그리고 보안을 모두 중요하게 여김. 이 GC와 capability 구조는 매력적임. “더 안전한 C”는 어떤 모습일지 여러 번 생각해 봤는데, capability 개념을 몇 번씩 검토하긴 했지만 난 컴파일러 코드는 잘 다루지 못함. Windows 지원이 힘든지 궁금함
GC에서 루트 오브젝트를 어떻게 추적하는지 궁금함. GC가 스캔할 루트를 미리 표시하는 컴파일 단계라도 있는지, 혹시 아는 사람이 설명해줄 수 있는지 문의함
이 프로젝트 정말 놀라움. 여태까지 들어본 적이 없던 게 이상할 정도임. 한번 직접 써보는 게 기대됨. 성능 한계로 실서비스에는 힘들 수 있지만, 일부 프로그램의 안전성을 직접 검증해볼 방법으로는 정말 유용해 보임. 평소에 사용하는 sanitizer보다는 더 포괄적인 느낌임