Как стать автором
Обновить

Комментарии 43

> Dart
Очередное не нужное УГ.
Я пробовал Flutter, по производительности он рвет React Native в клочья. Так что у Dart есть определённые перспективы.
Зачем улучшать то (RN), чего изначально не должно было существовать?
Затем что доля заказов на кросплатформу растёт. А RN это боль. Поэтому надо заказчиков мягко переключить на Flutter.
Если рассматривать в контексте веб-сервера. То скорее всего для того чтобы исключить TS, Flow, транспиляцию, и использовать строготипизированый нативно язык на архитектуре неблокирующего эвент лупа
Это не вопрос, а претензия к фреймворку.

Цукерберг — бизнесмен в первую очередь. Он делает все для оптимизации бизнеса. Но это не значит что он делает правильные вещи.

P. S.: редактировать комментарии искажая изначальный смысл — не надо так. Дописали бы через UPD.

UPD: кроссплатформа на мобильных точно не нужна. Это даже не обсуждается. Точка.
Спасибо за замечание. Учту.
На сколько я знаю, в последнее время ходят слухи об ос Фуксия, которая на Dart и Flutter, если это так и она взлетит как приёмница Android, то это уже будет стандарт под мобилы, по крайней мере от Google. Я вот сани летом готовлю.

UDP: А если он (Flutter) ещё и будет из коробки поддерживать портирование под Яблоко, Линукс и Винду, то я лично рад буду только и скорее всего со мной будут радоваться ещё много тысяч заказчиков, которые оплачивают весь этот праздник жизни
Вы видели приложение Яндекс Карт? Оно на RN. И оно ужасно

Портировать Java код под iOS можно и сейчас, например (см. J2ObjC).
— Вы почитайте про Flutter, он предлагает готовые библиотеки компонентов Material Design и Cupertino. Практически пиксель перфект и физикой оригинала
— Основная проблема RN это bridge из за чего возникают проблемы с производительностью при чехарде данными между js движком и нативом, Flutter устроен иначе. Поставщики предлагают 100% аналоги UI при рендере на стороне фреймворка.
— В последнее время стало выходить много интересных приложений от исследователей Flutter и я был поражён его гибкостью. «Всё что угодно» — это можно назвать так.
— Писать в 2019 году на Objective C уже не кашерно
> Поставщики предлагают 100% аналоги UI
утверждение которое вводит в заблуждение.
в флаттере не 100% аналоги виджетов UI, к примеру в ios клавиатура уходит вместе с VC в NavigationController, в флаттере нет.
Насчет 100% замены iOS блюров тоже терзают сильные сомнения, беглым поиском не iOS приложения/демо с блюром что бы сравнить с нативным.
(если там тоже самое что и в андроидовском демо с cupertino, то это ужас и кошмар)
Да, иногда Остапа сильно несёт. Но в любом случае, судя по тому как это реализуется, то тут вопрос больше в количестве времени которое могут выделить разработчикам на приведение UI в соответствие нативу
Откуда информация про Яндекс Карты? Я посмотрел — не выглдяит RN приложением, ни одного характерного для RN «хвоста», выглядит просто как очень кастомизированный native код. Cкорее всего тут схожесть между платформами важнее платформного look and feel
НЛО прилетело и опубликовало эту надпись здесь
А если сравнить с NativeScript? У него другой механизм, чем у RN.
«в оптимизацию работы V8 вложено колоссальное количество человеко-часов „

Создатель V8 Lars Bak работает на Гугл с 2004 года, так что команде Dart не надо было изобретать велосипед и вкладывать в Dart столько же усилий, как в V8.

А бенчмарки это дело такое, все они меряют что-то свое. Если мерить задержку и пропускную способность асинхронной обработки сетевых запросов, то Dart заметно быстрее — mrekucci.blogspot.com/2014/09/asynchronous-io-micro-war.html (но Netty все равно лучше).

Прикол в том что эти тесты на 500 или боже упаси 1000+ rpc, вычурные, у 99% проектов(это ещё мягкие оценки) такой загрузки не будет. Даже у stackexchange в пике 450 запросов в секунду.) https://stackexchange.com/performance.
Проект скорее упрется в кривую логику и алгоритмическую сложность или в запросы к бд или другие узкие места. А мерять запрос-ответ в вакууме это ни очем, есть ещё куча других моментов.

Stackexchange при всём уважении, наверное не самый популярный сайт в мире, все же целевая аудитория узковата (и никаких котиков)))). С точки зрения нагрузки надо смотреть на сайты типа google.com, Amazon.com, Facebook.com или отечественные vk.com, mail.ru )

Перечисленное вами как раз попадает в оставшийся один процент. Я хотел донести мысль что тестировать язык или платформу на поглощаемое кол-во запросов секунду это не тот параметр на который нужно обращать внимание. До размеров stackexchange нужно хотя бы дорасти.) А у них нагрузки как видно долеки даже до 500 rps. Там и решения можно применить специфические. А в 99% проблемы будут в других частях.

У многих проггеров страсть к велосипедам собранным ими самими. Я с этим борюсь, но не всегда получается. Плюс это возможность изучить новый инструментарий. K6.io мне подкинул интересную идею, о том что в качестве фронта для программиста может быть использован JS а бека Go, решение получилось очень производительным.
Интересно. Было бы еще интересно взглянуть на сравнения с php+веб сервер и golang
На а этот счёт есть статья от ребят из mail.ru мы же можем сделать вывод относительно Node.js. Golang естественно будет наиболее производительней. На стороне бека я бы за него топил. Но толко в там где появляются узкие места (привет микросервисная архитектура), так как простой прокси на СУБД можно реализовывать на чем то попроще

А вы читали, как ребята из mail.ru опозорились в своих бенчмарках?

Интересно. Но если разбираться до конца то важно учитывать не только производительность. Для меня важным является то сколько потребляет процесс ( в случае node и Go эта разница составляет 10 раз),
Плюс это наличие библиотек. К примеру недавно уперлись в то что либа под Go не может стилизовать графики Excel. Не знаю как под node но нам пришлось или отказать заказчику в этом требовании или после формирования отчёта, его распаковывать и ручками по регулярке править xml. Вобщем запрос висит на хабе (расширение либы) но из за нас никто это делать не будет, да и мы не хотим тратить на решение этой задачи месяц работы
Затрудняюсь, я уже там не работаю. Хотя в статье есть пометка, что тест относительный. Поэтому никакой разницы, что за проц нет. Шина и проц перегружены тестовым фреймворком который запускает по 500-750 http соединений единомоментно
У 8700k в 1.5 раза больше ядер(6 против 4), и по тестам он в среднем процентов на 30% (на треть, не в три раза) быстрее. Может быть поделитесь в каких задачах он в 3 раза быстрее?
Intel Core i7-2600K vs. Intel Core i7-8700K

Cinebench R15 (Single-Core)
128 (62%) vs 208 (100%)

Cinebench R15 (Multi-Core)
612 (42%) vs 1447 (100%)

В однопотоке разница на треть да, в многопотоке в 2.3 раза. Это не учитывая разгона, в нем однопоток становится быстрее в ~1.7 раз, многопоток в 2.7.
Во первых разгонять сервера как-то не принято.
Во вторых 3х раз все равно нет.
В третьих рендер в сайнбенче — сугубо расчетная задача нагружающая только цпу, а вебсервер в основном занимается вводом-выводом, так сравнивать вообще некорректно
Вы читали мое сообщение? Там написан вопрос про модель i7. Какие еще сервера?
3 раз нет, есть почти 3 раза.

Тестировал я как-то приложение на процессоре 2.4ггц и 3.6. Разница была видна даже на глаз. Поэтому частота очень решает.
Конечно прочитал,
Сервера при том что обсуждается серверное программное обеспечение,
разница между производительностью i7 первого и последнего поколения относительно не большая, и становится «в разы» только там, где софт может эффективно использовать добавившиеся ядра или новые наборы инструкций, что в случае веб-сервера актуально далеко не всегда

вам примерно об этом написали в 2х комментариях, а Вы зачем-то начали приводить результаты сайнбенча и разгон, хотя это в данном случае не релевантно.

Мне вообще была интересна модель i7. Вы опять начинаете про сервера.
Между первым i7 и последним — пропасть. Причем в однопотоке и многопотоке.
Вы видимо думаете что главное чем отличаются процессоры — количеством ядер, но нет. В первую очередь их отличает качество ядер.
Сможете эту «пропасть» охарактеризовать в числах?
Пару сравнений:


Про первое поколение лучше не начинать, там все плохо. Поэтому начинают обычно с 2600k.
И? Где пропасть то? (реальная пропасть есть, но она отнюдь не в производительности)

прогресс примерно в 2 раза за 8 поколений и почти 9 лет,
а значимые скачки, как и написал выше, или кол-во ядер или новые инструкции.
если еще нормировать на частоту, то прогресс на каждом поколении придется под микроскопом искать

Напомню, мы с вами в топике бенчмарка http сервера, для которого «числодробительная» мощь проца — далеко не на первых местах по важности, и сравниваются 2 разные программы, а не разное железо

а если уж совсем отойти от темы и по сравнивать теплое с мягким
то можете оценить прогресс от первого до предпоследнего поколения Core в вот этом видео www.youtube.com/watch?v=Viq1bSJHyAM

На безрыбье и рак — рыба. Процессоры могли бы расти как видеокарты, но видимо что-то мешает этому. Вы видимо сравниваете с таким ростом, желая роста 100% в год))
В реальности разница в 10% в однопотоке — уже супер, не говоря уже о 100%. Более того, выпусти интел завтра i7-9900k-v2 с 6ггц, фанаты его раскупят даже за $1000 потому что 10% в процессорах = 100% в видеокартах.

Что до многопоточности, Интел без конкуренции придерживала ядра, сейчас же прогресс возобновился. Если амд 9 числа анонсирует 12/16 ядер (я сомневаюсь в этом, но все же), то старые i7 станут сегодняшними пеньками.
Вы видимо сравниваете с таким ростом, желая роста 100% в год))

Я пишу о том что ваши «3 раза» далеки от реальности и в данном топике вообще бессмысленны

10% в процессорах = 100% в видеокартах.

тоже крайне спорное утверждение

разница в 10% в однопотоке — уже супер
— с этим соглашусь
серьезных подвижек без смены архитектуры мы пока не увидим
Интересно тогда услышать правильный ответ. Во сколько раз быстрее первой модели последняя?
а правильного ответа нет)))
результат будет зависеть от того что мерить, как мерить, где в данных условиях узкое место и еще множества других факторов.

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

Задействование AES-NI может заставить хилый Atom быть в разы производительней на операциях шифрования по сравнению с гораздо более мощными CPU где AES-NI отсутствует или не включен
AVX может ускорять работу с видео потоками

сам вопрос
Во сколько раз быстрее первой модели последняя?
не имеет смысла без уточнений при каких условиях.
Поддержу вас. У меня трудится рабочая станция HP Z420. Каких то глобальных различий не видно. Самое смешное что я специально заменил xeon e5 1620 -> xeon e5 2680 v2 нужно было больше ядер для виртуалок.

springimport
Мегагерцы не решают. Подбирайте сбалансированную конфигурацию и будет вам счастье.

@ogregorпривет.
Я испытываю нездоровое влечение к написанию бэкенда на dart.
Но моя рациональная часть меня постоянно одёргивает и убеждает меня, что это нецелесообразно т.к. на данной платформе пока сильно меньше готовых и опробированных решений - часто придётся писать свои велосипеды.
Скажи пожалуйста, был ли у тебя опыт написания бэкенда на dart за последнее время? Стоит ли оно дополнительных трудозатрат?

Я думаю что нет, проще взять node.js и typescript. Вряд ли под дарт существуют какие то нормальные библиотеки для работы с типично бэковскими вещами, такими как базы данных, различные хранилища и т д. Тем более вряд ли там есть какие то коннекторы к специфичным программам, таким как ClickHouse или Tarantool

Я пытался сделать бэк с использованием https://aqueduct.io/ В целом выглядит очень хорошо, но столкнулся с невозможностью использовать в БД тип данных numeric и некоторую ограниченность возможностей встроенного ORM.

Сейчас сделали форк этого проекта https://gitbook.theconduit.dev/ и многое исправили, но более подробно не разбирался еще.

Рекомендую посмотреть на https://appwrite.io/ Это open source и self-hosted аналог firebase в части некоторой функциональности, есть готовая клиентская библиотека для Flutter и можно писать серверные функции на Dart.

интересно спустя 3 года что то изменилось или нет?))

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории