[%] wasm은 솔직히 가망 없음

[익명(121.133)]

wasm이 js 생태계 먹으려면 dom 접근이 가능하거나 js와 메모리를 공유할 수 있어야 함

근데 두 가지 모두 지금 구조상에선 불가능함

따라서 wasm을 쓸 이유가 없음 쓰면 더 느려져서

[익명(101.53)]

애초에 용도가 JS생태계 먹으려고 나온 물건이 아닌데 왜 돔접근을 못한다고 가망이 없다는거임?? JS를 대체할수 없다는거면 100% 맞는말인데, 그러려고 만든거 아니야

[익명(121.133)]

ㅇㅇ js 대체만이 목적은 아니긴 함 근데 그게 가장 큰 목적이잖아 서버 애플리케이션을 목적으로 하기엔 거기엔 굳이 wasm을 쓸 이유가 없음

[익명(101.53)]

그게 목적이 아니라니까 왜 가장 큰 목적이래

[익명(58.141)]

ㅋㅋㅋㅋ - dc App

[익명(101.53)]

CPU intensive한 작업을 하기위한게 WASM이지 JS에서 하던 돔제어 같은 작업들을 가져오려고 만든게 아니라고. CPU intensive한 무거운 작업이 웹 클라이언트에서 필요할때는 WASM쓰는게 압도적으로 성능이 좋아. 다만 그걸 그닥 무겁지 않은 작업에도 인터랙션이 일어날때마다 매번 하면 당연히 오버헤드가 더 클수도 있겠지 그것까지 감안해서 설계해야해야하는거다. 이건 정답이다 오답이다 이렇게 단언하는게 아니라

[익명(121.133)]

니 말이 맞음 내가 말을 잘못했다 내 말의 요지는 클라이언트에서 컴퓨팅 빡세게 돌리는 것 자체가 수요가 작은데 그 파이를 먹어서 뭘 할 수 있느냐는 거였음 그러니 일반 웹 프론트 작업도 wasm이 할 수 있기를 원했는데 그건 거의 불가능한 것이라는 거고

[익명(223.38)]

말나온김에.. 샌드박스환경 구성도 가능해서 개인정보보호는 덤임 - dc App

[익명(101.53)]

그 수요가 니가 보기엔 작아보이겠지만 생각보다 많음

[익명(118.235)]

js 대체가 아니라 상호보완적으로 쓰라고 내논거 아닌가

[익명(121.133)]

상호보완이라고 하지만 같이 쓰면 대부분 더 느려지기 때문에 결국 js로 작성하는 수밖에 없음

[익명(118.235)]

일반적인 상황이면 wasm 쓰는게 바보짓 맞음 근데 가끔 이득보는 상황이 있고 그거 타게팅하는거

[익명(118.235)]

굳이 cpu 갈구는걸 웹 프론트에서 처리하기로 결심했으면 그땐 와즘이 도움됨 확실히 저게 그닥 안 일반적인 상황인거도 맞긴 하고

[익명(101.53)]

내가 이걸로 벤치마킹 여러번 해봤지만 WASM썼을때 더 느려지는경우는 거의 없다. 보통은 아주 조금이라도 더 빠름. 다만 작성의 어려움까지 생각한다면 굳이 쓸 이유가 없는 경우가 더 일반적이라는거지. 그리고 일반적인 간단한 웹앱에 쓰라고 만든 물건이 아니기때문에 니가 쓸 일이 없다면 그냥 무시하면 되는거야

[익명(118.235)]

에 대부분 더 빨라진단거 까진 몰랐네 덕분에 배우고 간다

[익명(101.53)]

생각해보면 당연한거야. 흔히들 WASM의 오버헤드라고 말하는게 크로스바운더리인데 돔조작같은 가벼운 작업을 하는데 그 오버헤드가 큰게 말이 안되잖아 ㅋㅋㅋ 더 빨라진다 까지는 아니고, 의미없는 차이를 보이는 경우가 더 많다. 가 더 정확할듯. 여튼 차이는 없는데 개발은 더 빡세니 그런 앱에선 쓸 이유가 없는건 맞지 이런것까지 다 생각해야해서 WASM도 그렇고 GPU도 그렇고 로우레벨에 대한 이해가 없으면 못쓴다

[익명(223.38)]

따잇보단 그냥 상호보완적으로 써야하는게 맞지.. - dc App

[히힠키(invest4471)]

wasm이 사용되는 이유중 하나는 기존에 서버에서 처리하던 무거운 작업을 클라이언트한테 어느정도 넘겨줘서 서버에 부담을 줄이려는 이유도 있음. 물론 이런건 굳이 wasm말고 다른 언어로도 가능하긴 한데 클라한테 넘겨줬을때 보안에 문제가 생길법한 부분들도 있어서 wasm에 이리저리 난독화 해서 분석하기 어렵게 만들려는 목적도 있음

[익명(211.234)]

js의 약점을 wasm으로 보완하려고 만든건데 js생태계를 먹을 이유가 없지

[익명(211.234)]

그리고 돔접근 오버헤드가 커서 성능이 많이 느려진다는 벤치마크가 있음? 이런 주장하는 사람중에 벤치마크 결과로 어떤 상황에서 얼마나 느려지는지 그게 순수 wasm의 오버헤드 문제인지 엔진 최적화가 덜된건지 확인해주는 경우는 못봐서

[익명(101.53)]

돔접근이 오버헤드가 커서 성능이 느린게 아니라 WASM이라는게 JS와 별도의 런타임이고, 돔조작같은 브라우저 api는 wasm에선 제어가 안됨. 그래서 돔과 관련된 이벤트를 wasm에서 제어하려면 두 런타임사이의 통신이 너무 많이 발생하고, 동시에 애초에 작업 자체가 가벼웠다면 Wasm을 써서 얻는 이점보다 그 오버헤드가 더 클 수 있다는거지. 성능이 떨어지는경우는 거의없는데, wasm 쓰나 안쓰나 성능이 비슷한 경우는 아주 많음. 이건 wasm의 문제가 아니라, 지가 쓰는 툴도 이해못하고 쓰는 유저의 문제

[익명(211.234)]

@ㅇㅇ(101.53) 그건 아는데 실제로 오버헤드가 커서 손해보는 경우를 코드로 보고싶다는 말임

[익명(101.53)]

손해보는 경우는 없을걸?? 이 오버헤드라는게 결국은 런타임간의 인터롭인데 가벼운 돔조작은 이점도 작고 오버헤드도 작아서 쌤쌤임. 성능은 그대로인데 개발시간이 늘어나서 손해이긴 하겠다. 여튼 성능의 손해 이야기하는애들은 뇌피셜일거임

[익명(210.98)]

wasm이 왜 나온건지도 모르고 하는 말 같은데 일단 mdn wasm 항목 개요부터 읽어보고 와라