ну если мне память не изменяет, они просто все контролы на opengl запилили. Почти как это делают браузеры со своим html+css. Ну или вы можете сделать на webgl ;)
Все программы бы работали сильно быстрее если сделать у cpu условные 10ггц.
нет. Еще раз — проблема не в CPU у 90% приложений. Проблема в работе с памятью.
Вот вы PHP разработчик, да? Помните выход php7? Мол "теперь в 2-3 раза быстрее". Вы же понимаете что это "быстрее" было не потому что у вас вдруг дополнительно частот стало больше, а потому что сильно оптимизировали работу с памятью, повысили локальность данных, уменьшили количество кэш мисов процессора.
А потому ваш слэк или шторм будет педалить одинаково что на 5Ghz что на 10Ghz. А вот скажем рендринг картинки в каком vray будет да быстрее порядочно.
Вот reindex проекта, использование диска было по-минимуму.
А теперь попробуйте сделать так — понизьте частоты вашего процессора и повторите эксперемент. И попробуем найти корреляцию суммарного времени построения индекса от частот CPU.
Это заметно когда даже 8700k 5.0ггц открывает программы с небольшим пролагом.
и пролаг этот связан с тем что ваш процессор ждет пока данные загрузятся (из кэша, потом из памяти при кэш мисе, и если что еще на файловую систему сгонять).
Ту же phpstorm он открывает 5-10 секунд.
И как вы думаете, какой процент этого времени уходит на ожидание I/O? Или вы думаете оно там яростно что-то считает?
один из быстрейших ssd
Даже если поставить ramdisk то все равно не будет нужной скорости.
Рзработчики игр, например, все больше уходят в многопоточность
Ну вы сравнили, объемы вычислений игрушки какой и объем вычислений требуемый тому же шторму.
Шторм упирается в I/O. Да, есть нюансы, типа специализированный софт для симуляций, визуализации и т.д. который можно развивать только за счет параллелизма вычислений, но это опять же маленький процент прикладного софта.
я сейчас смотрю на то сколько жрет IDEA и VSCode на одном и том же проекте (и да я понимаю что IDEA может делать много больше того, что я использую, но оно ж мне и не нужно) и как педалит их UI, и у меня возникают сомнения.
Опять же — вы недооцениваете возможности современных браузеров в плане отрисовки UI. Да, есть нюансы но в целом не думаю что у того же свинга есть хоть какие-то преимущества перед страничкой отренденной хромом.
QT
Помню году так в 2009-ом ковырялся с их этим QtQuick. Мне идея дико нравилась и реализация была неплохой. Во всяком случае писать софт под десктоп не на QT мне тогда не хотелось. Однако, беря в расчет то как реализован Qt, сомневаюсь что получится что-то существенно лучшее.
смогут поддерживаться одной кодовой базой.
Вот только я не хочу писать ни на Java ни на C++. А хочу например на Rust всю бизнес логику писать. Потому что type safe и прочее и прочее. Или на хаскеле.
На данный момент существуют два решения для интероп языков — webassembly (все компиляторы на базе LLVM в целом уже умеют в него компилить) и graalvm (оч интересный проект как по мне). А потому опять же — электрон выыигрывает тут так как в отличии от ораклавской graalvm все основано на открытом стандарте.
Написать сетевое приложение на Go значительно проще чем на C++
Согласен. Написать его эффективно — не сильно проще чем на C++. Просто язык дает меньше возможностей по стрельбе по ногам.
так что по эффективности они априори проигрывают.
Напомню что в го рантайм тоже не бесплатный. GC, распределение корутин, все это довольно жиное и в целом приводит к тому что грамотно написанное приложение на Java будет примерно так же эффективно работать. Другой момент что с Go будет проще. Однако тот же rust уделает их всех, хотя посадить студента на раст будет проблематичнее да.
Это С на стероидах.
Тогда Go это С на седативах.
А на Ваш взгляд?
На мой взгляд Go, это ответ на проблему низкой квалификации разработчиков. Урезанный по самое немогу язык (не считаю что это плохо, если что), который максимально защищает человека от вопросов применения воображения. Все делается примитивно и в лоб. Идеально для массовой разработки.
Является ли это качественным скачком? Нет. С точки зрения качества разница не велика. Опять же — основная проблема го — хайп, в свете которого все кому не лень начали на нем писать. И с каждым годом квалифицированность среднего разработчика на Го вызывает вопросы. Сейчас идет процесс усложнения языка, что в купе с наплывом слабых разработчиков скорее всего отбросит его успех назад.
Если же для вас Го это качественный скачек — задумайтесь. Это скачек для вас или для индустрии в целом?
Простите, но где тут количество и о каком качестве идет речь?
Если говорить о количестве и качестве — посмотрите на увеличение количества разработчиков на Go. А теперь проанализируйте тренд уровня этих разработчиков.
То что у нас появился компилируемый эрланг (да, я сейчас ооооочень сильно утрировал, без децентрализации это все не сильно нужно) это замечательно, однако качественного скачка я не вижу. Люди как и раньше писали на Java/Perl/Python/Node/C++ так и продолжают писать. Просто теперь есть еще Go и Rust. А еще есть D, Elexir, Kotlin и многие другие штуки. Но что-то как-то люди продолжают писать микросервисы на php.
p.s. центрифугу юзаю, и рад что кто-то ее написал. Но будь она написана на эрланге, хаскеле или ocaml — мое отношение к ней не сильно бы отличалось.
во первых не к финалу эволюции а к ограничениям элементной базы. А во вторых — причем тут процессоры?
Если что — основная проблема на сегодняшний день не процессоры, а скорость доступа к памяти и I/O. Пока вы ходите в оперативку за списком тредов вашего чатика, процессор может много чего сделать. Очень много всякого.
И выливается это все в распаралеливание и асинхронную работу. А учитывая уровень среднестатистического разработчика сегодня расчитывать на эффективную работу не приходится.
Напомню, что некие ребята из компании Mozilla дабы решить эту проблему хотя бы частично свой язык программирования придумали (именно что бы распаралелить рендринг страничек в своем браузере и при этом не свихнуться).
Что до вопроса с электроном и намеки что приложение на электроне потребляет ресурсов неадекватно больше чем нативное решение — пока это все пустые домыслы. Попробуйте реализовать какой-либо продукт нативно и в электроне. Причем так что бы функционал был идентичен и исходники открыты (дабы можно было объективно проверить насколько качественно реализовано).
Я бы не сказал что все это кастыли. Скорее это попытка компенсировать низкий уровень разработчиков.
И даже в сотню кбайт скомпилированного EXE с зависимостями только виндовых библиотек.
Оцените стоимость разработки того же слэка в вашем исполнении. В человекогодах, с сохранением всех фич. Умножьте это все на 6 (OSX, Linux, Android, iOS, Web). И поскольку у нас теперь не 1 UI а 6 имплементаций — умножим все это на оптимистичный коэффициент 1.5 (накладные расходы на синхронизацию, коммуникацию). Не забудем о тестировании (стоимость оного так же увеличится на порядок, поскольку нам не просто надо 6 UI-ек тестить, а еще и учитывать всякие там версии операционки и кучу других нюансов). Итого — стоимость разработки увеличивается на порядок.
Теперь добавим к этому тот факт что найти разработчиков под все это, которые смогут заставить это все работать — это тот еще квэст. Уж простите, но реалии рынка таковы. Можете винить в этом ужасную ситуацию с образованием в IT в целом. Ну нету адекватных специалистов на рынке в том количестве, в котором необходимо что бы все нэйтив и т.д.
Итого — 10X стоимость разработки. Что до пользователей — как вы думаете, повлияет ли увеличение стоимости разработки на стоимость продукта для потребителя? Нет? Они там свои тарифы просто так нарисовали? Если что — подавляющее большинство пользователей пользуются слэком бесплатно. Так что будет по итогу хуже для пользователя?
Теперь о грустном — вот у меня пред глазами 2 приложения. Телеграм и слэк. Обе отжираютт 600 метров памяти, одно нативное — а другое нет. UI по отзывчивости работает примерно одинаково. Да, слэк иногда подлагивает, но обычно из-за нюансов того, как они реализовали перерисовку, а не потому что хром медленно рендрит. В нэйтиве среднестатистический разработчик так же налажает с локами трэедов или при работе с I/O. И да, по CPU в идле нативный телеграм жрет чуточку больше.
А если не видно разницы — зачем вкладывать в разработку на порядки больше средств? Не лучше ли вложить эти средства в оптимизацию UI и разработку новых фич или даже отдельных продуктов, расширяя бизнес?
p.s. как пример качественного приложения под электрон — сравните vscode с atom. И то и то написано на JS, и то и то — электрон, вот только в том как это все работает какая-то разница все же есть.
> Хотя это боль и унижение, если имплементацию нужно делать более одного раза
Не сказал бы, обычно просто в разных контекстах тесттирование происходит. Например одни и те же сценарии можно гонять на уровне e2e либо на уровне api. И может статься например что для e2e только самые важные гоняются а для api все. Ну разные есть варианты.
Если же прям совсем одинаковая реализация — то возникают вопросы зачем так сделали.
все так. Смысл в этом небольшой конечно, разве что полная свобода и полная независимость от вендора браузера.
тормоза происходят из-за блокировки потока перерисовки этого UI. А заблокировать этот самый поток легко когда он один.
Всякие же сервис воркеры для фронтэндера это уже ух, сложна. Ну то есть требует уже уровня повыше среднего.
это легко обойти.
а как вы боритесь с шелами в метаданных EXIF? Да и потом, уверен что я смогу заиньектить код так что пройду и эту "тяжелую форму".
Как по мне — проблему надо решать иначе.
ну если мне память не изменяет, они просто все контролы на opengl запилили. Почти как это делают браузеры со своим html+css. Ну или вы можете сделать на webgl ;)
нет. Еще раз — проблема не в CPU у 90% приложений. Проблема в работе с памятью.
Вот вы PHP разработчик, да? Помните выход php7? Мол "теперь в 2-3 раза быстрее". Вы же понимаете что это "быстрее" было не потому что у вас вдруг дополнительно частот стало больше, а потому что сильно оптимизировали работу с памятью, повысили локальность данных, уменьшили количество кэш мисов процессора.
А потому ваш слэк или шторм будет педалить одинаково что на 5Ghz что на 10Ghz. А вот скажем рендринг картинки в каком vray будет да быстрее порядочно.
А теперь попробуйте сделать так — понизьте частоты вашего процессора и повторите эксперемент. И попробуем найти корреляцию суммарного времени построения индекса от частот CPU.
и пролаг этот связан с тем что ваш процессор ждет пока данные загрузятся (из кэша, потом из памяти при кэш мисе, и если что еще на файловую систему сгонять).
И как вы думаете, какой процент этого времени уходит на ожидание I/O? Или вы думаете оно там яростно что-то считает?
Ну вы сравнили, объемы вычислений игрушки какой и объем вычислений требуемый тому же шторму.
Шторм упирается в I/O. Да, есть нюансы, типа специализированный софт для симуляций, визуализации и т.д. который можно развивать только за счет параллелизма вычислений, но это опять же маленький процент прикладного софта.
был запущен 12 дней. После перезапуска сходу сьел 190 метров.
я сейчас смотрю на то сколько жрет IDEA и VSCode на одном и том же проекте (и да я понимаю что IDEA может делать много больше того, что я использую, но оно ж мне и не нужно) и как педалит их UI, и у меня возникают сомнения.
Опять же — вы недооцениваете возможности современных браузеров в плане отрисовки UI. Да, есть нюансы но в целом не думаю что у того же свинга есть хоть какие-то преимущества перед страничкой отренденной хромом.
Помню году так в 2009-ом ковырялся с их этим QtQuick. Мне идея дико нравилась и реализация была неплохой. Во всяком случае писать софт под десктоп не на QT мне тогда не хотелось. Однако, беря в расчет то как реализован Qt, сомневаюсь что получится что-то существенно лучшее.
Вот только я не хочу писать ни на Java ни на C++. А хочу например на Rust всю бизнес логику писать. Потому что type safe и прочее и прочее. Или на хаскеле.
На данный момент существуют два решения для интероп языков — webassembly (все компиляторы на базе LLVM в целом уже умеют в него компилить) и graalvm (оч интересный проект как по мне). А потому опять же — электрон выыигрывает тут так как в отличии от ораклавской graalvm все основано на открытом стандарте.
Согласен. Написать его эффективно — не сильно проще чем на C++. Просто язык дает меньше возможностей по стрельбе по ногам.
Напомню что в го рантайм тоже не бесплатный. GC, распределение корутин, все это довольно жиное и в целом приводит к тому что грамотно написанное приложение на Java будет примерно так же эффективно работать. Другой момент что с Go будет проще. Однако тот же rust уделает их всех, хотя посадить студента на раст будет проблематичнее да.
Тогда Go это С на седативах.
На мой взгляд Go, это ответ на проблему низкой квалификации разработчиков. Урезанный по самое немогу язык (не считаю что это плохо, если что), который максимально защищает человека от вопросов применения воображения. Все делается примитивно и в лоб. Идеально для массовой разработки.
Является ли это качественным скачком? Нет. С точки зрения качества разница не велика. Опять же — основная проблема го — хайп, в свете которого все кому не лень начали на нем писать. И с каждым годом квалифицированность среднего разработчика на Го вызывает вопросы. Сейчас идет процесс усложнения языка, что в купе с наплывом слабых разработчиков скорее всего отбросит его успех назад.
Если же для вас Го это качественный скачек — задумайтесь. Это скачек для вас или для индустрии в целом?
Простите, но где тут количество и о каком качестве идет речь?
Если говорить о количестве и качестве — посмотрите на увеличение количества разработчиков на Go. А теперь проанализируйте тренд уровня этих разработчиков.
То что у нас появился компилируемый эрланг (да, я сейчас ооооочень сильно утрировал, без децентрализации это все не сильно нужно) это замечательно, однако качественного скачка я не вижу. Люди как и раньше писали на Java/Perl/Python/Node/C++ так и продолжают писать. Просто теперь есть еще Go и Rust. А еще есть D, Elexir, Kotlin и многие другие штуки. Но что-то как-то люди продолжают писать микросервисы на php.
p.s. центрифугу юзаю, и рад что кто-то ее написал. Но будь она написана на эрланге, хаскеле или ocaml — мое отношение к ней не сильно бы отличалось.
во первых не к финалу эволюции а к ограничениям элементной базы. А во вторых — причем тут процессоры?
Если что — основная проблема на сегодняшний день не процессоры, а скорость доступа к памяти и I/O. Пока вы ходите в оперативку за списком тредов вашего чатика, процессор может много чего сделать. Очень много всякого.
И выливается это все в распаралеливание и асинхронную работу. А учитывая уровень среднестатистического разработчика сегодня расчитывать на эффективную работу не приходится.
Напомню, что некие ребята из компании Mozilla дабы решить эту проблему хотя бы частично свой язык программирования придумали (именно что бы распаралелить рендринг страничек в своем браузере и при этом не свихнуться).
Что до вопроса с электроном и намеки что приложение на электроне потребляет ресурсов неадекватно больше чем нативное решение — пока это все пустые домыслы. Попробуйте реализовать какой-либо продукт нативно и в электроне. Причем так что бы функционал был идентичен и исходники открыты (дабы можно было объективно проверить насколько качественно реализовано).
Я бы не сказал что все это кастыли. Скорее это попытка компенсировать низкий уровень разработчиков.
А если вам совсем поплакать хочется за "прогресс человечества" — The Mother of All Demos, presented by Douglas Engelbart (1968)
напомните мне примеры выполнения этого закона.
Оцените стоимость разработки того же слэка в вашем исполнении. В человекогодах, с сохранением всех фич. Умножьте это все на 6 (OSX, Linux, Android, iOS, Web). И поскольку у нас теперь не 1 UI а 6 имплементаций — умножим все это на оптимистичный коэффициент 1.5 (накладные расходы на синхронизацию, коммуникацию). Не забудем о тестировании (стоимость оного так же увеличится на порядок, поскольку нам не просто надо 6 UI-ек тестить, а еще и учитывать всякие там версии операционки и кучу других нюансов). Итого — стоимость разработки увеличивается на порядок.
Теперь добавим к этому тот факт что найти разработчиков под все это, которые смогут заставить это все работать — это тот еще квэст. Уж простите, но реалии рынка таковы. Можете винить в этом ужасную ситуацию с образованием в IT в целом. Ну нету адекватных специалистов на рынке в том количестве, в котором необходимо что бы все нэйтив и т.д.
Итого — 10X стоимость разработки. Что до пользователей — как вы думаете, повлияет ли увеличение стоимости разработки на стоимость продукта для потребителя? Нет? Они там свои тарифы просто так нарисовали? Если что — подавляющее большинство пользователей пользуются слэком бесплатно. Так что будет по итогу хуже для пользователя?
Теперь о грустном — вот у меня пред глазами 2 приложения. Телеграм и слэк. Обе отжираютт 600 метров памяти, одно нативное — а другое нет. UI по отзывчивости работает примерно одинаково. Да, слэк иногда подлагивает, но обычно из-за нюансов того, как они реализовали перерисовку, а не потому что хром медленно рендрит. В нэйтиве среднестатистический разработчик так же налажает с локами трэедов или при работе с I/O. И да, по CPU в идле нативный телеграм жрет чуточку больше.
А если не видно разницы — зачем вкладывать в разработку на порядки больше средств? Не лучше ли вложить эти средства в оптимизацию UI и разработку новых фич или даже отдельных продуктов, расширяя бизнес?
p.s. как пример качественного приложения под электрон — сравните vscode с atom. И то и то написано на JS, и то и то — электрон, вот только в том как это все работает какая-то разница все же есть.
Фортран фортрану рознь. И да, нет ничего стыдного в том что бы писать на фортране.
Но согласитесь, новых проектов на кобале вроде как не страртуют уже особо.
А как бы вы проверяли? Мне просто любопытно.
Не сказал бы, обычно просто в разных контекстах тесттирование происходит. Например одни и те же сценарии можно гонять на уровне e2e либо на уровне api. И может статься например что для e2e только самые важные гоняются а для api все. Ну разные есть варианты.
Если же прям совсем одинаковая реализация — то возникают вопросы зачем так сделали.