этот мой «гипотетический пример» — он везде вокруг. По крайней мере, пока Фантом не начал массовый захват мира ;)
Но вы опять по какую-то ОС — забудьте. В случае Фантома, если довольно грубо, то ОС — это современная программа. Программы Фантома — нити внутри современной программы. Нить возвращает программе стек? Остальные все ресурсы во владении самой программы? Вот так и будет в Фантоме. Нет никакого ни юзер- ни другого спейса. Прослойка VM и сразу железо.
Если вы сейчас в программе запускаете нить, что бы она сделала для вас полезную работу, нить в ходе этого нажрала гигабайты памяти, что происходит?
Либо, ссылка на эти гигабайты осталась в стеке, после освобождения стека протухла, и гигабайты подберет сборщик мусора, или нить отдала «полезное нажратое» вам в качестве результата — «на, слушай, сам выкинь, да!» (анекдот про бумеранг)
Разница в том, что при закрытии приложение освобождает утекшие ресурсы
прошу еще раз посмотреть на аналогию. В случае фантома «закрытие приложения» — это суть «завершилась нить» в тех приложениях которые сейчас.
Куда переносятся какие ресурсы из нити? Вот будет всё то же самое.
Сейчас, например у jre память можно жестко ограничить при запуске, и процесс внутри, будет получать отлупы.
Всё ровно то же будет происходить в Фантоме, никакой качественной разницы не будет.
То, что условно памяти станет несколько ТБ, я заметной разницей не считаю ;)
Попробую совсем тезисов: архитектура фантома не дает каких-то там заметных преимуществ в автоматическом управлении ресурсами. Наличие мозга у программиста всё еще требуется, аккуратность работы — всё еще важна важна. В то же время, каких-то заметных недостатков тоже нет — если программист с мозгом и аккуратен, на него не свалятся какие-то внезапные проблемы.
Сейчас утечка памяти живёт до закрытия приложения. Если файловой системы нет, утечки не на виду.
Если утечка не на виду, может это и не утечка вовсе?
Вопрос был в том, не является ли архитектура Фантом особенно к ним уязвимой.
Не думаю, что есть какая-то заметная разница, в сравнении с обычным приложением, если не рассматривать связи этого приложения и его окружения.
Хотя, за счет более стройной архитектуры в целом, может оказаться, что инструментарий для мониторинга/анализа и может быть даже автоматических каких-то реакций в таких ситуациях, будет проще реализовать.
Возьмем, например, String. Это data class? Он может протекать?
Возьмем, например, какой-нибудь BinaryTree. Это будет data class? Оно сможет протекать? Там будут виртуальные методы? Или, с другой стороны — нужно ли требовать где-то у таких классов отсутствие виртуальных методов?
«Нет сериализации».
Те же самые String и BinaryTree — их совсем нельзя будет сериализовать? Кто-то запретит мне из них сделать json или xml? Так и представляю, приходит dz и ufm, и грозят пальцем «ай-ай-ай, не сериализуй! Грешно! Будешь всю жизнь в SOAP долбиться!»
Что сейчас происходит, если программист забывает какую-то ссылку внутри?
Скорее всего в случае Фантома будет ровно то же самое. И просто «добавить персистентность» и «избавить от сериализации» на уровне системы, не сделает автоматически всех программистов умными.
Как и «добавь вывод типов» — тоже. Как и «добавь зависимые типы» — тоже не сделает.
Инструменты со строгой типизацией помогают человеку меньше ошибаться.
Вывод типов компилятором — помогают меньше писать руками.
Зависимые типы — позволяют исключить еще целый класс ошибок, и еще меньше писать руками. Чем больше вы добавляете мозгов/математики инструменту на уровне концепции, чем больше инструмент может проверить, по сути сужая область в которой программист может нафигачить — тем меньше ошибок.
Но персистентность — это ведь ортогональная штука ко всему этому. Отсутствие сериализации — это просто выкидывание целого класса тупой работы. Это уменьшает количество ошибок, но не концептуально, а рутинно — меньше работы — меньше ошибок.
Да и потом, давно уже всю сериализацию генерируют, не?
javaxb, protobuf, и вот это всё.
Но если у меня есть «документ», как суть, как понятие, он же как-то будет в системе представлен? Будет это data class, или будет это вполне себе smart class — у которого будет внутри какого-то метода while true, но не такой явный, который моймает компилятор, а заумный?
Если человек хочет прострелить себе ногу — он её прострелит.
Могу только повторить тот пример, с которого начал — представьте сейчас любую программу на managed платформе, у которой внутри запускаются отдельные потоки. Вот это примерно то же самое. Просто у современных программ есть какие-то отдельные концепции типа «файл», «база данных», «сеть», а Фантому эти концепции ненужны. И просто не нужно будет мне из какого-то BinaryTree, делать BinaryTreeJson, но не потому, что dz меня предаст анафеме, а просто с точки зрения здравого смысла — зачем заниматьая какой-то фигнёй, если можно прям сам объект отдать, и там всё правильно поймут?
«файл» — в данном случае, суть «документ», и конечно, есть же сейчас понятие data class?
Не понимаю, как экземпляр data class может чо-то там сам решать, ну разве что только если у него будут в комплекте какие-то ACL, которые что-то там ограничат. В любом случае — он эе откуда-то взялся, его кто-то создал, и ссылку на него куда-то передал. Или вместе с понятием «владение» или просто, расрашил (полайкал, ретвитнул :)
И вот этот data class — он сам по себе протекать не может. В него кто-то может че-то напихивать — да. Но ровно так-же, кто-то другой, должен уметь проверить, че там напихали, и лишние удалить.
А код, который со всем этим работает, по-любому нужно уметь останавливать, хотя бы для того, что бы обновить на новую-свежую версию, которая «уже не протекает»
Я еще в школу ходил, игрушки были еще 2D, но люди уже понимали, что «отрисовывать» то, что не видно — нет никакого смысла. Можно сказать не «реже», а «вообще не нужно».
Пытаясь вернуться в контекст статьи — если в коллекции «поле» 30000 объектов, то перед отрисовкой нужно сделать viewField.filter(isVisible()), вдруг в итоге останется вообще один объект, потому что игрок носом уперся в стену.
вы правы, вот только «рано остановились», нужно довести эту логику до денег.
Денег, которые принесут эти 100 пользователей, и денег, которые нужно будет отдать программистам и за аренду сервера. К сожалению, на шаге «перевод в деньги», очень многие обламываются, а он самый важный показатель. Потому, что серверные мощности со временем дешевеют, а программисты — дорожают.
А практика (увы, подкрепить цифрами не могу) написания кода показывает, что функциональный оптимизировать легче. Он гораздо более наглядно передает суть «что тут вообще происходит», чем императивная лапша.
Довольно часто из лаконичности и краткости следует понятность.
Это я не пытаюсь возразить вам, даже наоборот, поддерживаю — нужно очень четко решать и договариваться где когда и зачем. Потому, что вот эти самые «лаконичность краткость понятность» — очень субъективные штуки.
Приведу простой пример, который (надеюсь) будет понятен всем:
Приложение, написанное на Java/C#/несуть. Допустим, какая-то обработка данных, которые откуда-то поступают, их как-то обрабатывают, результат обработки — куда-то складывают. Для обработки очередной порции данных, запускают 1-2, да хоть 100500 нитей, из которых в каждый момент времени может получаться довольно замысловатый граф обработки. Но по мере завершения работы, нити останавливают.
До этого места всё понятно?
Теперь, представьте, вот это гипотетическое приложение — операционка. А одна гипотетическая нить в нем — приложение пользователя. Пользователю прислали документ, он его открыл, что-то в нём исправил сохранил и окно закрыл.
Значит ли, что пользователь сделал Uninstall того куска кода, который отрисовывает окно, документ в нём, обрабатывает события итд? Очевидно — нет. Как был в бинарнике приложения кусок кода — так он там и остался. Должен ли быть «запущен» тот кусок кода или нужно «останавливать нить»?
Не знаю, но не вижу никаких проблем поступать хоть так, хоть эдак.
Согласно персистентной модели, приложение запускается один раз и на всю жизнь.
Тут нужно обратить внимание, что никто не запрещает приложению завершать работу.
«Вся жизнь» — то время, которое необходимо приложению, что бы выполнить полезную для пользователя работу.
Когда я еще был маленьким, и ходил в школу, довелось общаться с человеком, который на память помнил команды 8080, и в мониторе РК «Специалист», сразу программы hex-кодами писал.
Потом я вырос, и когда в универе учиться уже стало скучно, работал. Люди которые занимались железом в нашем проекте, не просто помнили на память коды 8051, но могли просто в уме прикинуть, нужно РФ'ку стирать, что бы поправить условие перехода, или можно поверх в программаторе закатать этот самый исправленный байт (я же не путаю, РФ'ки по-байтно шились?)
Но, простите, это всё было в прошлом веке. Впрочем, уже тогда, эти люди рассказывали, что с точки зрения стройности система команд DEC гораздо приятнее. И в современных микроконтроллерах (современных по тем меркам, 90-ые), тоже бывает гораздо удобнее/интереснее чем x86
А сейчас вообще уже 2017 год, кому какая разница, какая там система команд, кроме производителей компиляторов, и людей, у которых очень жесткий реалтайм, и очень ограниченный бюджет (или миллионные партии), что они считают каждую сотую копейки, каждый тик процессора, лишний корпус, и так далее.
И еще мне что-то подсказывает, что в таких крайних условиях, железо с x86 внутри пролетает. по другим требованиям.
Я уж не помню, сдержал ли я себя от написания комментария тогда на Хабре под анонсом Кварка (кажется) или нет, и сейчас искать лень. Но тогда ценник и сроки доступности мне показались очень странными.
Мне, как человеку, у которого есть всякие ардуины, биглебоны, esp* и прочие штуки, которые покупаются «на посмотреть, чего оно, куда его можно».
А отношение производителей (это те, кто уже посмотрел, и решил — что ага, интересно), вон в комментариях написали — там сразу хочется каких-то гарантий на 5-10 лет, что это не умрет.
И как человек, который принимал некое участие в разработке софта для embedded решения на очень интересной архитектуре, а потом уже как члеовек, который эти решения внедряет, очень хорошо их понимаю. В какой-то момент производитель той самой интересной архитектуры, сказал «простите, но мы больше такие платы выпускать не будем. Но вот, у нас есть партнеры, которые закупают пачками эти микропроцессоры, и делают почти такие-же, почти за те же деньги». Коллеги-разработчики, вдохнули воздух, и начали миграцию. Потом было еще несколько миграций… Да, это всё на отрезке лет 15-16. И всё это совсем не радовало.
То самое преимущество, за которое когда-то была выбрана платформа, стало «убывать» с каждой миграцией.
К чему это я рассказываю? Не знаю, на что рассчитывал Интел при запусках/анонсах, но никаких преимуществ лично я не заметил даже в том самом минимальном количестве, что бы просто в своих руках покрутить.
потратил минуту на сайте Quest Software не нашел даже раздел где брать на посмотреть.
Только маркетинговое бла-бла-бла, как круто они умеют всё мониторить.
конечно, всякие очки начнут иметь смысл как только будет глобальный рейтинг.
Думаю, по ходу дела, еще может всякое напридумываться, по каким критериям ранжировать.
Поэтому общая идея такая — все метрики по ходу игры куда-то складывать.
еще навскидку
— количество таймаутов
— сколько раз сдавался
— сколько ходов сделал до выигрыша
— сколько ходов «продержался», максимум, минимум, среднее
в общем, казалось бы, такая простая игра, но перевод её в многопользовательскую открывает бездны :)
Одна беда со всем этим — достаточно просто пишутся боты, да и математика для бота не сильно сложная. По ходу игру совсем примитивная-локальная, в «сложных» — посчитать вероятности…
В любом случае — спасибо, вспомнил юность, залип на час
Но вы опять по какую-то ОС — забудьте. В случае Фантома, если довольно грубо, то ОС — это современная программа. Программы Фантома — нити внутри современной программы. Нить возвращает программе стек? Остальные все ресурсы во владении самой программы? Вот так и будет в Фантоме. Нет никакого ни юзер- ни другого спейса. Прослойка VM и сразу железо.
Если вы сейчас в программе запускаете нить, что бы она сделала для вас полезную работу, нить в ходе этого нажрала гигабайты памяти, что происходит?
Либо, ссылка на эти гигабайты осталась в стеке, после освобождения стека протухла, и гигабайты подберет сборщик мусора, или нить отдала «полезное нажратое» вам в качестве результата — «на, слушай, сам выкинь, да!» (анекдот про бумеранг)
прошу еще раз посмотреть на аналогию. В случае фантома «закрытие приложения» — это суть «завершилась нить» в тех приложениях которые сейчас.
Куда переносятся какие ресурсы из нити? Вот будет всё то же самое.
Сейчас, например у jre память можно жестко ограничить при запуске, и процесс внутри, будет получать отлупы.
Всё ровно то же будет происходить в Фантоме, никакой качественной разницы не будет.
То, что условно памяти станет несколько ТБ, я заметной разницей не считаю ;)
Попробую совсем тезисов: архитектура фантома не дает каких-то там заметных преимуществ в автоматическом управлении ресурсами. Наличие мозга у программиста всё еще требуется, аккуратность работы — всё еще важна важна. В то же время, каких-то заметных недостатков тоже нет — если программист с мозгом и аккуратен, на него не свалятся какие-то внезапные проблемы.
Если утечка не на виду, может это и не утечка вовсе?
Не думаю, что есть какая-то заметная разница, в сравнении с обычным приложением, если не рассматривать связи этого приложения и его окружения.
Хотя, за счет более стройной архитектуры в целом, может оказаться, что инструментарий для мониторинга/анализа и может быть даже автоматических каких-то реакций в таких ситуациях, будет проще реализовать.
Возьмем, например, какой-нибудь BinaryTree. Это будет data class? Оно сможет протекать? Там будут виртуальные методы? Или, с другой стороны — нужно ли требовать где-то у таких классов отсутствие виртуальных методов?
«Нет сериализации».
Те же самые String и BinaryTree — их совсем нельзя будет сериализовать? Кто-то запретит мне из них сделать json или xml? Так и представляю, приходит dz и ufm, и грозят пальцем «ай-ай-ай, не сериализуй! Грешно! Будешь всю жизнь в SOAP долбиться!»
Что сейчас происходит, если программист забывает какую-то ссылку внутри?
Скорее всего в случае Фантома будет ровно то же самое. И просто «добавить персистентность» и «избавить от сериализации» на уровне системы, не сделает автоматически всех программистов умными.
Как и «добавь вывод типов» — тоже. Как и «добавь зависимые типы» — тоже не сделает.
Инструменты со строгой типизацией помогают человеку меньше ошибаться.
Вывод типов компилятором — помогают меньше писать руками.
Зависимые типы — позволяют исключить еще целый класс ошибок, и еще меньше писать руками. Чем больше вы добавляете мозгов/математики инструменту на уровне концепции, чем больше инструмент может проверить, по сути сужая область в которой программист может нафигачить — тем меньше ошибок.
Но персистентность — это ведь ортогональная штука ко всему этому. Отсутствие сериализации — это просто выкидывание целого класса тупой работы. Это уменьшает количество ошибок, но не концептуально, а рутинно — меньше работы — меньше ошибок.
Да и потом, давно уже всю сериализацию генерируют, не?
javaxb, protobuf, и вот это всё.
Но если у меня есть «документ», как суть, как понятие, он же как-то будет в системе представлен? Будет это data class, или будет это вполне себе smart class — у которого будет внутри какого-то метода while true, но не такой явный, который моймает компилятор, а заумный?
Если человек хочет прострелить себе ногу — он её прострелит.
Могу только повторить тот пример, с которого начал — представьте сейчас любую программу на managed платформе, у которой внутри запускаются отдельные потоки. Вот это примерно то же самое. Просто у современных программ есть какие-то отдельные концепции типа «файл», «база данных», «сеть», а Фантому эти концепции ненужны. И просто не нужно будет мне из какого-то BinaryTree, делать BinaryTreeJson, но не потому, что dz меня предаст анафеме, а просто с точки зрения здравого смысла — зачем заниматьая какой-то фигнёй, если можно прям сам объект отдать, и там всё правильно поймут?
Не понимаю, как экземпляр data class может чо-то там сам решать, ну разве что только если у него будут в комплекте какие-то ACL, которые что-то там ограничат. В любом случае — он эе откуда-то взялся, его кто-то создал, и ссылку на него куда-то передал. Или вместе с понятием «владение» или просто, расрашил (полайкал, ретвитнул :)
И вот этот data class — он сам по себе протекать не может. В него кто-то может че-то напихивать — да. Но ровно так-же, кто-то другой, должен уметь проверить, че там напихали, и лишние удалить.
А код, который со всем этим работает, по-любому нужно уметь останавливать, хотя бы для того, что бы обновить на новую-свежую версию, которая «уже не протекает»
Пытаясь вернуться в контекст статьи — если в коллекции «поле» 30000 объектов, то перед отрисовкой нужно сделать viewField.filter(isVisible()), вдруг в итоге останется вообще один объект, потому что игрок носом уперся в стену.
Денег, которые принесут эти 100 пользователей, и денег, которые нужно будет отдать программистам и за аренду сервера. К сожалению, на шаге «перевод в деньги», очень многие обламываются, а он самый важный показатель. Потому, что серверные мощности со временем дешевеют, а программисты — дорожают.
А практика (увы, подкрепить цифрами не могу) написания кода показывает, что функциональный оптимизировать легче. Он гораздо более наглядно передает суть «что тут вообще происходит», чем императивная лапша.
Это я не пытаюсь возразить вам, даже наоборот, поддерживаю — нужно очень четко решать и договариваться где когда и зачем. Потому, что вот эти самые «лаконичность краткость понятность» — очень субъективные штуки.
Это как-то очень странно звучит.
Приведу простой пример, который (надеюсь) будет понятен всем:
Приложение, написанное на Java/C#/несуть. Допустим, какая-то обработка данных, которые откуда-то поступают, их как-то обрабатывают, результат обработки — куда-то складывают. Для обработки очередной порции данных, запускают 1-2, да хоть 100500 нитей, из которых в каждый момент времени может получаться довольно замысловатый граф обработки. Но по мере завершения работы, нити останавливают.
До этого места всё понятно?
Теперь, представьте, вот это гипотетическое приложение — операционка. А одна гипотетическая нить в нем — приложение пользователя. Пользователю прислали документ, он его открыл, что-то в нём исправил
сохранили окно закрыл.Значит ли, что пользователь сделал Uninstall того куска кода, который отрисовывает окно, документ в нём, обрабатывает события итд? Очевидно — нет. Как был в бинарнике приложения кусок кода — так он там и остался. Должен ли быть «запущен» тот кусок кода или нужно «останавливать нить»?
Не знаю, но не вижу никаких проблем поступать хоть так, хоть эдак.
Тут нужно обратить внимание, что никто не запрещает приложению завершать работу.
«Вся жизнь» — то время, которое необходимо приложению, что бы выполнить полезную для пользователя работу.
Когда я еще был маленьким, и ходил в школу, довелось общаться с человеком, который на память помнил команды 8080, и в мониторе РК «Специалист», сразу программы hex-кодами писал.
Потом я вырос, и когда в универе учиться уже стало скучно, работал. Люди которые занимались железом в нашем проекте, не просто помнили на память коды 8051, но могли просто в уме прикинуть, нужно РФ'ку стирать, что бы поправить условие перехода, или можно поверх в программаторе закатать этот самый исправленный байт (я же не путаю, РФ'ки по-байтно шились?)
Но, простите, это всё было в прошлом веке. Впрочем, уже тогда, эти люди рассказывали, что с точки зрения стройности система команд DEC гораздо приятнее. И в современных микроконтроллерах (современных по тем меркам, 90-ые), тоже бывает гораздо удобнее/интереснее чем x86
А сейчас вообще уже 2017 год, кому какая разница, какая там система команд, кроме производителей компиляторов, и людей, у которых очень жесткий реалтайм, и очень ограниченный бюджет (или миллионные партии), что они считают каждую сотую копейки, каждый тик процессора, лишний корпус, и так далее.
И еще мне что-то подсказывает, что в таких крайних условиях, железо с x86 внутри пролетает. по другим требованиям.
Я уж не помню, сдержал ли я себя от написания комментария тогда на Хабре под анонсом Кварка (кажется) или нет, и сейчас искать лень. Но тогда ценник и сроки доступности мне показались очень странными.
Мне, как человеку, у которого есть всякие ардуины, биглебоны, esp* и прочие штуки, которые покупаются «на посмотреть, чего оно, куда его можно».
А отношение производителей (это те, кто уже посмотрел, и решил — что ага, интересно), вон в комментариях написали — там сразу хочется каких-то гарантий на 5-10 лет, что это не умрет.
И как человек, который принимал некое участие в разработке софта для embedded решения на очень интересной архитектуре, а потом уже как члеовек, который эти решения внедряет, очень хорошо их понимаю. В какой-то момент производитель той самой интересной архитектуры, сказал «простите, но мы больше такие платы выпускать не будем. Но вот, у нас есть партнеры, которые закупают пачками эти микропроцессоры, и делают почти такие-же, почти за те же деньги». Коллеги-разработчики, вдохнули воздух, и начали миграцию. Потом было еще несколько миграций… Да, это всё на отрезке лет 15-16. И всё это совсем не радовало.
То самое преимущество, за которое когда-то была выбрана платформа, стало «убывать» с каждой миграцией.
К чему это я рассказываю? Не знаю, на что рассчитывал Интел при запусках/анонсах, но никаких преимуществ лично я не заметил даже в том самом минимальном количестве, что бы просто в своих руках покрутить.
Только маркетинговое бла-бла-бла, как круто они умеют всё мониторить.
А сейчас еще модно нейронки тренировать, не удивлюсь если кто-то решит сделать бота на модных технологиях :)
Думаю, по ходу дела, еще может всякое напридумываться, по каким критериям ранжировать.
Поэтому общая идея такая — все метрики по ходу игры куда-то складывать.
еще навскидку
— количество таймаутов
— сколько раз сдавался
— сколько ходов сделал до выигрыша
— сколько ходов «продержался», максимум, минимум, среднее
в общем, казалось бы, такая простая игра, но перевод её в многопользовательскую открывает бездны :)
Одна беда со всем этим — достаточно просто пишутся боты, да и математика для бота не сильно сложная. По ходу игру совсем примитивная-локальная, в «сложных» — посчитать вероятности…
В любом случае — спасибо, вспомнил юность, залип на час
— а если сделать командную… :))))