Новость на iXBT от 6.11.23 "BYD построит свой первый европейский завод". Но не зависимо от того есть там на данный момент завод или нет, это только подтверждает правильность тезиса о том что китайские производители сначала растут на огромном китайском рынке, где правительство им обеспечивает поддержку и продвижение, а потом идут захватывать мировой. Компания BYD существует с 2003 года, 20 лет они жили и развивались на внутреннем рынке, доросли до того, что стали делать электромобилей больше теслы, а теперь начинают экспансию в остальной мир. И такой путь почти каждой китайской успешной компании. И он возможен только из-за очень большого внутреннего рынка. Что мешает мешает делать такое же с производством чипов? Куча автопроизводителей и производителей электроники уже сделали огромный рынок сбыта для китайских чипов. По факту санкции играют сейчас ровно обратную роль, они нарушают устоявшуюся монополию крупных мировых производителей и создают все условия для появления их конкурентов. Сейчас сложно себе представить что AMSL может кто-то заменить, как сложно было представить что клоны айфона с телевизором превратятся в Xiaomi 13T Pro или Huawei P60 Pro.
Думаю что там экономика как строй, на словах это коммунизм, а по факту гибрид. Много ли видели среди экспорта китайский авто компанию BYD? Вообще ни одного не видел. А ведь эта компания производит электромобилей больше чем Тесла. У меня сейчас во дворе( это большой ЖК) точно будет стоят пара электромобилей теслы, BYD не будет ни одного. Наверно в целом вы правы, экономика живет за счет экспорта, но речь именно о стадии роста, сначала активное развитие мелких компаний за счет внутреннего рынка и стимулов на нем, а когда они созрели идут в мир. Речь именно о стадии развития. Причем действуют они всеми доступными методами, копирование, производство по лицензии, сначала производство по лицензии, потом копирование, покупка не китайских компаний и вытягивание всех технологий. И еще заметил одну особенность - если что-то появляется у одного китайского производителя, то это тут же распространяется по всем, такое чувство что правительство заставляет свои компании друг с другом делиться технологиями.
Если смотреть исторически, представить что китай станет лидером производства смарфонов в 2003 году, когда были китайские клоны айфона с телевизором, было вообще невозможно, на смех бы подняли за такое утверждение. А сейчас есть айфон и есть китайские смартфоны, все. Еще самсунг, даже lg сдулся. То же самое сейчас происходит с автомобилями, представить себе Geely Monjaro во времена чери амулет было невозможно, а сейчас отдельные китайские бренды могут очень неплохую конкуренцию составить немецким и иногда японским производителям. Почему вы не верите что то же самое может произойти в области производства оборудования для чипов? У них есть гиганский рынок сбыта, сам китай, на локальном рынке всегда проще развиваться.
Все просто, причина та же по которой с++ программисты не понимают зачем код покрывать 100% юнит тестами. Условно код программы можно разделить на:
1) код который выполняет задачу, как правило это какой алгоритм, у него есть входные данные и выходные
2) код который занимается доставкой данных из разных мест и отправкой результата в нужные места программы или обработки различных действий по результатам(показать попап, обновить БД или еще что).
Причем кода второго типа может быть достаточно много, но он простой, ошибиться можно разве что написав метод с ошибкой или имя переменной, нарушить типизацию или еще что, особенно это важно когда происходит какой-то рефакторинг. Так вот правильность имен переменных, правильность типов, совместимость данных большей частью проверит компилятор во время сборки. А JS исполняется строчка за строчкой и программа содержащая ошибку в JS коде запустится, но работать не будет и вы узнаете о ошибке в название метода или переменной во время работы приложения. Контролировать большое количество такого кода становится проблемой. Я не говорю что компилятор это магическая палка выручалка которая защитит вас от всего на свете, но она защитит вас от ошибки в именах методов, классов, функции, от несоответствия типов, а если применять мета программирование(шаблоны) еще много от всего.
И конечно же с++ код легче отлаживать, отладка с++ кода реализована наверно в любом компиляторе и на любой платформе, от программирования микроволновок, до микро сервисов(да на с++ то же можно писать микро сервисы, причем для этого есть очень крутые системы типа CORBA которым 100500 лет). Беда многих молодых программистов в том что они даже если слышали про CORBA открывают ее документацию смотрят минут 15 и закрывают, после чего начинают делать JRPC на с++, сталкиваются с тем что не понимают как быстро написать парсер json после чего идут смотрят на Go, где это пишут чуть ли не во введение и решают писать на нем. Я не против Go, это хороший язык, но неплохо было бы знать какие методы и решения использовались до того как появился Go, возможно там будет что-то более мощное и функциональное. Или еще пример, опять же про тот же json, есть такая библиотека simdjson, у нас получилось на современном компьютере парсить 3Гб json файлов за 150мс на нем. Кто-то может похвастаться таким перфом?
Или boost::graph, я половины этой библиотеки не понимаю, но даже то что понимаю позволяет решить все задачи на графах которые у меня когда либо возникали, причем достаточно компактными 15-20 строчками кода, да это будут очень странные 20 строчек кода, на которые посмотришь и такой, чё???? Но работать будет быстро и лучше ничего нет, вообще. Как и CGAL это наверно самая фундаментальная и комплексная геометрическая библиотека которая существует.
"Если скинете примеры", что скидывать то? есть правила сборки qt приложения, они примерно такое, qml файлы декларируются в qrc файле, дальше при сборке весь контент перечисленный в qrc файле трансформируется в с++ код, прим в исходнике base64 текстом все бинарные фалы идут. Потом компилятор все собирает в бинарные файлы. Данные падают в секцию данных и доступны грубо говоря как глобальные переменные, обертка над ресурсной системой позволяет их доставить типа QFile("qrc://main.qml"), все. Для того что бы собрать проект нужна любая система сборки которая позволяет делать правила компиляции для файлов. Сборка qt/c++ приложения это последовательный вызов определенных утилит, которые делают определенные трансформации над данным и в итоге получается бинарный файл. Для того что бы это все руками не настраивать есть CMake он интегрируется в Gradle, и с помощью него же генерируется xcode проект где уже все настроено. Для того что бы писать на qt достаточно минимальных знаний cmake, после чего вы получите проект для MSVS, XCode, такие среды как CLion и QtCreator могут прямо открывать Cmake файлы и показывать из них проекты. Отладчик QML вы кроме QtCreator больше нигде не получите, но там особо отлаживать нечего, это статическая верстка и очень тривиальный код.
"для iOS в альфе сейчас" В 2012 году уже писал на Qt/QML большой коммерческий проект под Android.
"с coroutines приятнее и удобнее чем с потоками" так используйте они же есть уже в стандарте. Но операционка все равно оперирует потоками и семафорами, хотите быстро и полный контроль тут без шансов, вам нужно манипулировать самым близким уровнем к железу, а это с++.
"где мне или кодогенерация или gson распарсят json без особых стараний с моей стороны" Как выглядит парсинг JSON в с++:
namespace ns {
struct person { std::string name; std::string address; int age; };
Для с++ сделали пакетный менеджер уже несколько лет, даже несколько есть конан, не использовал, есть vcpkg там 2200 библиотек. Есть такие библиотеки которые невозможно переписать на что-то иное, максимум вокруг с++ написать обертку в нужный язык, boost::graph, opencv, curl, jolt, box2, bullet, openimage, spirv, implot, sqlite3, libtorrent, tesseract, cgal. Каждая из этих библиотек это сотни человеколет работы, мы с вами вместе за всю жизни не напишем даже одну из этих библиотек, даже если всю жизнь будем работать только над этим.
Скорее всего для многих написали обертки в котлин для Qt даже есть обертка в питон. Но зачем нужно ждать пока кто-то сделает и зачем нужна обертка, если все равно основные библиотеки все на с++ написаны, бери исходник, даже WebRTC это с++ в основе, там без шансов быть чему-то иному.
Вы просто попробуйте решить задачу редактора любой игры прям на девайсе. Тут же столкнетесь с кучей проблем, если только у вас движок игры будет не на котлине, а на котлине он врядли будет, просто не потянут не по перфу не по сложности, все это тут же сожрет всю память сегментацией и будут дикие фризы во время сборки мусора, это кое как решили в юнити, и то, вместо фриза на кадр, просадки на несколько кадров. Мощь с++ не в том что он какой-то удобный или в его синтаксическом сахаре, его мощь в библиотеках которые решают любую задачу которые можете придумать и скорее всего они уже лежат на гитхабе и добавлены в vcpkg.
IDE может быть любой, красота Qt в том что вы можете писать программу полностью на десктопе под десктоп, без эмуляторов, симуляторов и прочего, почти 95% кода так можно написать и остается 5% которым потребуется платформенно зависимые штуки, скорее всего это будут пуши, может быть работа с камерой. Нет проблемы разрабатывать на Qt используя андроид студию. В разработке на qt строго говоря вы вообще не привязаны к IDE. Насчет сложности С++ разговоры сильно преувеличены, тут конечно вкусовщина, это мой основной язык разработки на протяжение наверно 20 лет, но у него есть плюс, даже два, он кроссплатформенный, программа написанная на котлин или Swift будет работать только под одной платформой, и если их выбрать как основу, вам нужно иметь две команды которые будут фактически делать два приложения, программа написанная на с++ будет работать везде, конечно же мы говорим про логику, а не взаимодействие с ОС специфичными. "сам kotlin гораздо приятнее" Вы же понимаете что это вкусовщина, язык должен позволять выполнять определенные задачи, грубо говоря реализовывать алгоритм, все Си подобные языки более менее одинаковые (если не нравится си подобный, можно сказать оберон подобные или процедурные или ООП, кому как нравится). В целом что бы решать почти все задачи достаточно функций и структур, остальное это синтаксический сахар, корутины, замыкания, стандартная библиотека и прочее и прочее, это удобные помощники, но не больше.
"Непонятки с QML/C++ что где писать и на что ориентироваться" стоит начать и все сразу станет понятно, с++ это строительные блоки QML это клей который склеивает их между собой. С++ строго типизированный язык, на нем нужно писать 90% кода, в случае если что-то пойдет не так, программа как правило не соберется(имею ввиду не соответствие типов), QML дает свободу в виде отсутствующей типизации, на нем удобно склеивать между собой различные блоки сделанные на с++, но если вы нарушили типизацию узнаете(как в питоне) в момент выполнения программы. QML по большей части декларативный язык, это такой HTML на стероидах, в нем можно писать блоки на JS, но лучше что бы это были простые функции проброса данных в с++ и логику на js лучше вообще не писать. Ну и мегафича Qt/QML это свои виджеты, у вас есть RHI(можно считать что это OpenGL) и делай что хочешь и как хочешь, шейдеры, многопоточный рендер, все сразу, любые капризы, вот тебе gl контекст делай шо хочешь. У нас представление игры в тулинге фактически через один виджет реализовано, просто сделали его оберткой вокруг движка и игры.
Писать мобильные приложения на десктопе без эмуляторов и прочего это кстати очень удобно и значительно быстрее. Просто делаете приложение, оно запускается, отлаживается, все как в любом десктопном приложение, любой профилировщик втягивается, потом шаманите с системой сборки, где МОКи для мобильно специфичных задач подменяются на реальные при сборке и вырезается все что вы прикрутили на десктопе для отладки и профилирования и прочие хелперы. И хлоп на выходе мобильное приложение, причем у себя на машине вообще не собираю его, все делает CI. Я просто пишу приложение как для десктопа, а потом магическим образом получаются ios и android приложения.
Не понимаю почему Qt/QML так мало используют в мобильной и уж тем более в десктопной разработке. Очень удобный фрейморк или СДК, кому как нравится, работает быстро, накладные расходы на кроссплатформенность минимальные, платформенно специфичные баги бывают, но достаточно редко. Я его использую для разработки внутреннего тулинга в геймдеве, причем уже в двух компаниях. Альтернатива электрон, но смотрю на слак и скайп, постоянно то одно то другое бажит и как-то желания даже смотреть его нет. Скайп был вообще мегастабильный до перехода на электрон. Вайбер и Телеграмм на qt сделаны, телеграмм конечно достаточно специфично qt использует )) но то ладно.
Не знаю о чем вы конкретно, но у меня лента просто на монитор сзади приклеена, и просто светит одним светом, красиво выглядит и глаза меньше устают, плюс света больше становится, не могу работать в полумраке, с наступлением осени пользуюсь каждый день.
Шумиха, думаю, в следствие новизны подхода, первые кто сделал десктопный арм в массы. Мне то же непонятна шумиха вокруг десктопных арм процов. У эпла хорошие процессоры получились, но думаю не потому что арм, а потому что эпл их делал.
"Зачем сравнивать с Ryzen?" Сравнивать больше не с чем, назвался десктопным процом сравнивайся с десктопом. Про и Макс это процы для ноутов, наверно их сравнивать надо с Райзен для ноутов, а вот Ультра это чисто десктопный проц. А зачем сравнивать, а как еще разобраться в вопросе. Условно у меня устаревает компьютер, возникает вопрос, что лучше собрать х86, или купить мак студио, или может ноутбука хватит с подключением внешнего монитора и переферии, лично для меня вопрос так стоит. Условные $3,5к за апловский ноут звучит много, но у меня текущий комп вообще ни разу не дешевле был, а может и дороже, думаю цифра ближе к $4.5к(одна 4090 с блоком питания больше $2.5). Пришлось немало сил приложить что бы комп был тихим, но печка еще та, зимой хорошо, летом реально кондиционер приходится посильнее включать. 600-700Вт в при нагрузке на проц и видяху это нормально.
Пока м2 Ультра выглядит нормально относительно топовых Райзен, но если брать Тредриперы, м2 начинает проигрывать.
У меня далеко не рядовые запросы, пишут с++ код примерно 5-8 часов в день, хочется что бы все происходило настолько быстро насколько оно может быть, поэтому приходится откидывать существенные деньги на железо, каждый раз плачУ и плАчу, но потом оно себя оправдывает. Задержки на компиляцию минимальные, даже полные ребилды, не успеваешь из мысли выйти. Помню времена когда рядовой проект мог собираться 10 минут, вот это да, уже забыл что делал пока сборку дождался.
Не совсем понятен ваш агрессивный коммент в мою сторону. Я бы приложил графки потребления, если бы они были, но в своем посте четко обозначил эту тему. "По потреблению энергию м2 конечно же далеко впереди".
"А если ему поднять TDP до 120 вт, кто выиграет?"
В этом вопросе и заключается мой комментарий, который критикует тезис в статье, о том что архитектура арм принципиально выигрывает у х86. Только отталкиваюсь от производительности, именно последние проценты перфа раздувают энергопотребление процессора и превращают его в печку. В этом и вопрос, какое будет энергопотребление условного м2' если его по перф на существующем техпроцессе увеличить на те самые 25% на которые он отстает, если мы говорим про одно ядро и 160% если говорим про все ядра. Не выйдет ли так что энергопотребление примерно одинаковое получится с х86.
Мне кажется что качество процессора, что бы не скрывалось под словом "качество" определяет техпроцесс, транзисторный бюджет и лимиты энергопотребления, а архитектура, если она не имеет значительных ошибок в реализации, в последнею очередь. Переход апл на арм, на мой взгляд, обусловлен не причинами превосходства арм над х86, а другими:
экономическими - закупать чужой процессор дороже чем делать свой
гибкостью в разработке - свои процессор можно наделить дополнительными блоками под определенные задачи, безопасность, распознавание образов и прочее, что эпл периодически делает для айфона.
большей независимостью выстраивать бизнес процессы, не надо ждать релиза интел новых процессоров, можно делать ровно такие процессоры какие нужны апл, а не договариваться о этом с интел.
То же самое касается и нвидии. амд уверено выступает и на рынке видеокарт и на рынке процессоров, интел был только на рынке процессоров, но с недавних пор штурмуют рынок видеокарт, нвидия живет только на рынке видеокарт, и не имеет выхода на рынок процессоров, х86 для них закрыт, никто не продаст лицензию, остается только арм, выпуск своих процессоров позволит на равных конкурировать с амд и интел по охвату сегментов рынка.
Мне как пользователю нравится конкуренция арм против х86, конкуренция четырех компаний на всех сегментах рынка против конкуренции пары компаний, но как с++ программисту добавление еще одной архитектуры это конечно тот еще геморрой, то какие-то нужные библиотеки имеют в себе асемблерные куски и не портированы под арм, то непойми как CI настроить на кросскомпиляцию.
Попробуйте такой же тест провернуть установив на свой компьютер линукс, где-то читал что у виндовса медленно происходит оперировать объектами ядра ос, открывать мьютексы, файловые дескрипторы. Я же говорю чисто в лоб сравнивать процессоры сложно, получается или сравнение ос или сравнение компиляторов. Что бы сравнить прям чисто процессор нужно брать синтетику, синебенч это чистая синтетика, но потом получается как у вас. У меня то же такой пример, проект на с++, на виндовс сборка 5 минут, на маке 1:30, но это больше говорит о том что кланг работает быстрее чем компилятор микрософт.
Еще важен момент, что м2 опережает ваш процессор на поколение, м1 корректно сравнивать с 5950х, а м2 корректно сравнивать с 7950х, у м2 и 7950х более менее одинаковое время релиза и одинаковый техпроцесс.
У меня есть стойкое чувство что определяющим фактором является не архитектура, а техпроцесс и тепловой пакет, все остальное будет давать проценты разницы. х86 процессоры можно упрекнуть что они делают двойную работу, им нужно большие команды разбивать на маленькие, за арм процессор это делает компилятор. Битва команд процессоров была важна в 70х-80х, когда действительно писали на ассемблере и большие команды(скорее подходящее слово комплексные) были банальным удобством программиста, кому захочется писать 5 команд когда можно написать одну. Тогда х86 победил арм, сейчас выходит что у арм процессора всегда будет один блок проще, а значит он будет меньше транзисторного бюджета использовать и меньше потреблять. Насколько большая работа по разбивке комплексных команд на мелкие я не знаю, насколько она много потребляет энергии и занимает транзисторного бюджета то же, но такой аргумент в против х86 привести можно.
"то чипы на её базе получаются весьма производительные плюс энергии потребляют меньше, чем x86-решения."
Вот как выглядят "весьма производительные" чипы в тестах. По потреблению энергию м2 конечно же далеко впереди, но по перфу пока проигрывает. И, возможно, если это самое "пока" попробуют исправить то и энергопотребление может подрасти. Тест синебенч это конечно специфичная задача, но других прямых сравнений сходу не нашел, мне интересно было бы сравнить время компиляции, но сравнить его достаточно сложно, если взять visual studio и xcode получится сравнение компиляторов, а это не то что хотелось бы.
Как выбрать... если домой, у вас есть один вариант - 4090, на А100 и прочие денег не хватит, ценник стартует от 800 тр, стартует(!). В то же время бессмысленно пытаться что-то сделать на 16Гб, ну что-то получится но перф и модели будут маленькие, 4090 - это входной билет по памяти и перфу, цена в 200 тр еще хоть как-то подъемная что бы купить.
М.2 один - значит резервирования не будет, диск сгорит - досвиданья данные. Подключить пулы жестких дисков по USB то же так себе идея. Они менее стабильные чем SATA, в том плане что могут отваливаться во время месяцев непрерывной работы.
$500 за синолоджи отдавать это действительно так себе идея. Примерно за $300(если не считать диски) собрал себе NAS и немного бушного железа.
ASUS Prime B550M, Ryzen 5 3600x, 32Gb (максимум можно 128Gb), затычка GeForce GT 1030 с пассивным охлаждением. Корпус Fractal Design Define R5. Аналоги по процу и памяти от синолоджи стоят за $1000.
Может NAS делать? Но для NAS нужно несколько(желательно от 3) sata портов. Что бы пулл зеркальный сделать(для важных данных) и пулл для всякого хлама, но на одном hdd.
Вроде изначально идея малины и подобных это быть дешевыми и позволять рулить разной периферией, шаговыми двигателями, релешками и прочим, при этом будучи полноценным компьютером не обрекать разработчика на ад программирования микроконтроллеров, от которого у обычного десктопного разработчика взорвется мозг(понятно утрирую). И вот $180 это уже не дешево, да железо выглядит на грани ультрабюджетных исторически десктопных производителей. И мне даже несколько раз хотелось купить таких штук 10 и попробовать поупражняться в разработке под кластер. Или купить как комп для фана, типа показывать друзьям какой маленький и дешевый и работает как полноценный, но каждый раз останавливался. Ибо не мог понять что с ним все же делать.
Логика такая: мне же нужен типа десктопный, значит надо памяти 16Гб, а сейчас 32Гб(потому что памяти не бывает много), хм еще корпус, охлад нужен, карта памяти, ну на побольше. Ну ок, получается вроде норм, даже можно будет отдать ребенку в качестве первого компа. Но тут по цене выскакивает мини-ПК на интеле который чуть дороже... ммм так может мини-пк взять, уже все собрано и корпус нормальный... И зачем мне еще один комп, у меня из старого железа уже можно и так датацентр дома открывать. А тут еще одна железка. И все. Идея тухнет до следующего раза.
$179 за топовую версию с 32Гб это уже совсем не мало. Это уже сопоставимо с каким-нить мини ПК на интеле, там кстати будет и сменная память. И корпус и охлаждение и ссд на 512Гб.
Нет не из-за этого. Для того что бы государственное сделать частным, нужно было уничтожить государственность. Вы не заметили что все заводы в России(РСФСР) вдруг стали из государственных частными? Задумайтесь как при нормально работающих институтах власти "Самарский металлургический завод", построенный в 1960 году вдруг в 93 стал частной собственность. Для того что бы устроить великий раздербан госимущества и резалась страна на части, а так же полностью ломались органы власти.
Новость на iXBT от 6.11.23 "BYD построит свой первый европейский завод". Но не зависимо от того есть там на данный момент завод или нет, это только подтверждает правильность тезиса о том что китайские производители сначала растут на огромном китайском рынке, где правительство им обеспечивает поддержку и продвижение, а потом идут захватывать мировой. Компания BYD существует с 2003 года, 20 лет они жили и развивались на внутреннем рынке, доросли до того, что стали делать электромобилей больше теслы, а теперь начинают экспансию в остальной мир. И такой путь почти каждой китайской успешной компании. И он возможен только из-за очень большого внутреннего рынка. Что мешает мешает делать такое же с производством чипов? Куча автопроизводителей и производителей электроники уже сделали огромный рынок сбыта для китайских чипов. По факту санкции играют сейчас ровно обратную роль, они нарушают устоявшуюся монополию крупных мировых производителей и создают все условия для появления их конкурентов. Сейчас сложно себе представить что AMSL может кто-то заменить, как сложно было представить что клоны айфона с телевизором превратятся в Xiaomi 13T Pro или Huawei P60 Pro.
Думаю что там экономика как строй, на словах это коммунизм, а по факту гибрид. Много ли видели среди экспорта китайский авто компанию BYD? Вообще ни одного не видел. А ведь эта компания производит электромобилей больше чем Тесла. У меня сейчас во дворе( это большой ЖК) точно будет стоят пара электромобилей теслы, BYD не будет ни одного. Наверно в целом вы правы, экономика живет за счет экспорта, но речь именно о стадии роста, сначала активное развитие мелких компаний за счет внутреннего рынка и стимулов на нем, а когда они созрели идут в мир. Речь именно о стадии развития. Причем действуют они всеми доступными методами, копирование, производство по лицензии, сначала производство по лицензии, потом копирование, покупка не китайских компаний и вытягивание всех технологий. И еще заметил одну особенность - если что-то появляется у одного китайского производителя, то это тут же распространяется по всем, такое чувство что правительство заставляет свои компании друг с другом делиться технологиями.
Если смотреть исторически, представить что китай станет лидером производства смарфонов в 2003 году, когда были китайские клоны айфона с телевизором, было вообще невозможно, на смех бы подняли за такое утверждение. А сейчас есть айфон и есть китайские смартфоны, все. Еще самсунг, даже lg сдулся. То же самое сейчас происходит с автомобилями, представить себе Geely Monjaro во времена чери амулет было невозможно, а сейчас отдельные китайские бренды могут очень неплохую конкуренцию составить немецким и иногда японским производителям. Почему вы не верите что то же самое может произойти в области производства оборудования для чипов? У них есть гиганский рынок сбыта, сам китай, на локальном рынке всегда проще развиваться.
Все просто, причина та же по которой с++ программисты не понимают зачем код покрывать 100% юнит тестами. Условно код программы можно разделить на:
1) код который выполняет задачу, как правило это какой алгоритм, у него есть входные данные и выходные
2) код который занимается доставкой данных из разных мест и отправкой результата в нужные места программы или обработки различных действий по результатам(показать попап, обновить БД или еще что).
Причем кода второго типа может быть достаточно много, но он простой, ошибиться можно разве что написав метод с ошибкой или имя переменной, нарушить типизацию или еще что, особенно это важно когда происходит какой-то рефакторинг. Так вот правильность имен переменных, правильность типов, совместимость данных большей частью проверит компилятор во время сборки. А JS исполняется строчка за строчкой и программа содержащая ошибку в JS коде запустится, но работать не будет и вы узнаете о ошибке в название метода или переменной во время работы приложения. Контролировать большое количество такого кода становится проблемой. Я не говорю что компилятор это магическая палка выручалка которая защитит вас от всего на свете, но она защитит вас от ошибки в именах методов, классов, функции, от несоответствия типов, а если применять мета программирование(шаблоны) еще много от всего.
И конечно же с++ код легче отлаживать, отладка с++ кода реализована наверно в любом компиляторе и на любой платформе, от программирования микроволновок, до микро сервисов(да на с++ то же можно писать микро сервисы, причем для этого есть очень крутые системы типа CORBA которым 100500 лет). Беда многих молодых программистов в том что они даже если слышали про CORBA открывают ее документацию смотрят минут 15 и закрывают, после чего начинают делать JRPC на с++, сталкиваются с тем что не понимают как быстро написать парсер json после чего идут смотрят на Go, где это пишут чуть ли не во введение и решают писать на нем. Я не против Go, это хороший язык, но неплохо было бы знать какие методы и решения использовались до того как появился Go, возможно там будет что-то более мощное и функциональное. Или еще пример, опять же про тот же json, есть такая библиотека simdjson, у нас получилось на современном компьютере парсить 3Гб json файлов за 150мс на нем. Кто-то может похвастаться таким перфом?
Или boost::graph, я половины этой библиотеки не понимаю, но даже то что понимаю позволяет решить все задачи на графах которые у меня когда либо возникали, причем достаточно компактными 15-20 строчками кода, да это будут очень странные 20 строчек кода, на которые посмотришь и такой, чё???? Но работать будет быстро и лучше ничего нет, вообще. Как и CGAL это наверно самая фундаментальная и комплексная геометрическая библиотека которая существует.
"Если скинете примеры", что скидывать то? есть правила сборки qt приложения, они примерно такое, qml файлы декларируются в qrc файле, дальше при сборке весь контент перечисленный в qrc файле трансформируется в с++ код, прим в исходнике base64 текстом все бинарные фалы идут. Потом компилятор все собирает в бинарные файлы. Данные падают в секцию данных и доступны грубо говоря как глобальные переменные, обертка над ресурсной системой позволяет их доставить типа QFile("qrc://main.qml"), все. Для того что бы собрать проект нужна любая система сборки которая позволяет делать правила компиляции для файлов. Сборка qt/c++ приложения это последовательный вызов определенных утилит, которые делают определенные трансформации над данным и в итоге получается бинарный файл. Для того что бы это все руками не настраивать есть CMake он интегрируется в Gradle, и с помощью него же генерируется xcode проект где уже все настроено. Для того что бы писать на qt достаточно минимальных знаний cmake, после чего вы получите проект для MSVS, XCode, такие среды как CLion и QtCreator могут прямо открывать Cmake файлы и показывать из них проекты. Отладчик QML вы кроме QtCreator больше нигде не получите, но там особо отлаживать нечего, это статическая верстка и очень тривиальный код.
"для iOS в альфе сейчас" В 2012 году уже писал на Qt/QML большой коммерческий проект под Android.
"с coroutines приятнее и удобнее чем с потоками" так используйте они же есть уже в стандарте. Но операционка все равно оперирует потоками и семафорами, хотите быстро и полный контроль тут без шансов, вам нужно манипулировать самым близким уровнем к железу, а это с++.
"где мне или кодогенерация или gson распарсят json без особых стараний с моей стороны" Как выглядит парсинг JSON в с++:
namespace ns {
struct person { std::string name; std::string address; int age; };
}
NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE(person, name, address, age)
Сложно?
Для с++ сделали пакетный менеджер уже несколько лет, даже несколько есть конан, не использовал, есть vcpkg там 2200 библиотек. Есть такие библиотеки которые невозможно переписать на что-то иное, максимум вокруг с++ написать обертку в нужный язык, boost::graph, opencv, curl, jolt, box2, bullet, openimage, spirv, implot, sqlite3, libtorrent, tesseract, cgal. Каждая из этих библиотек это сотни человеколет работы, мы с вами вместе за всю жизни не напишем даже одну из этих библиотек, даже если всю жизнь будем работать только над этим.
Скорее всего для многих написали обертки в котлин для Qt даже есть обертка в питон. Но зачем нужно ждать пока кто-то сделает и зачем нужна обертка, если все равно основные библиотеки все на с++ написаны, бери исходник, даже WebRTC это с++ в основе, там без шансов быть чему-то иному.
Вы просто попробуйте решить задачу редактора любой игры прям на девайсе. Тут же столкнетесь с кучей проблем, если только у вас движок игры будет не на котлине, а на котлине он врядли будет, просто не потянут не по перфу не по сложности, все это тут же сожрет всю память сегментацией и будут дикие фризы во время сборки мусора, это кое как решили в юнити, и то, вместо фриза на кадр, просадки на несколько кадров. Мощь с++ не в том что он какой-то удобный или в его синтаксическом сахаре, его мощь в библиотеках которые решают любую задачу которые можете придумать и скорее всего они уже лежат на гитхабе и добавлены в vcpkg.
IDE может быть любой, красота Qt в том что вы можете писать программу полностью на десктопе под десктоп, без эмуляторов, симуляторов и прочего, почти 95% кода так можно написать и остается 5% которым потребуется платформенно зависимые штуки, скорее всего это будут пуши, может быть работа с камерой. Нет проблемы разрабатывать на Qt используя андроид студию. В разработке на qt строго говоря вы вообще не привязаны к IDE. Насчет сложности С++ разговоры сильно преувеличены, тут конечно вкусовщина, это мой основной язык разработки на протяжение наверно 20 лет, но у него есть плюс, даже два, он кроссплатформенный, программа написанная на котлин или Swift будет работать только под одной платформой, и если их выбрать как основу, вам нужно иметь две команды которые будут фактически делать два приложения, программа написанная на с++ будет работать везде, конечно же мы говорим про логику, а не взаимодействие с ОС специфичными. "сам kotlin гораздо приятнее" Вы же понимаете что это вкусовщина, язык должен позволять выполнять определенные задачи, грубо говоря реализовывать алгоритм, все Си подобные языки более менее одинаковые (если не нравится си подобный, можно сказать оберон подобные или процедурные или ООП, кому как нравится). В целом что бы решать почти все задачи достаточно функций и структур, остальное это синтаксический сахар, корутины, замыкания, стандартная библиотека и прочее и прочее, это удобные помощники, но не больше.
"Непонятки с QML/C++ что где писать и на что ориентироваться" стоит начать и все сразу станет понятно, с++ это строительные блоки QML это клей который склеивает их между собой. С++ строго типизированный язык, на нем нужно писать 90% кода, в случае если что-то пойдет не так, программа как правило не соберется(имею ввиду не соответствие типов), QML дает свободу в виде отсутствующей типизации, на нем удобно склеивать между собой различные блоки сделанные на с++, но если вы нарушили типизацию узнаете(как в питоне) в момент выполнения программы. QML по большей части декларативный язык, это такой HTML на стероидах, в нем можно писать блоки на JS, но лучше что бы это были простые функции проброса данных в с++ и логику на js лучше вообще не писать. Ну и мегафича Qt/QML это свои виджеты, у вас есть RHI(можно считать что это OpenGL) и делай что хочешь и как хочешь, шейдеры, многопоточный рендер, все сразу, любые капризы, вот тебе gl контекст делай шо хочешь. У нас представление игры в тулинге фактически через один виджет реализовано, просто сделали его оберткой вокруг движка и игры.
Писать мобильные приложения на десктопе без эмуляторов и прочего это кстати очень удобно и значительно быстрее. Просто делаете приложение, оно запускается, отлаживается, все как в любом десктопном приложение, любой профилировщик втягивается, потом шаманите с системой сборки, где МОКи для мобильно специфичных задач подменяются на реальные при сборке и вырезается все что вы прикрутили на десктопе для отладки и профилирования и прочие хелперы. И хлоп на выходе мобильное приложение, причем у себя на машине вообще не собираю его, все делает CI. Я просто пишу приложение как для десктопа, а потом магическим образом получаются ios и android приложения.
Не понимаю почему Qt/QML так мало используют в мобильной и уж тем более в десктопной разработке. Очень удобный фрейморк или СДК, кому как нравится, работает быстро, накладные расходы на кроссплатформенность минимальные, платформенно специфичные баги бывают, но достаточно редко. Я его использую для разработки внутреннего тулинга в геймдеве, причем уже в двух компаниях. Альтернатива электрон, но смотрю на слак и скайп, постоянно то одно то другое бажит и как-то желания даже смотреть его нет. Скайп был вообще мегастабильный до перехода на электрон. Вайбер и Телеграмм на qt сделаны, телеграмм конечно достаточно специфично qt использует )) но то ладно.
По теме топика, какую версию Qt используете?
Не знаю о чем вы конкретно, но у меня лента просто на монитор сзади приклеена, и просто светит одним светом, красиво выглядит и глаза меньше устают, плюс света больше становится, не могу работать в полумраке, с наступлением осени пользуюсь каждый день.
Похоже что мастдай таки наступил для отдельно взятых версий. Только не знаю радоваться или грустить.
Шумиха, думаю, в следствие новизны подхода, первые кто сделал десктопный арм в массы. Мне то же непонятна шумиха вокруг десктопных арм процов. У эпла хорошие процессоры получились, но думаю не потому что арм, а потому что эпл их делал.
"Зачем сравнивать с Ryzen?" Сравнивать больше не с чем, назвался десктопным процом сравнивайся с десктопом. Про и Макс это процы для ноутов, наверно их сравнивать надо с Райзен для ноутов, а вот Ультра это чисто десктопный проц. А зачем сравнивать, а как еще разобраться в вопросе. Условно у меня устаревает компьютер, возникает вопрос, что лучше собрать х86, или купить мак студио, или может ноутбука хватит с подключением внешнего монитора и переферии, лично для меня вопрос так стоит. Условные $3,5к за апловский ноут звучит много, но у меня текущий комп вообще ни разу не дешевле был, а может и дороже, думаю цифра ближе к $4.5к(одна 4090 с блоком питания больше $2.5). Пришлось немало сил приложить что бы комп был тихим, но печка еще та, зимой хорошо, летом реально кондиционер приходится посильнее включать. 600-700Вт в при нагрузке на проц и видяху это нормально.
Пока м2 Ультра выглядит нормально относительно топовых Райзен, но если брать Тредриперы, м2 начинает проигрывать.
У меня далеко не рядовые запросы, пишут с++ код примерно 5-8 часов в день, хочется что бы все происходило настолько быстро насколько оно может быть, поэтому приходится откидывать существенные деньги на железо, каждый раз плачУ и плАчу, но потом оно себя оправдывает. Задержки на компиляцию минимальные, даже полные ребилды, не успеваешь из мысли выйти. Помню времена когда рядовой проект мог собираться 10 минут, вот это да, уже забыл что делал пока сборку дождался.
Не совсем понятен ваш агрессивный коммент в мою сторону. Я бы приложил графки потребления, если бы они были, но в своем посте четко обозначил эту тему. "По потреблению энергию м2 конечно же далеко впереди".
"А если ему поднять TDP до 120 вт, кто выиграет?"
В этом вопросе и заключается мой комментарий, который критикует тезис в статье, о том что архитектура арм принципиально выигрывает у х86. Только отталкиваюсь от производительности, именно последние проценты перфа раздувают энергопотребление процессора и превращают его в печку. В этом и вопрос, какое будет энергопотребление условного м2' если его по перф на существующем техпроцессе увеличить на те самые 25% на которые он отстает, если мы говорим про одно ядро и 160% если говорим про все ядра. Не выйдет ли так что энергопотребление примерно одинаковое получится с х86.
Мне кажется что качество процессора, что бы не скрывалось под словом "качество" определяет техпроцесс, транзисторный бюджет и лимиты энергопотребления, а архитектура, если она не имеет значительных ошибок в реализации, в последнею очередь. Переход апл на арм, на мой взгляд, обусловлен не причинами превосходства арм над х86, а другими:
экономическими - закупать чужой процессор дороже чем делать свой
гибкостью в разработке - свои процессор можно наделить дополнительными блоками под определенные задачи, безопасность, распознавание образов и прочее, что эпл периодически делает для айфона.
большей независимостью выстраивать бизнес процессы, не надо ждать релиза интел новых процессоров, можно делать ровно такие процессоры какие нужны апл, а не договариваться о этом с интел.
То же самое касается и нвидии. амд уверено выступает и на рынке видеокарт и на рынке процессоров, интел был только на рынке процессоров, но с недавних пор штурмуют рынок видеокарт, нвидия живет только на рынке видеокарт, и не имеет выхода на рынок процессоров, х86 для них закрыт, никто не продаст лицензию, остается только арм, выпуск своих процессоров позволит на равных конкурировать с амд и интел по охвату сегментов рынка.
Мне как пользователю нравится конкуренция арм против х86, конкуренция четырех компаний на всех сегментах рынка против конкуренции пары компаний, но как с++ программисту добавление еще одной архитектуры это конечно тот еще геморрой, то какие-то нужные библиотеки имеют в себе асемблерные куски и не портированы под арм, то непойми как CI настроить на кросскомпиляцию.
Попробуйте такой же тест провернуть установив на свой компьютер линукс, где-то читал что у виндовса медленно происходит оперировать объектами ядра ос, открывать мьютексы, файловые дескрипторы. Я же говорю чисто в лоб сравнивать процессоры сложно, получается или сравнение ос или сравнение компиляторов. Что бы сравнить прям чисто процессор нужно брать синтетику, синебенч это чистая синтетика, но потом получается как у вас. У меня то же такой пример, проект на с++, на виндовс сборка 5 минут, на маке 1:30, но это больше говорит о том что кланг работает быстрее чем компилятор микрософт.
Еще важен момент, что м2 опережает ваш процессор на поколение, м1 корректно сравнивать с 5950х, а м2 корректно сравнивать с 7950х, у м2 и 7950х более менее одинаковое время релиза и одинаковый техпроцесс.
У меня есть стойкое чувство что определяющим фактором является не архитектура, а техпроцесс и тепловой пакет, все остальное будет давать проценты разницы. х86 процессоры можно упрекнуть что они делают двойную работу, им нужно большие команды разбивать на маленькие, за арм процессор это делает компилятор. Битва команд процессоров была важна в 70х-80х, когда действительно писали на ассемблере и большие команды(скорее подходящее слово комплексные) были банальным удобством программиста, кому захочется писать 5 команд когда можно написать одну. Тогда х86 победил арм, сейчас выходит что у арм процессора всегда будет один блок проще, а значит он будет меньше транзисторного бюджета использовать и меньше потреблять. Насколько большая работа по разбивке комплексных команд на мелкие я не знаю, насколько она много потребляет энергии и занимает транзисторного бюджета то же, но такой аргумент в против х86 привести можно.
"то чипы на её базе получаются весьма производительные плюс энергии потребляют меньше, чем x86-решения."
Вот как выглядят "весьма производительные" чипы в тестах. По потреблению энергию м2 конечно же далеко впереди, но по перфу пока проигрывает. И, возможно, если это самое "пока" попробуют исправить то и энергопотребление может подрасти. Тест синебенч это конечно специфичная задача, но других прямых сравнений сходу не нашел, мне интересно было бы сравнить время компиляции, но сравнить его достаточно сложно, если взять visual studio и xcode получится сравнение компиляторов, а это не то что хотелось бы.
А stable diffusion умеет их подхватывать обе или надо как-то с бубном танцевать?
Как выбрать... если домой, у вас есть один вариант - 4090, на А100 и прочие денег не хватит, ценник стартует от 800 тр, стартует(!). В то же время бессмысленно пытаться что-то сделать на 16Гб, ну что-то получится но перф и модели будут маленькие, 4090 - это входной билет по памяти и перфу, цена в 200 тр еще хоть как-то подъемная что бы купить.
М.2 один - значит резервирования не будет, диск сгорит - досвиданья данные. Подключить пулы жестких дисков по USB то же так себе идея. Они менее стабильные чем SATA, в том плане что могут отваливаться во время месяцев непрерывной работы.
$500 за синолоджи отдавать это действительно так себе идея. Примерно за $300(если не считать диски) собрал себе NAS и немного бушного железа.
ASUS Prime B550M, Ryzen 5 3600x, 32Gb (максимум можно 128Gb), затычка GeForce GT 1030 с пассивным охлаждением. Корпус Fractal Design Define R5. Аналоги по процу и памяти от синолоджи стоят за $1000.
А как вы планируете к NAS на одноплатнике подключать массив жестких дисков? Там же сата портов нет. Ну и корпус хочется же все в одном.
Куда видео 8к подключать?
Про VR вроде у топовых видеокарт не всегда хватает мощности тянуть игры с хорошей графикой?
Может NAS делать? Но для NAS нужно несколько(желательно от 3) sata портов. Что бы пулл зеркальный сделать(для важных данных) и пулл для всякого хлама, но на одном hdd.
Вроде изначально идея малины и подобных это быть дешевыми и позволять рулить разной периферией, шаговыми двигателями, релешками и прочим, при этом будучи полноценным компьютером не обрекать разработчика на ад программирования микроконтроллеров, от которого у обычного десктопного разработчика взорвется мозг(понятно утрирую). И вот $180 это уже не дешево, да железо выглядит на грани ультрабюджетных исторически десктопных производителей. И мне даже несколько раз хотелось купить таких штук 10 и попробовать поупражняться в разработке под кластер. Или купить как комп для фана, типа показывать друзьям какой маленький и дешевый и работает как полноценный, но каждый раз останавливался. Ибо не мог понять что с ним все же делать.
Логика такая: мне же нужен типа десктопный, значит надо памяти 16Гб, а сейчас 32Гб(потому что памяти не бывает много), хм еще корпус, охлад нужен, карта памяти, ну на побольше. Ну ок, получается вроде норм, даже можно будет отдать ребенку в качестве первого компа. Но тут по цене выскакивает мини-ПК на интеле который чуть дороже... ммм так может мини-пк взять, уже все собрано и корпус нормальный... И зачем мне еще один комп, у меня из старого железа уже можно и так датацентр дома открывать. А тут еще одна железка. И все. Идея тухнет до следующего раза.
$179 за топовую версию с 32Гб это уже совсем не мало. Это уже сопоставимо с каким-нить мини ПК на интеле, там кстати будет и сменная память. И корпус и охлаждение и ссд на 512Гб.
Нет не из-за этого. Для того что бы государственное сделать частным, нужно было уничтожить государственность. Вы не заметили что все заводы в России(РСФСР) вдруг стали из государственных частными? Задумайтесь как при нормально работающих институтах власти "Самарский металлургический завод", построенный в 1960 году вдруг в 93 стал частной собственность. Для того что бы устроить великий раздербан госимущества и резалась страна на части, а так же полностью ломались органы власти.