А кто вам сказал что я работаю с нейросетями? Я так поиграться дома. Видяху вообще в игры играть купил. Моя работа сидеть буковки в IDE в нужных местах вбивать. Работа вообще не мое, я щитаю ))
А если серьезно то мои суждения основаны на работе программиста, пишу код на с++, а с++ любит долго компилироваться, вот и приходится на работе всегда первым делом выбивать себе комп близкий к топовому конфигу, ждать 10-15 минут сборку проекта - это наймите кого-нить другого. На вопрос "а че ты хочешь такой жирный конфиг," - ответ примерно такой, я вроде пришел в топовую компанию работать, а тут комп не могут купить хотя бы такой же как у меня дома стоит. Скрипят, хмуряться, но комп выдают через время. А дома у меня стоит уже топовый амдешный 16 ядерник. Так что спорить сложно. Ну и оно реально непонятно зачем ждать, если можно не ждать. Ладно бы просил там два двухпроцессорный зион, а так просто топовой домашний проц за 750 баксов, ну епта, вы топовая ИТ компания или подвал дяди ашота.
Я сравнивал на SD, 4080 показывала производительность почти в два раза меньше чем 4090. Упомянутая вами 3060Ti дает результаты 23 изображения в минуту, против 75 у 4090. Кому-то и кобыла невеста. У меня тренировка на 4090 моего небольшого датасета занимала около 8 часов. Сложно представить как работать, если время будет еще в три раза больше. Для целей разобраться, попробовать, что-то понять 3060 пойдет, но работать, именно выполнять задачи для работы за деньги, где когда время инженера за месяц заботы будет стоить как две 4090 имеет смысл покупать только такие видеокарты. Или идти в облака. Если у тебя месяц времени работы сотрудника стоит как железка и сотрудник упирается в производительность железки, то тут выход один купить железку. Если ты энтузиаст и тебе нужно разобраться в вопросе что бы стать тем самым сотрудником время которого будет стоит как три железки - тогда покупай то на что хватит денег что бы минимально вписаться в требования.
К сожалению для работы, а не поиграться, подходит только 4090. Так что вариант такой, что вариантов нет. На 4080 у меня работало, но скорость крайне медленная, особенно если учить нейронки.
Нет, не так, с++ очень стабилен в поддержке и всегда имеет обратную совместимость(был один или два случая когда это правило нарушилось). Наверно есть библиотеки которые могут перестать работать, но таких случаев не помню. Многие с++ библиотеки слишком большие что бы быть заброшенными. Например curl это часть операционной системы линукс и с некоторых пор виндовс. Qt развивается с 93 года или что-то около того. Многие библиотеки с++ это матрешки, которые зависят от более мелких библиотек, а те еще от более мелких. К примеру openimageio зависит от 98 других библиотек. Так же в с++ очень мало зоопарка библиотек, никто не будет писать аналог zlib(библиотека сжатия данных).
Бегло посмотрел репозиторий что вы дали, нашел интересную штуку JoltPhysics.js( A WebAssembly port of JoltPhysics) это то о чем говорил, с++ проникает условно в мир других языков через порты и обертки под эти языки, уверен есть порт для питона и других языков, но внутри там будет с++ библиотека.
Еще почему-то в подобных разговорах принято считать что программисты с++ думаю только о нем и ничего вокруг не видят, в "мире с++" вполне нормальная практика брать и вкручивать в приложение другие языки, почти все игровые движки созданные на с++ имеют внутри себя интерпретаторы(или jit компиляторы) других языков для упрощения написания логики, как правило это lua или python, Unreal Engine внутри содержит графический язык BluePrint. Qt сейчас переходит на QML это использование с++ для базовых функции и склеивание их через js.
Так же нет проблемы двигаться вниз по языковым абстракциям и спускаться до ассемблера, если есть желание использовать какие-то низкоуровневые процессорные расширения типа AVX, почти все видео кодеки туда спускаются, но это порождает определенные трудности в переносимости под другие типы архитектур.
Почитал статью и так и не понял чем раст лучше, наверно это неплохой язык, но что мешает использовать пул потоков в с++, почему автор статьи считает что многопоточное программирование на с++ это потоки и мьютексы?
Мое понимание разработки на данный момент сводится к тому что можно очень долго выяснять какой язык лучше и чем на, скажем так, академических примерах, беда в том что это сильно далеко от реальной жизни. Мне не нужен язык, мне нужно программу делать, а для этого нужны библиотеки, очень много библиотек, на данный момент в составе vcpkg около 2,5 тысяч библиотек. Это код который у вас сразу и скорее всего без проблем соберется под все распространённые настольные и мобильные платформы. Не представляю что должно случиться что бы библиотека CGAL была переписана на другой язык. В нее закопаны наверно сотни человеколет работы. И это только одна библиотека из множества других. И такие библиотеки можно перечислять очень долго: SQLite, Qt, curl, boost graph, openimageio, eigen3, lua, imgui... У меня в глазах ужас при мысли как каждую из них можно было бы портировать на другой язык, не говоря уже о всех вместе.
Из описания не понял одного, как соблюдается закон сохранения энергии. Перенос протона и прочее это конечно хорошо, но откуда откачивается энергия? Если выкопать большую яму рядом с озером, то под действием гравитации туда будет сливаться вода вода и пока она сливается можно вырабатывать электричество. Что делать когда яма наполнилась? Отсюда очень много вопросов. Так то и элемент Пельтье работает очень неплохо, до тех пор пока есть разность теплового потенциала. Но вы же понимаете что поставить холодильник, обложить его стенки элементами Пельтье и запитать от них компрессор не получится, ну как получится, только работать не будет, в лучшем случае получите аналог маятника.
Уже было много странных работ которые обещали чудо вот-вот, недавно был хайп вокруг неинерциального двигателя(EmDrive) или как-то так, который должен был создавать тягу не реактивным движение. Опять же чем закончился хайп вокруг анализа одной капли крови(Theranos) (тюремными сроками и сериалом на нетфликсе). Много что бы открыто случайно. Не припомню случаев когда что-то работало, но ему не было объяснения (не говорю что такого не было, говорю что я не знаю таких случаев, если кто-то приведет примеры буду рад узнать новое).
Новость на 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 привести можно.
А кто вам сказал что я работаю с нейросетями? Я так поиграться дома. Видяху вообще в игры играть купил. Моя работа сидеть буковки в IDE в нужных местах вбивать. Работа вообще не мое, я щитаю ))
А если серьезно то мои суждения основаны на работе программиста, пишу код на с++, а с++ любит долго компилироваться, вот и приходится на работе всегда первым делом выбивать себе комп близкий к топовому конфигу, ждать 10-15 минут сборку проекта - это наймите кого-нить другого. На вопрос "а че ты хочешь такой жирный конфиг," - ответ примерно такой, я вроде пришел в топовую компанию работать, а тут комп не могут купить хотя бы такой же как у меня дома стоит. Скрипят, хмуряться, но комп выдают через время. А дома у меня стоит уже топовый амдешный 16 ядерник. Так что спорить сложно. Ну и оно реально непонятно зачем ждать, если можно не ждать. Ладно бы просил там два двухпроцессорный зион, а так просто топовой домашний проц за 750 баксов, ну епта, вы топовая ИТ компания или подвал дяди ашота.
Я сравнивал на SD, 4080 показывала производительность почти в два раза меньше чем 4090. Упомянутая вами 3060Ti дает результаты 23 изображения в минуту, против 75 у 4090. Кому-то и кобыла невеста. У меня тренировка на 4090 моего небольшого датасета занимала около 8 часов. Сложно представить как работать, если время будет еще в три раза больше. Для целей разобраться, попробовать, что-то понять 3060 пойдет, но работать, именно выполнять задачи для работы за деньги, где когда время инженера за месяц заботы будет стоить как две 4090 имеет смысл покупать только такие видеокарты. Или идти в облака. Если у тебя месяц времени работы сотрудника стоит как железка и сотрудник упирается в производительность железки, то тут выход один купить железку. Если ты энтузиаст и тебе нужно разобраться в вопросе что бы стать тем самым сотрудником время которого будет стоит как три железки - тогда покупай то на что хватит денег что бы минимально вписаться в требования.
Ссылка на тесты перфа
https://cdn.mos.cms.futurecdn.net/RtAnnCQxaVJNYgA4LbBhuJ.png
К сожалению для работы, а не поиграться, подходит только 4090. Так что вариант такой, что вариантов нет. На 4080 у меня работало, но скорость крайне медленная, особенно если учить нейронки.
Нет, не так, с++ очень стабилен в поддержке и всегда имеет обратную совместимость(был один или два случая когда это правило нарушилось). Наверно есть библиотеки которые могут перестать работать, но таких случаев не помню. Многие с++ библиотеки слишком большие что бы быть заброшенными. Например curl это часть операционной системы линукс и с некоторых пор виндовс. Qt развивается с 93 года или что-то около того. Многие библиотеки с++ это матрешки, которые зависят от более мелких библиотек, а те еще от более мелких. К примеру openimageio зависит от 98 других библиотек. Так же в с++ очень мало зоопарка библиотек, никто не будет писать аналог zlib(библиотека сжатия данных).
Бегло посмотрел репозиторий что вы дали, нашел интересную штуку JoltPhysics.js( A WebAssembly port of JoltPhysics) это то о чем говорил, с++ проникает условно в мир других языков через порты и обертки под эти языки, уверен есть порт для питона и других языков, но внутри там будет с++ библиотека.
Еще почему-то в подобных разговорах принято считать что программисты с++ думаю только о нем и ничего вокруг не видят, в "мире с++" вполне нормальная практика брать и вкручивать в приложение другие языки, почти все игровые движки созданные на с++ имеют внутри себя интерпретаторы(или jit компиляторы) других языков для упрощения написания логики, как правило это lua или python, Unreal Engine внутри содержит графический язык BluePrint. Qt сейчас переходит на QML это использование с++ для базовых функции и склеивание их через js.
Так же нет проблемы двигаться вниз по языковым абстракциям и спускаться до ассемблера, если есть желание использовать какие-то низкоуровневые процессорные расширения типа AVX, почти все видео кодеки туда спускаются, но это порождает определенные трудности в переносимости под другие типы архитектур.
Почитал статью и так и не понял чем раст лучше, наверно это неплохой язык, но что мешает использовать пул потоков в с++, почему автор статьи считает что многопоточное программирование на с++ это потоки и мьютексы?
Мое понимание разработки на данный момент сводится к тому что можно очень долго выяснять какой язык лучше и чем на, скажем так, академических примерах, беда в том что это сильно далеко от реальной жизни. Мне не нужен язык, мне нужно программу делать, а для этого нужны библиотеки, очень много библиотек, на данный момент в составе vcpkg около 2,5 тысяч библиотек. Это код который у вас сразу и скорее всего без проблем соберется под все распространённые настольные и мобильные платформы. Не представляю что должно случиться что бы библиотека CGAL была переписана на другой язык. В нее закопаны наверно сотни человеколет работы. И это только одна библиотека из множества других. И такие библиотеки можно перечислять очень долго: SQLite, Qt, curl, boost graph, openimageio, eigen3, lua, imgui... У меня в глазах ужас при мысли как каждую из них можно было бы портировать на другой язык, не говоря уже о всех вместе.
14нм - это уровень Ryzen первого поколения, это даже по современным меркам вполне хороший процессор.
Из описания не понял одного, как соблюдается закон сохранения энергии. Перенос протона и прочее это конечно хорошо, но откуда откачивается энергия? Если выкопать большую яму рядом с озером, то под действием гравитации туда будет сливаться вода вода и пока она сливается можно вырабатывать электричество. Что делать когда яма наполнилась? Отсюда очень много вопросов. Так то и элемент Пельтье работает очень неплохо, до тех пор пока есть разность теплового потенциала. Но вы же понимаете что поставить холодильник, обложить его стенки элементами Пельтье и запитать от них компрессор не получится, ну как получится, только работать не будет, в лучшем случае получите аналог маятника.
Уже было много странных работ которые обещали чудо вот-вот, недавно был хайп вокруг неинерциального двигателя(EmDrive) или как-то так, который должен был создавать тягу не реактивным движение. Опять же чем закончился хайп вокруг анализа одной капли крови(Theranos) (тюремными сроками и сериалом на нетфликсе). Много что бы открыто случайно. Не припомню случаев когда что-то работало, но ему не было объяснения (не говорю что такого не было, говорю что я не знаю таких случаев, если кто-то приведет примеры буду рад узнать новое).
Новость на 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 привести можно.