60 fps = 16,6 миллисекунд на кадр, если у тебя в кадр X runtime решит порыскать по помойкам прям ровно 5 мс, то у тебя на кадр останется 11,6 миллисекунд, т.е. на целых 30,13% меньше для обработки логики и отрисовки. а если GC займёт более 10 миллисекунд то ты практически кадр потерял и получил микролаг GC можно использовать только для бизнес логики, не для самого рендера, тот должен быть manually managed

это зависит от того что рендерить. если условный эксельчик или там менеджер виртуальных машин, то какая наплевать?

это зависит от того что рендерить. если условный эксельчик или там менеджер виртуальных машин, то какая наплевать?

нет, это НЕ зависит от того какая у тебя логика. рендер и бизнес-логика - разъдельны и оперируют в разных независимых потоках. Единственное что рендер-поток делает это считывает переодически состояние данных.

потому-что рендеру ВСЕГДА нужно укладываться в 16 миллисекунд для полноценных 60 фпс без микролагов и этого сложно добиться с GC ибо он плохо предсказуем

нет, это НЕ зависит от того какая у тебя логика. рендер и бизнес-логика - разъдельны и оперируют в разных независимых потоках. Единственное что рендер-поток делает это считывает переодически состояние данных.

ну в го они и будут в разных потоках

ну в го они и будут в разных потоках

нет, они будут в 1 рантайме, у которого 1 GC

который в любой момент может решить что ему нужно на помойку заглянуть и прое.. потеряет кадр

нет, они будут в 1 рантайме, у которого 1 GC

речь шла о потоках. а рантайм да - один.

речь шла о потоках. а рантайм да - один.

то что горутины могут в несколько потоков это всем известно, но то что нельзя просто взять и запустить рендер в отдельном от бизнес-логике runtime'е без GC - увы факт

использовать Go вместе каким-то отдельным рендером который вне runtime'а - вот это вполне годная идея

пускай рендер рисует а Go с данными и логикой работает

но я не уверен можно ли это реализовать..

если бы можно было например рендер написать на Rust и позволить Go каким-то образом импортировать его как дин. библиотеку ака .dll/.so чтоб они делили меж друг другом память

а зачем плодить технологии в одном проекте, все на расте делай и все

а зачем плодить технологии в одном проекте, все на расте делай и все

Rust он блин сложный, ты не хочешь на нём бизнеслогику писать..

и асинхронщину тоже я лично писать не хочу

то что горутины могут в несколько потоков это всем известно, но то что нельзя просто взять и запустить рендер в отдельном от бизнес-логике runtime'е без GC - увы факт

Зачем рендер без гарбадж коллектора условному например гую для простановки mp3 тэгов?

я вообще не хочу писать, только деньги получать

и не только на расте

Rust он блин сложный, ты не хочешь на нём бизнеслогику писать..

c++

если бы можно было например рендер написать на Rust и позволить Go каким-то образом импортировать его как дин. библиотеку ака .dll/.so чтоб они делили меж друг другом память

Так А что мешает?

Зачем рендер без гарбадж коллектора условному например гую для простановки mp3 тэгов?

Там реально надо 60 fps?

c++

Паrни, я вам немного пэхэпэ принес https://www.peachpie.io

Так А что мешает?

отсутствие опыта и времени)) у тебя есть идея как такое реализовать?

Зачем рендер без гарбадж коллектора условному например гую для простановки mp3 тэгов?

не понял вопрос

Паrни, я вам немного пэхэпэ принес https://www.peachpie.io

подавись им! *я это, любя.. ?*

не понял вопрос

Есть куча приложений, где информация в приложении обновляется с частотой в доли герца. Чем там вредят паузы в 5 миллисекунд иногда?

замечу ли я паузу в 5 милисекунд в интерфейсе keepass?

или условном thunderbird

паузу в 5 милисекунд наверное можно заметить в шутере

Есть куча приложений, где информация в приложении обновляется с частотой в доли герца. Чем там вредят паузы в 5 миллисекунд иногда?

ещё раз: в графике у тебя строгие требования к performance'у, если 60 фпс то у тебя ~16 миллисекунд на отрисовку кадра, не более, если 144 фпс то вообще не более ~6,8 GC не предсказуем, поэтому такие вещи как рендер лучше писать на мануальном менеджменте памяти в обход всяких runtime'ов. 6 миллисекунд на кадр это тебе не 10к HTTP запросов обработать, там можно и на секунду провалить дэдлайн, ничего с тобой не будет, а GUI пользователь тебе такое не простит

давно не играл. помню в майнкрафте на жабе лаги напрягали иногда

ещё раз: в графике у тебя строгие требования к performance'у, если 60 фпс то у тебя ~16 миллисекунд на отрисовку кадра, не более, если 144 фпс то вообще не более ~6,8 GC не предсказуем, поэтому такие вещи как рендер лучше писать на мануальном менеджменте памяти в обход всяких runtime'ов. 6 миллисекунд на кадр это тебе не 10к HTTP запросов обработать, там можно и на секунду провалить дэдлайн, ничего с тобой не будет, а GUI пользователь тебе такое не простит

откуда строгие требования? что плохо в потере одного кадра при отрисовке условного keepass?

откуда строгие требования? что плохо в потере одного кадра при отрисовке условного keepass?

условного keepass - ничего, но если ты хоть раз в жизни пользовался анимированными красивыми современными UI - ты меня поймёшь. Микролаги это катастрофа для анимаций... просто посмотри фильм с переодическими хаотичными микролагами... тебе такой фильм все нервы сожрёт, там про UX даже говорить не надо.. user-experience быстро превратится в ultra-xu€vo

условного keepass - ничего, но если ты хоть раз в жизни пользовался анимированными красивыми современными UI - ты меня поймёшь. Микролаги это катастрофа для анимаций... просто посмотри фильм с переодическими хаотичными микролагами... тебе такой фильм все нервы сожрёт, там про UX даже говорить не надо.. user-experience быстро превратится в ultra-xu€vo

Пользовался. Ну нахуй.

Меньше анимации в интерфейсе - здоровее психика

Меньше анимации в интерфейсе - здоровее психика

видимо не теми приложениями неправильных дизайнеров пользовался, потому-что полное отсутствие анимаций это тоже не айс но ты конечно можешь сказать что дизайнеры Apple вообще идиоты и в UX не шарят и UI современных айфонов вообще должен быть как UI keepass... но тебя не поймут)))

то что горутины могут в несколько потоков это всем известно, но то что нельзя просто взять и запустить рендер в отдельном от бизнес-логике runtime'е без GC - увы факт

Можно интерфейс в отдельном процессе запускать, как отдельное приложение и тогда gc должен быть отдельный, если я правильно понимаю. Есть ли минусы у такого подхода?

А, сори, ниже эта мысль была

Можно интерфейс в отдельном процессе запускать, как отдельное приложение и тогда gc должен быть отдельный, если я правильно понимаю. Есть ли минусы у такого подхода?

тогда у тебя будет проблема с шарингом памяти между рендером и данными. придётся городить IPC а это ойойой, лучше не надо..

Есть куча приложений, где информация в приложении обновляется с частотой в доли герца. Чем там вредят паузы в 5 миллисекунд иногда?

С какой частотой? Ведь Гц -- это мера частоты...

видимо не теми приложениями неправильных дизайнеров пользовался, потому-что полное отсутствие анимаций это тоже не айс но ты конечно можешь сказать что дизайнеры Apple вообще идиоты и в UX не шарят и UI современных айфонов вообще должен быть как UI keepass... но тебя не поймут)))

между тем я вижу сотни приложений вокруг у которых рендер вполне мог бы быть на го и никто от этого не пострадал бы потому что нет анимации

между тем я вижу сотни приложений вокруг у которых рендер вполне мог бы быть на го и никто от этого не пострадал бы потому что нет анимации

если уж и разрабатывать UI на Go то они должны быть future-proof а не "ну мы как-бы можем UI но только такое как у keepass"... раз ты так утверждаешь то предлагаю тебе написать такую библиотеку, но предупреждаю - она никому не будет нужна в 2018+ году)

рендер на Go писать нельзя, Go не для time-critical систем изобретался, это всё-равно что молотком шуруп в железо заколачивать

а вот совместить Go с неким внешним рендером но чтоб они работали в 1 процессе (но рендер работал вне runtime'а Go) можно

рендер на Go писать нельзя, Go не для time-critical систем изобретался, это всё-равно что молотком шуруп в железо заколачивать

Скорее отвёрткой заворачивать гвоздь

Скорее отвёрткой заворачивать гвоздь

точно

замечу ли я паузу в 5 милисекунд в интерфейсе keepass?

Если кадр показывается в среднем 16,6мс, то это 60 фпс. Если кадр показывается 41,6мс, то это 24 фпс. Таким образом время отображения кадра лучше бы держать в пределах 40мс, чтобы глаз не резали лаги интерфейса

вопрос знатакам cgo: можно ли написать условный процесс A на Rust и скомпилить его вместе с Go кодом в 1 бинарь, чтоб они спокойно делили меж собой память и могли коммуницировать? ну или хотя-бы C, но ой как не охота писать на C..

тогда у тебя будет проблема с шарингом памяти между рендером и данными. придётся городить IPC а это ойойой, лучше не надо..

Ну, если фронтенд и бэкенд не так интенсивно обмениваются данными, то может и не нужно шарить память?

Сори, если вопросы глупые, я не то что бы программист

тогда у тебя будет проблема с шарингом памяти между рендером и данными. придётся городить IPC а это ойойой, лучше не надо..

коллега, а вы в курсе, как работает X11?

Ну, если фронтенд и бэкенд не так интенсивно обмениваются данными, то может и не нужно шарить память?

нужно, иначе как? хочешь IPC? чтоб для каждой системы писать отдельную, медленную реализацию передачи данных между процессами а на мобилках это было бы вообще невозможно?

коллега, а вы в курсе, как работает X11?

брать пример с X11?!

почему нет?

(пример, конечно, надо брать с osx)

почему нет?

потому-что медленно (многократное копирование) и некроссплатформенно зачем, если можно в 1 процесс уложиться?

ведь cgo же компилирует каким-то образом C и Go в один бинарь..

но лучше таки писать рендер на Rust а не на C

вопрос знатакам cgo: можно ли написать условный процесс A на Rust и скомпилить его вместе с Go кодом в 1 бинарь, чтоб они спокойно делили меж собой память и могли коммуницировать? ну или хотя-бы C, но ой как не охота писать на C..

На хабре емнип пару лет назад была статья

по сути-ж нам нужно лишь слинковать Rust библиотеку с Go кодом

layout, painting, drawcalls всё в Rust в Go только использование некого интерфейса, который предоставляет рендеру модели данных

нужно, иначе как? хочешь IPC? чтоб для каждой системы писать отдельную, медленную реализацию передачи данных между процессами а на мобилках это было бы вообще невозможно?

А как работают системы, у которых фронт и бэк раздельные приложения? Бэкенд бывает и на другом компьютере находится, а этот компьютер с бэком не всегда близко. И данными они как-то обмениваются. Вот хороший на мой взгляд пример - мультиплеерные компьютерные игры

но честно говоря переизобретать Qt Quick и QML на Rust нет желания и времени.. уж лучше просто брать Qt и использовать его в качестве фронтэнда и рендера с языком QML и как-то подружить Go с ним... что собственно уже неоднократно делали но проекты эти почему-то все погибли..

А как работают системы, у которых фронт и бэк раздельные приложения? Бэкенд бывает и на другом компьютере находится, а этот компьютер с бэком не всегда близко. И данными они как-то обмениваются. Вот хороший на мой взгляд пример - мультиплеерные компьютерные игры

эээээ... мы тут вообще-то про GUI приложения, а не сетевые приложения.

Хм, не очень понял. У приложения есть часть с интерфейсом - фронт и часть с логикой - бэк. Почему это неприменимо на десктопные приложения?

Хм, не очень понял. У приложения есть часть с интерфейсом - фронт и часть с логикой - бэк. Почему это неприменимо на десктопные приложения?

Graphics Card <--> Video Driver <-- Graphics API <-- Renderer <--> Application <--> Network <--> Server

мы говорим о том, как написать приложение на Go с отрисовкой GUI на экран

ответ: никак, не надо этого делать, потому-что GC == microlags! а можно ли использовать Go для логики приложения у которого внешний рендер вне Go runtime? это уже другой вопрос..

надо, надо) вот фаерфокс написан на вышем Rust`е, но лагает так же как и все программы, только не на рендере, а на сети

причем так лагает, что уже прогруженное и отрисованное даже не скроллится

60 fps = 16,6 миллисекунд на кадр, если у тебя в кадр X runtime решит порыскать по помойкам прям ровно 5 мс, то у тебя на кадр останется 11,6 миллисекунд, т.е. на целых 30,13% меньше для обработки логики и отрисовки. а если GC займёт более 10 миллисекунд то ты практически кадр потерял и получил микролаг GC можно использовать только для бизнес логики, не для самого рендера, тот должен быть manually managed

@cryptstal ,пожалуйста, читайте, если тема вам интересна

да я не вижу смысла ловить по 5мс микролаги, если в целом так обгадиться на сети

тогда у тебя будет проблема с шарингом памяти между рендером и данными. придётся городить IPC а это ойойой, лучше не надо..

Это довольно легко

тогда у тебя будет проблема с шарингом памяти между рендером и данными. придётся городить IPC а это ойойой, лучше не надо..

Для пары процессов ipc делается просто: либо uf_unix, либо shared memory

И насколько я помню, pthread mutex умеет жить в shm

Вечер добрый! Народ, поделитесь опытом (мнением) как правильно реализовать механизм аутентификации с использованием OAuth? Вопрос конкретно в следующем: Зарегил приложние на Яндексе, чтобы OAuth пользоваться. Написал простенький фронт (SPA на Vue). Алгоритм сейчас такой: 1. Пользователь на странице нажимает кнопку выбора провайдера аутентификации (в частности " войти через Яндекс") 2. Попадает на старницу разрешений Яндекса 3. Яндекс делает callback на страницу SPA и вставляет в url кода для запроса Token. 4. SPA извлекает код из урла и делает запрос на backend (естественно на go) 5. Backend проверяет код в запросе, запрашивает токен, запрашивает данные пользователя (email, id, name) 6. Backend проверяет имеется ли пользователь в базе (т.е. зарегистрировался он уже в приложении или нет) ....И вот тут вопрос если пользователя нет, то перед тем как зарегистрироваться ему нужно прочитать и согласиться с "Соглашнием о..." Если пользователя в базе нет тогда: 7. Создаю uid-ключ и добавляю в Redis запись с данными пользователя полученными от Яндекса (которая экспайрится через 5 минут). 8. Возвращаю uid обратно пользователю и перекидываю его на страницу соглашения. 9. Если пользователь согласился, то он нажимает кнопку "согласен" и отправляет подтверждение на сервер вместе с uid. 10. Backend получает запрос на подтверждение регистрации, извлекает uid,проверяет, извлекает данные из Redis, если OK удаляет запись в Redis. 11. Регит пользователя, генерит ему jwt 12. Возвращает пользователю cookies c jwt токеном. Далее пользователь уже общается с backend-ом через данные в куках.... Вопрос....Это я велосипед придумал? Или может есть какой-то рабочий паттерн для этих целей... ? Заранее спасибо!

Вечер добрый! Народ, поделитесь опытом (мнением) как правильно реализовать механизм аутентификации с использованием OAuth? Вопрос конкретно в следующем: Зарегил приложние на Яндексе, чтобы OAuth пользоваться. Написал простенький фронт (SPA на Vue). Алгоритм сейчас такой: 1. Пользователь на странице нажимает кнопку выбора провайдера аутентификации (в частности " войти через Яндекс") 2. Попадает на старницу разрешений Яндекса 3. Яндекс делает callback на страницу SPA и вставляет в url кода для запроса Token. 4. SPA извлекает код из урла и делает запрос на backend (естественно на go) 5. Backend проверяет код в запросе, запрашивает токен, запрашивает данные пользователя (email, id, name) 6. Backend проверяет имеется ли пользователь в базе (т.е. зарегистрировался он уже в приложении или нет) ....И вот тут вопрос если пользователя нет, то перед тем как зарегистрироваться ему нужно прочитать и согласиться с "Соглашнием о..." Если пользователя в базе нет тогда: 7. Создаю uid-ключ и добавляю в Redis запись с данными пользователя полученными от Яндекса (которая экспайрится через 5 минут). 8. Возвращаю uid обратно пользователю и перекидываю его на страницу соглашения. 9. Если пользователь согласился, то он нажимает кнопку "согласен" и отправляет подтверждение на сервер вместе с uid. 10. Backend получает запрос на подтверждение регистрации, извлекает uid,проверяет, извлекает данные из Redis, если OK удаляет запись в Redis. 11. Регит пользователя, генерит ему jwt 12. Возвращает пользователю cookies c jwt токеном. Далее пользователь уже общается с backend-ом через данные в куках.... Вопрос....Это я велосипед придумал? Или может есть какой-то рабочий паттерн для этих целей... ? Заранее спасибо!

А не проще ли сделать роль "согласился с соглашением"?

А не проще ли сделать роль "согласился с соглашением"?

Т.е. в jwt зашить эту роль и payload для регистрации?

после 6 пункта -- создаешь пользователя без роли если его нет

7 пунктом показываешь соглашение, если у текущего пользователя нет роли

если он соглашается -- добавляешь ему роль

да я не вижу смысла ловить по 5мс микролаги, если в целом так обгадиться на сети

что?!

Для пары процессов ipc делается просто: либо uf_unix, либо shared memory

shared memory и "довольно легко"))) для каждой платформы отдельный механизм IPC, на мобилках (ведройд, иос) вообще пздц плюс лишнее копирование данных туда сюда, из-за чего придётся скорее всего буферизировать и т.д. и т.п. "довольно легко"))

shared memory и "довольно легко"))) для каждой платформы отдельный механизм IPC, на мобилках (ведройд, иос) вообще пздц плюс лишнее копирование данных туда сюда, из-за чего придётся скорее всего буферизировать и т.д. и т.п. "довольно легко"))

Копирование откуда?

Копирование откуда?

с shared memory копирование можно избежать, но вот я не понимаю как ты на мобилках shared memory реализуешь..

с shared memory копирование можно избежать, но вот я не понимаю как ты на мобилках shared memory реализуешь..

На андроид - без проблем

думаю что нативные GUI это проигрышный вариант, писать приложение отдельно для разных систем это невыгодно и проблематично, лучше использовать браузер в качестве платформы для GUI, только не на HTML/CSS разумеется а на WebGL, мы об этом помоему уже говорили

ждём когда в WASM завезут потоки и переходим на WASM

и думаем как можно потенциально написать рендер на Rust который работает в связке с Go для асинх логики и скомпилить всё это в 1 WASM бинарь