Чем сейчас в линуксе музыку слушают? Несколько лет не пользовался, помню про Амарок, сунулся нет его, Dead Beaf есть и работает, может что-то еще есть?
Чуваки вообще не паляться "которые должны были быть заранее закуплены для того, чтобы в случае выигрыша тендера мы успеть его исполнить в обозначенные сроки."
То есть тендер написан так что его невозможно исполнить не имея заранее оборудования. Интересно, а почему так? Это закупка оборудования или пересадка почки? Куда так спешат? А нет ли тут случайно изначальных договоренностей о том кто этот тендер выиграет. И исполнители такие рисковые, готовы деньги на все оборудование потратить заранее, "без уверенности" в том что тендер выиграют, отчаянный отечественный бизнес. Палятся прям не отходя от кассы.
А кто вам сказал что я работаю с нейросетями? Я так поиграться дома. Видяху вообще в игры играть купил. Моя работа сидеть буковки в 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 использует )) но то ладно.
Не знаю о чем вы конкретно, но у меня лента просто на монитор сзади приклеена, и просто светит одним светом, красиво выглядит и глаза меньше устают, плюс света больше становится, не могу работать в полумраке, с наступлением осени пользуюсь каждый день.
Чем данный метод лучше использования AUTOMATIC1111? ( https://github.com/AUTOMATIC1111/stable-diffusion-webui )
Чем сейчас в линуксе музыку слушают? Несколько лет не пользовался, помню про Амарок, сунулся нет его, Dead Beaf есть и работает, может что-то еще есть?
Чуваки вообще не паляться "которые должны были быть заранее закуплены для того, чтобы в случае выигрыша тендера мы успеть его исполнить в обозначенные сроки."
То есть тендер написан так что его невозможно исполнить не имея заранее оборудования. Интересно, а почему так? Это закупка оборудования или пересадка почки? Куда так спешат? А нет ли тут случайно изначальных договоренностей о том кто этот тендер выиграет. И исполнители такие рисковые, готовы деньги на все оборудование потратить заранее, "без уверенности" в том что тендер выиграют, отчаянный отечественный бизнес. Палятся прям не отходя от кассы.
А кто вам сказал что я работаю с нейросетями? Я так поиграться дома. Видяху вообще в игры играть купил. Моя работа сидеть буковки в 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 используете?
Не знаю о чем вы конкретно, но у меня лента просто на монитор сзади приклеена, и просто светит одним светом, красиво выглядит и глаза меньше устают, плюс света больше становится, не могу работать в полумраке, с наступлением осени пользуюсь каждый день.
Похоже что мастдай таки наступил для отдельно взятых версий. Только не знаю радоваться или грустить.