Неоригинал брать не рискнул, и наверное не рискну. Если сравнить со сменными соплами эндера, которые при засоре даже выкинуть не жалко, то разница в цене ощутима.
У неоригиналов заявлены сменные сопла (в комплекте идут) - это как раз то, что в эндере выкинуть не жалко. Например, вот
особенно в свете того как быстро словил засор
Я так убил комплектный закаленный 0.6-хотенд за пару дней на филаменте, который родной 0.4-хотенд прекрасно переваривал несколько месяцев :)
На алике сейчас есть уже 3 поколение кастомных хотендов:
"проводки на соплях" - ужасное подключение, особенно на adv5pro, где корпус закрыт и фиг подлезешь сбоку. Работают 50 на 50 - один экземпляр показал отрицательную температуру сопла, второй нормально отработал месяц, пока ехали оригиналы. На распродаже можно было найти по 700-800 руб (цены упали после появления новых поколений сопел).
"красные" хотенды - провода разъема уже не соплями висят, а упакованы в пластик красного цвета по аналогии с корпусом оригинального хотенда. На распродаже стоили порядка 1100 руб.
"xxx Phaetus Conch Hotend", где xxx - обычно имя магазина. Обещают объемный поток больше оригинального, закаленные сопла. Цена - больше оригинальных, на распродаже можно найти в районе 2000 руб. Пару месяцев назад самого ходового варианта с 0.4-соплом было просто нереально купить - все выбрали подчистую.
Сейчас оригинальные хотенды подешевели и стоят в районе 1500-1600 руб (в начале года были больше 2к руб), поэтому сторонние стали не такими интересными, только если смотреть варианты с закаленными соплами на убой абразивами.
Так опенсорс же, форкаешь и дописываешь то, что тебе нужно, а потом тебя форкают дальше и перепиливают под себя. Ограниченный кодоген в виде патча на ядро был в классике и то только для тех, кому 6 компонентов в фильтре было мало. Т.е кодоген по сути для исправлений в ядре, а не для пользовательского кода. Такое количество компонентов не совсем нормально и должно быть поводом задуматься о пересмотре компоновки данных, но механизм расширения был дан. В лайте уже не надо было патчить ядро и можно было собирать фильтры любой сложности на стороне клиента без изменений в ядре.
Про идеи организации можно почитать вот тут https://habr.com/ru/articles/742376/ Какие-то административные договоренности по взаимодействию нужны, да. Еще не стоит мельчить с компонентами, иначе это на самом деле может превратиться в неуправляемое месиво, когда никто не будет знать как и что должно работать. Функционал стоит делить на "фичи", когда есть блок компонентов, управляемых блоком систем, а снаружи к ним идет обращение через создание сущностей-событий или навешивание маркеров-событий, а дальше они сами работают. Когда логика разбивается на подобные логические блоки - управлять ей становится проще. Это все решается административными мерами - какими-то правилами, которыми должны руководствоваться все со-командники, т.к строгих правил не существует из-за гибкости самого ECS-подхода (одни правила подходят на одном проекте, другие на другом).
Абсолютно нет, Entitas построен исключительно на классах, про структуры автор начал заговаривать в рамках разработки нового фреймворка с атомарными компонентами, где все разбивалось вплоть до отдельных значений, но это было в 2020 году и все благополучно умерло.
Я свои самописные поделия начал делать как раз в конце 2017 как альтернативу платному кодогену Entitas, который проблемно ставился на macos. В начале 2018 была написана реализация на классах, которая обогнала или показала такую же производительность как Entitias, но без кодогена - задача была выполнена и появился LeoECS Classic, про Entitas больше не вспоминал. В 2019 эта реализация переехала на структуры и скорость работы еще возросла - Entitas все это время был в коме и не развивался.
Вы не правы в том, что производительность не ассоциирована с ECS
Так я про то и написал, что одни понесли, а другие охотно поверили. Производительность абсолютно никак не связана с ECS, а связана с логикой обработки данных - скорость в итоге может быть как лучше, так и хуже.
Практически все ее упоминания или реализации на этом сосредоточены и так было с момента ее создания.
Абсолютно ничем не подтвержденное высказывание. ECS впервые как архитектурный паттерн появился в dungeon siege, а это 2002 год. Ни про какую скорость разговора не было, была попытка управлять взрывным ростом механик и поддерживать их в рабочем состоянии.
Следующая известная веха - это GDC 2015, когда авторы entitas начали активно продвигать этот паттерн и конкретно свою реализацию в рамках юнити. Ни слова про производительность не было ни тогда, ни на следующем GDC2016, где опять же было выступление про удобство декомпозиции, добавления и удаления игромеханик без ломания остального кода.
Юнитехи со своим "performance by default" заявились на ECS-сцене только в 2017 году и то не смогли ничего работающего показать раньше середины 2018, причем этим пользоваться было нельзя, а производительность была ужасна.
Безусловно важным фактором является и разделение логики и данных - и, на самом деле, я критикую это не в последнюю очередь как способ создать реально сложные и плохо обслуживаемые решения
Плохо обслуживаемые решения можно создать на чем-угодно и ECS тут никак не помогает и не мешает.
ООП буквально придуман для того, чтобы собрать это вместе по хорошей причине - локальность данных и кода
Внезапно, от локальности и когерентности данных в памяти/кеше и производительности по этой причине перешли к локальности данных по отношению к логике. В чем тогда был смысл рассказывать про производительность? Экземпляры ООП классов в общем случае всегда размазаны по памяти случайным образом и никогда не смогут догнать на тех же линейных переборах DOD-подход, когда данные лежат плотно и подряд (и нет, это опять сравнение не ECS с ООП, а DOD с ООП).
Я бы не сказал, что сложные задачи, где нужны гибкие отношения многих ко многим сильно упрощаются в ecs
Тут какая штука - с ецс ты просто садишься и пишешь код как получится, на ходу подправляя неудобные места, тебе просто не нужно иметь в голове какую-то стройную архитектуру, а только набор идей/правил по взаимодействию различных подсистем. ООП-шники этому не верят и скорее всего именно отсутствие строгой архитектуры их и пугает в ECS, что все настолько гибко, что может быть изменено в произвольном направлении и относительно без боли.
Херня написана - хорошую работу по промыванию мозгов проделали маркетологи юнитехов, которые рассказали, что ECS это про скорость и приравняли его к DOD (https://en.wikipedia.org/wiki/Data-oriented_design). Нет, ECS - это не про скорость, про скорость - это DOD. ECS не накладывает никаких требований и ограничений на то, как будут реализованы кишки, удобно ли для кеша разложены данные и будет ли оно максимально быстро обрабатываться - следование DOD является особенностью конкретной реализации. ECS - это архитектура, причем скорее архитектурный паттерн, не имеющей фиксированной реализации. Если бы оно было про скорость, то Entitas (https://github.com/sschmid/Entitas) никогда бы не появился на свет и не был бы до сих пор самым быстро растущим по популярности ECS-фреймворком (сейчас уже по 1к звезд в год) с 2015 года, ведь он весь на классах, через интерфейсы, на реактивных системах и местами постоянно аллоцирует память, про производительность вообще не стоит заводить разговор - это самая медленная реализация из всех существующих на сегодня. Смысл ECS не в скорости, а в гибкости и простоте рефакторинга. Если системы распилены на независимые части (features, "фичи"), то их можно наращивать и выпиливать почти безболезненно, пользуясь понятием "composition over inheritance". Берут его именно по этой причине, когда ТЗ или не готово, или меняется каждую неделю - с ECS рефакторинг проходит менее болезненно, чем в красиво выстроенной абстракции ООП-типов. Да, в ECS неприятно делать обработку любых иерархических данных типа графов, работы с UI и т.п, но не нужно все тащить в ECS, оно прекрасно живет рядом с ООП-сервисами, реализующими проблемные места. Непонятно, почему после миллиона статей про ECS продолжают приравнивать ECS к DOD или, что еще хуже, к UECS/DOTS, хотя это всего лишь частный случай реализации.
"Работа с референсами с обводкой" - тут имелась ввиду работа в фотошопе. Krita - это опенсорсная замена фотошопу в задачах, перечисленных в статье. Так же она может являться заменой Aseprite после настройки.
Пул не подразумевает выделение памяти при создании новых экземпляров (не его задача), он подразумевает выделение памяти под хранение ссылок на отработанные экземпляры для дальнейшего их переиспользования, что слегка отличается от арены как аллокатора памяти.
Это про пул экземпляров одного типа, не более того. Арена подразумевает выделение большого непрерывного блока памяти, внутри которого уже самостоятельно выделять память под экземпляры разных типов, а освобождать не по одному экземпляру, а память арены целиком.
Перечень вредных советов какой-то. Горотины не бесплатны сами по себе + синхронизация может съесть все выигранное время и даже больше + нужна блокировка множественного доступа к ресурсам. Применять их стоит только осознанно и только в подготовленном окружении.
При возвращении указателя, объявлять его при создании переменной
Субъективщина же, скорость может поменяться в худшую сторону внутри метода, если анализатор увидит, что указатель может стать nil.
Используйте for-loop
Тут вообще хрень написана - тесты надо проводить на реальных примерах, а не на пустых циклах. Самый простой случай: обращение по индексу в слайс - for-loop будет медленнее из-за постоянного bounds-check если не сделать дополнительные проверки внутри тела цикла, что приведет к замедлению по отношению к range-loop. В случае range-loop компилятор понимает, что нарушения границ быть не может и не вставляет эти проверки. Сравнять скорость можно только используя флаг компиляции -gcflags=all="-B", отключающий все проверки на границы.
Есть только 3 рациональных варианта использования for-loop:
нужно идти с шагом, отличным от 1.
реверсивный цикл, это можно будет обойти через range-over-func в 1.23.
если коллекция состоит из жирных объектов, которые range-loop будет принудительно копировать, то for-loop становится выгоднее, если ползать в слайс через указатели.
Он не спал, он активно хайпожорил, что это все говно и никому не нужно, покупайте мои ооп-курсы. Всех, кто приходил к нему в тележковый чатик и случайно упоминал запретное слово "ECS" - сначала обсирал, а потом просто банил. Почему мне в принципе смешно от ситуации - я автор этого фрейма, который он 4 года назад назвал поделием школьника, а теперь продает на нем курсы, хотя он уже устарел и не поддерживается. :)
вот только стоимость далеко не та же :)
он на текущей распродаже стоит дороже - 27к руб, без распродаж - 23к в среднем: https://aliexpress.ru/item/1005008094126761.html
да, 256х256 против 220х220 у FF 5x. правда цена у FF в 2-3 раза ниже, в зависимости от маркетплейса.
Надо сравнивать не с bambu p1s, а с flashforge 5x с теми же 4 цветами, и теми же схожими ттх, который к тому же продается уже полгода как.
Вот оригинал за 1700
Вот оригинал за 1800
У неоригиналов заявлены сменные сопла (в комплекте идут) - это как раз то, что в эндере выкинуть не жалко. Например, вот
Я так убил комплектный закаленный 0.6-хотенд за пару дней на филаменте, который родной 0.4-хотенд прекрасно переваривал несколько месяцев :)
На алике сейчас есть уже 3 поколение кастомных хотендов:
"проводки на соплях" - ужасное подключение, особенно на adv5pro, где корпус закрыт и фиг подлезешь сбоку. Работают 50 на 50 - один экземпляр показал отрицательную температуру сопла, второй нормально отработал месяц, пока ехали оригиналы. На распродаже можно было найти по 700-800 руб (цены упали после появления новых поколений сопел).
"красные" хотенды - провода разъема уже не соплями висят, а упакованы в пластик красного цвета по аналогии с корпусом оригинального хотенда. На распродаже стоили порядка 1100 руб.
"xxx Phaetus Conch Hotend", где xxx - обычно имя магазина. Обещают объемный поток больше оригинального, закаленные сопла. Цена - больше оригинальных, на распродаже можно найти в районе 2000 руб. Пару месяцев назад самого ходового варианта с 0.4-соплом было просто нереально купить - все выбрали подчистую.
Сейчас оригинальные хотенды подешевели и стоят в районе 1500-1600 руб (в начале года были больше 2к руб), поэтому сторонние стали не такими интересными, только если смотреть варианты с закаленными соплами на убой абразивами.
https://github.com/mattermost
Так опенсорс же, форкаешь и дописываешь то, что тебе нужно, а потом тебя форкают дальше и перепиливают под себя. Ограниченный кодоген в виде патча на ядро был в классике и то только для тех, кому 6 компонентов в фильтре было мало. Т.е кодоген по сути для исправлений в ядре, а не для пользовательского кода. Такое количество компонентов не совсем нормально и должно быть поводом задуматься о пересмотре компоновки данных, но механизм расширения был дан. В лайте уже не надо было патчить ядро и можно было собирать фильтры любой сложности на стороне клиента без изменений в ядре.
В LeoECS нет кодогенерации, ответственно заявляю как автор.
Про идеи организации можно почитать вот тут https://habr.com/ru/articles/742376/
Какие-то административные договоренности по взаимодействию нужны, да. Еще не стоит мельчить с компонентами, иначе это на самом деле может превратиться в неуправляемое месиво, когда никто не будет знать как и что должно работать. Функционал стоит делить на "фичи", когда есть блок компонентов, управляемых блоком систем, а снаружи к ним идет обращение через создание сущностей-событий или навешивание маркеров-событий, а дальше они сами работают. Когда логика разбивается на подобные логические блоки - управлять ей становится проще. Это все решается административными мерами - какими-то правилами, которыми должны руководствоваться все со-командники, т.к строгих правил не существует из-за гибкости самого ECS-подхода (одни правила подходят на одном проекте, другие на другом).
Абсолютно нет, Entitas построен исключительно на классах, про структуры автор начал заговаривать в рамках разработки нового фреймворка с атомарными компонентами, где все разбивалось вплоть до отдельных значений, но это было в 2020 году и все благополучно умерло.
Я свои самописные поделия начал делать как раз в конце 2017 как альтернативу платному кодогену Entitas, который проблемно ставился на macos. В начале 2018 была написана реализация на классах, которая обогнала или показала такую же производительность как Entitias, но без кодогена - задача была выполнена и появился LeoECS Classic, про Entitas больше не вспоминал. В 2019 эта реализация переехала на структуры и скорость работы еще возросла - Entitas все это время был в коме и не развивался.
Так я про то и написал, что одни понесли, а другие охотно поверили. Производительность абсолютно никак не связана с ECS, а связана с логикой обработки данных - скорость в итоге может быть как лучше, так и хуже.
Абсолютно ничем не подтвержденное высказывание. ECS впервые как архитектурный паттерн появился в dungeon siege, а это 2002 год. Ни про какую скорость разговора не было, была попытка управлять взрывным ростом механик и поддерживать их в рабочем состоянии.
Следующая известная веха - это GDC 2015, когда авторы entitas начали активно продвигать этот паттерн и конкретно свою реализацию в рамках юнити. Ни слова про производительность не было ни тогда, ни на следующем GDC2016, где опять же было выступление про удобство декомпозиции, добавления и удаления игромеханик без ломания остального кода.
Юнитехи со своим "performance by default" заявились на ECS-сцене только в 2017 году и то не смогли ничего работающего показать раньше середины 2018, причем этим пользоваться было нельзя, а производительность была ужасна.
Плохо обслуживаемые решения можно создать на чем-угодно и ECS тут никак не помогает и не мешает.
Внезапно, от локальности и когерентности данных в памяти/кеше и производительности по этой причине перешли к локальности данных по отношению к логике. В чем тогда был смысл рассказывать про производительность? Экземпляры ООП классов в общем случае всегда размазаны по памяти случайным образом и никогда не смогут догнать на тех же линейных переборах DOD-подход, когда данные лежат плотно и подряд (и нет, это опять сравнение не ECS с ООП, а DOD с ООП).
Тут какая штука - с ецс ты просто садишься и пишешь код как получится, на ходу подправляя неудобные места, тебе просто не нужно иметь в голове какую-то стройную архитектуру, а только набор идей/правил по взаимодействию различных подсистем. ООП-шники этому не верят и скорее всего именно отсутствие строгой архитектуры их и пугает в ECS, что все настолько гибко, что может быть изменено в произвольном направлении и относительно без боли.
Херня написана - хорошую работу по промыванию мозгов проделали маркетологи юнитехов, которые рассказали, что ECS это про скорость и приравняли его к DOD (https://en.wikipedia.org/wiki/Data-oriented_design). Нет, ECS - это не про скорость, про скорость - это DOD. ECS не накладывает никаких требований и ограничений на то, как будут реализованы кишки, удобно ли для кеша разложены данные и будет ли оно максимально быстро обрабатываться - следование DOD является особенностью конкретной реализации. ECS - это архитектура, причем скорее архитектурный паттерн, не имеющей фиксированной реализации. Если бы оно было про скорость, то Entitas (https://github.com/sschmid/Entitas) никогда бы не появился на свет и не был бы до сих пор самым быстро растущим по популярности ECS-фреймворком (сейчас уже по 1к звезд в год) с 2015 года, ведь он весь на классах, через интерфейсы, на реактивных системах и местами постоянно аллоцирует память, про производительность вообще не стоит заводить разговор - это самая медленная реализация из всех существующих на сегодня.
Смысл ECS не в скорости, а в гибкости и простоте рефакторинга. Если системы распилены на независимые части (features, "фичи"), то их можно наращивать и выпиливать почти безболезненно, пользуясь понятием "composition over inheritance". Берут его именно по этой причине, когда ТЗ или не готово, или меняется каждую неделю - с ECS рефакторинг проходит менее болезненно, чем в красиво выстроенной абстракции ООП-типов.
Да, в ECS неприятно делать обработку любых иерархических данных типа графов, работы с UI и т.п, но не нужно все тащить в ECS, оно прекрасно живет рядом с ООП-сервисами, реализующими проблемные места.
Непонятно, почему после миллиона статей про ECS продолжают приравнивать ECS к DOD или, что еще хуже, к UECS/DOTS, хотя это всего лишь частный случай реализации.
"Работа с референсами с обводкой" - тут имелась ввиду работа в фотошопе. Krita - это опенсорсная замена фотошопу в задачах, перечисленных в статье. Так же она может являться заменой Aseprite после настройки.
Почему не krita - и для работы с референсами с обводкой и для пиксельарта?
Пул не подразумевает выделение памяти при создании новых экземпляров (не его задача), он подразумевает выделение памяти под хранение ссылок на отработанные экземпляры для дальнейшего их переиспользования, что слегка отличается от арены как аллокатора памяти.
Это про пул экземпляров одного типа, не более того. Арена подразумевает выделение большого непрерывного блока памяти, внутри которого уже самостоятельно выделять память под экземпляры разных типов, а освобождать не по одному экземпляру, а память арены целиком.
Перечень вредных советов какой-то. Горотины не бесплатны сами по себе + синхронизация может съесть все выигранное время и даже больше + нужна блокировка множественного доступа к ресурсам. Применять их стоит только осознанно и только в подготовленном окружении.
Субъективщина же, скорость может поменяться в худшую сторону внутри метода, если анализатор увидит, что указатель может стать nil.
Тут вообще хрень написана - тесты надо проводить на реальных примерах, а не на пустых циклах. Самый простой случай: обращение по индексу в слайс - for-loop будет медленнее из-за постоянного bounds-check если не сделать дополнительные проверки внутри тела цикла, что приведет к замедлению по отношению к range-loop. В случае range-loop компилятор понимает, что нарушения границ быть не может и не вставляет эти проверки. Сравнять скорость можно только используя флаг компиляции
-gcflags=all="-B", отключающий все проверки на границы.Есть только 3 рациональных варианта использования for-loop:
нужно идти с шагом, отличным от 1.
реверсивный цикл, это можно будет обойти через range-over-func в 1.23.
если коллекция состоит из жирных объектов, которые range-loop будет принудительно копировать, то for-loop становится выгоднее, если ползать в слайс через указатели.
Он не спал, он активно хайпожорил, что это все говно и никому не нужно, покупайте мои ооп-курсы. Всех, кто приходил к нему в тележковый чатик и случайно упоминал запретное слово "ECS" - сначала обсирал, а потом просто банил. Почему мне в принципе смешно от ситуации - я автор этого фрейма, который он 4 года назад назвал поделием школьника, а теперь продает на нем курсы, хотя он уже устарел и не поддерживается. :)