MS Edge был и остается незаменимым браузером для слабенького и/или устаревшего железа, ни никакого другого разумного альтернативного варианта для ноута 15-летней давности особо нет
На старом ноутбуке с 1GB оперативки без disk swap, MS Edge легко тянет несколько открытых вкладок, даже относительно тяжеловесных, вроде Telegram или Skype - в то время как другие браузеры, даже будучи единственным активным пользовательским приложением в системе, начинают жаловаться на нехватку памяти и почти сразу обрушивать вкладки
Не уверен как это именно устроено внутри MS Edge, но по всей видимости он как-то очень быстро умеет "замораживать" вкладки в таком случае, поскольку при переключении явно заметен эффект, что вкладка загружается заново - но комфорту работы это не мешает, да чуть медленее, зато очень стабильно без крашей вкладок
Идея для размышления для адептов LLM - а почему не считать github.com новым сильным искусственным интеллектом? Там расположены большие объемы качественного и рабочего программного кода, библиотек, и в отличие от результатов LLM-помоек, все еще компилируется и работает!
Еще google.com - тоже сильный искусственный интеллект, ведь он может ответить на большое количество вопросов, причем без галлюцинаций. А stackoverflow.com - этот вообще умеет разрабатывать на множестве языков программирования, исправлять ошибки компиляции и исполнения, советовать best practices, ревьюить код и даже решать задачи по computer science!
Что-то не складывается, да? А вот когда все вышеперечисленное заскрапили в offline-базу и прикрутили к ней поиск на нативном языке, то внезапно оказалось, что пользователи наделяют наличием интеллекта не саму петабайтную базу знаний с заготовленными ответами, а галлюционирующий поисковик по этой базе знаний
>ИИ пройдёт авторитетный IQ-тест MENSA летом 2025 года, а к 2026 году ИИ сможет сам создавать другие нейросети
Нет никаких сомнений, чо ИИ сможет решать всякие сложные задачи, синтезровать программные и в будущем аппаратные решения. Только большой вопрос, появится ли хотя бы какой-то минимальный ИИ к 2025 году? Alphacode что-то заглох, по крайней мере ничего не публикуют уже год, что грустно, а других известных ИИ что-то не видно в публичном пространстве :(
Жаль что тему с ИИ как будто бы не развивают (по крайней мере публично), а все информационное поле завалено бесполезными LLM-бредогенераторами, которые от ИИ на порядок дальше, чем банальный поисковый алгоритм Гугла, оптимизатор в LLVM или предсказатель в процессоре - вот где интеллект, а не тупая хайповая болталка на около-цифровые темы
За работу мозга не скажу, насколько мне известно, до сих пор не существует общепризнанной непротиворечивой модели его работы. Дискуссии вида естественный/искусственный интеллект это заведомо неконструктивно, холиварно и не особо интересно.
Вот что действительно интересно, это настоящий искусственный интеллект, или лучше абстрактный интеллект. Идея примерно следующая - по аналогии как в физике энтропия в какой-то мере характеризует "качество" энергии для ее последующего использования, так же в мире информации и формальной логики есть аналогичная характеристика - к примеру, конкретная тройка чисел a^n+b^n != c^n - это "низкокачественная" информация, а вот запись доказательства теоремы в языке формальной логики - "высококачественная" информация.
Основное качество интеллекта - умение по наличию входной "низкокачественной" информации получать "высококачественную", то есть в какой-то мере более сжатую, и условно говоря, отражающую реальные взаимосвязи в логическом (математика) или естественном (физика).
При таком определении всякие ИНСы и *GPT не только не являются интеллектом, но наоборот - строго являются его противоположностью. Имея на входе эксабайты очень "высококачественной" информации, взятой из научных статей, форумов с решениями задач, готовых миллиардов/триллионов строк качественного кода и так далее - ИНС способна генерировать только более "низкокачественную" информацию, но никогда не более "высококачественную".
За счет огромного входа для обучения и очень высокого качества информации в нем, падение качества на выходе ИНС недостаточно, чтобы опуститься до уровня рандомного шума, поэтому выход получается осмысленным, и иногда полезным. Однако повышение качества информации на выходе ИНС по сравнению с ее входом чисто физически невозможно, т.е. ИНС никогда не сможет решать задачи более сложные, чем уже были в обучающей выборке. В то время как для настоящего искусственного интеллекта - это как раз и есть основная работа
Невероятный фейспалм каждый раз, когда термины *искусственный интеллект* (ИИ) и *искусственные нейронные сети* (ИНС) используются как взаимозаменяемые вещи
ИНС в принципе не способны на решение инженерных, научных и технических задач, хоть сколько квадриллионов нейронов в них засунуть, поскольку являются просто сортом экстраполяции по набору обучающей выборки. В областях генерации картинок или нетехнического текста это работает великолепно, поскольку эти области не требуют точности и формализма
В случае научно-технических задач подход принципиально иной. Нельзя взять набор формул из формальной теории и по их внешнему виду наэкстраполировать новых знаний, просто смешивая с определенными весами и добавляя случайные символы. Примерно так же, как невозможно доказать теорему Ферма или гипотезу Коллатца, просто перебирая и подставляя в них числа. ИНС любого размера для этих целей по определению бесполезен
ИИ в научно-технической сфере - это в сторону автоматического доказательства теорем, формальной верификации и программ высшего порядка, которые умеют генерировать другие программы и/или проверять их свойства (с учетом ограничения теоремы Райса) и так далее
Есть много интересных достижений ИИ в этой сфере, которые можно осветить, но информационное поле забито бесполезными ИНСами, генерирующими котиков, или переформулирующими готовые ответы из Google или StackOverflow
Какие уроки я извлёк из создания расширения VSCode с помощью GPT-4
То, что в OpenSource находятся настолько гигантские залежи петабайтов кода, что большинство несложных задач, которые можно придумать за 5 минут и реализовать на популярном языке программирования, уже давно написаны?
OpenAI реализовали отличный мультимодальный поисковик, но зачем-то испортили его бесполезным фасадом в виде prompta и ответа на "человеческом языке", вместо того чтобы просто предоставлять качественную выдачу оригинальных URL-ов без каких-либо галлюцинаций и пост-обработки
В этом плане *GPT только очерняют понятие ИИ, поскольку как раз является худшим его представителем - глючным недо-поисковиком по эксабайтам существующей информации, но портящий ее галлюцинациями, даже в примитивной задаче сложения пары чисел
В то же время есть серьезные профильные ИИ-проекты, за которыми действительно будущее AI-разработки, например AlphaCode от DeepMind, который успешно решает немаленький процент олимпиадных задач, и при этом натренирован на выборке в десятках мегабайт (которую можно к тому же загрузить и посмотреть), то есть он действительно в какой-то мере понимает задачу
В отличие от *GPT-помоек, которые просто роются в эксабайтах готовой информации, но никак ее не понимают, а просто подбирают следующие токен вероятностным образом. Жаль, что хайповый продукт с перенасыщенным бюджетом смещает фокус с настоящих AI-разработок в баловство
Нет сомнений, что будущее за AI, в том числе в инженерии и науке, включая разработку, но этот AI очевидно будет (уже есть?) родственником условного AlphaCode или чего-то подобного, а не захайпленной помойки
Сравнения естественного и искусственного интеллекта, к сожалению или счастью, есть очень неконструктивная тема для дискуссии, в которой легко скатиться в псевдо-философию. В конце концов и немного упрощая, все во вселенной состоит плюс/минус из атомов, а значит любой объект как сборник атомов потенциально может обладать и интеллектом, и сознанием - хоть GPT, хотя булыжник валяющийся на дороге. Обсуждать такое для технического ресурса несерьезно, поэтому в исходном комментарии я целенаправленно удержался от любых утверждений о возможностях и сравнении ИИ и мозга
Отличий от огромной поисковой машины, точнее от поисковой машины+авторефератора, так обнаружить не удалось. Тот же пример описания шутки с телефоном и VGA-кабелем, элементарно ищется в Твиттере за историю (разумеется старую историю, когда GPT-3 еще даже в помине не было)
А вообще зачем о чем-то подобном спорить. Лучше пользоваться следующим алгоритмом: 1) Возьмите какой-нибудь кейс из обычной жизни, и придумайте на его основе какую-нибудь несложную, но не примитивную, математическую или физическую задачку 2) Методом аккуратного гугления/яндексования проверьте, что подобная задачка действительно уникальная, иначе вернуться к пункту 1 3) Попросить решение задачи у GPT и проанализировать ответ 4) Методом аккуратного гугления/яндексования проверьте, вам предоставили ответ на какую-то задачу, которая относительно похожа по тексту, но совершенно иная по смыслу 5) Повторить начиная с пункта 1, собирая статистику* для получения или опровержения статистической гипотезы о возможностях ИИ по решению принципиально новых задач
*Как мы помним из матстата, число испытаний необходимо утвердить по проведения эксперимента, чтобы избежать p-hacking-а по вкусу
Забавно конечно наблюдать, как даже вроде бы технически-грамотные инженеры ищут "интеллект" у продвинутой поисковой системы - хотя в принципе ничего нового, в каждую эпоху свои когнитивные искажения
Ответ на механизм "интеллекта" gpt-подобных систем очень простой: люди просто забывают, насколько огромен интернет, и насколько на самом деле плоховато работают классические поисковики. По состояния на 2022ой год, как указывают источники, это около 90 зеттабайт, то есть порядка 9*10^22 байт
На самом деле в интернете обсуждено и написано так много, что гораздо сложнее придумать что-то новое, что не было обсуждено. Школьники и студенты на каждый чих выкладывают задачи с просьбой помочь их решить. Диванные философы регулярно обсуждают вопросы природы сознания, сравнения работы мозга и ИИ и так далее
Единственное что делают gpt-подобные системы - это очень хороший поиск по зеттабайтам информации и реферирование/перефразирование текстов так, чтобы цитата из ответа не искалась дословным поиском (в кавычках) в поисковой системе
Не скажу за гуманитарные и общефилософские области, но при общении с gpt в технических областях всегда одно из двух - либо для ответа бота можно найти один или несколько однозначных источников, откуда ответ скомпонован с небольшими модификациями, или же в ответе бота будет откровенная рандомная галлюцинация
Арифмометр считал быстрее человека еще несколько веков назад, а чат-боты, с которыми можно поговорить о сути бытия, вполне себе были уже в 90ые годы. Здесь более продвинутый поисковик и авто-рефератор, ну ок, круто
Спекулятивное выполнение и теневые регистры же. Вас же не удивляет, что обе ветки if-else выполняются, а когда результат условия становится известен, выбирается только один путь. Спекуляций видимых за MMU/IOMMU видимо все-таки не существует по определению (Кроме хитрых lockless алгоритмов, но там другое - алгоритм умеет rollback-ить определенные жестко фиксированные случаи, которые сам же и спекулирует :)
В каком-нибудь таком случае вполне себе изменит https://godbolt.org/z/brn7brjoE , плюс все __sync_* функции все равно форсированно приводят указатель к volatile, благодаря чему оно верно и компилируется. Условный TBB от Intel тоже вполне себе использует volatile в многопоточном коде Search · volatile (github.com)
В общем, не вижу смысла в дальнейшей дискуссии. Исходный тезис был "multithreading и многопоточность несовместимы", а это не верно. Показать примеры из промышленного кода я не могу по NDA, а сидеть выдумывать аналогичные простые примеры - не вижу смысла
Чтобы подвести bottom line - смысл volatile (не технически, а скорее философски) примерно такой же, как у std::launder - надавать компилятору по рукам, где в высокооптимизированном (и скорее всего массивно-многопоточном) highload-коде проведены ручные микрооптимизации под целевую платформу, и надо отвадить компилятор от неверной кодогенерации :)
Atomic конечно соберется с любым процессором, но может оказаться, что там всадили lock - в каких-то случаях это плюс, но в каких-то лучше пусть не скомпилируется, зато это повод явно разработать lockless-версию для целевой платформы, и не нарваться на lock
Хотя вы конечно скажите `static_assert(std::atomic<T>::is_always_lock_free == true, "LOCK DETECTED ALARM")` - в общем, на вкус, на цвет, и на грануларность контроля :)
Я особенно ничего доказывать не хочу, мне просто слишком резанула глаз цитата про единственное исключение - все-таки исключение-то не единственное, и вполне себе можно сочетать volatile и multithreading при должно сноровке :)
Никогда, слышите, никогда не используйте volatile в одном предложении с multithreading. Единственное исключение: предыдущее предложение.
А так спору нет, более того, вне экзотических случаев, лучше вообще использовать готовенький TBB, решающий большинство проблем подо все адекватные платформы :)
Разве ж C и C++ отличаются в поведении относительно volatile?
Проверенная годами и highload-нагрузкой схема - volatile, CAS, выравнивание по линейке кеша, серийник в старших битах для обхода ABA-проблемы - и примитив для многопоточного lockless-алгоритма на X86-64 архитектуру, даже с множеством numa-нод готов - в большинстве случаев даже fence-ы не нужны
Понятно что есть красивый фасад в виде std::atomic вокруг кучи intrinsic-ов, и джунам лучше использовать его, чтобы не выстрелить себе в ногу, но в целом же это банальный синтаксический сахар, и странно говорить что volatile не подходит для многопоточности, в то время как он отлично подходит в решениях, проверенных годами
В конце концов, интринсик всего лишь или вставляет машинную инструкцию, или же инструктирует компилятор об аспектах кодогенерации (например запрещает переставлять операции в целях оптимизации, или маркирует неявную возможную замену объекта при девиртуализации в std::launder, к примеру)
Это примерно из того же разряда, как проверять свойства типов в compile time - классическим SFINAE или через темплейтную auto-лямбду? У второго подхода есть свои плюсы, но странно говорить, что старый добрый SFINAE уже не подходит для этого
Для C++-ных junior-ов да, лучше использовать высокоуровневые абстракции типа std atomic-ов, но в целом для highload многопоточных приложений без volatile, барьеров, фенов, CAS-ов - никуда
А почему они должны отмываться, когда все конкуренты поступают та же?
Это настолько очевидная правда, но для ново-левых активистов признать это страшнее, чем расстаться с жизнью
Возможно ново-левые активисты насколько верят в свою новенькую "вокеистскую религию", что считывают затыкания ртов, цензурирование контента и культуры отмены чем-то настолько естественным, что даже не могут представить обратное даже как гипотезу
Подумаешь, ты усомнился с правильности действия толпы из гетто, громящей улицы после сметри от передоза темнокожего уголовника-рецедевиста - все, получай пожизненный теневой (или настоящий бан) и публичное порицание от новолевых активистов-экстремистов
Оурвеллу такое даже не снилось в страшных снах, а Вы говорите конкуренты :)
потеря производительности в нем равна потере производительности при работе чего-то в контейнере
Здесь Вы правы, только вот потеря производительности в кублето-контейнерах колоссальная - это даже не разы, а вполне себе несколько порядков - тысячи и десятки тысяч раз
Сколько стоит одно переключение контекста? Сколько стоит блокирующий системный вызов, где могло быть непрерывное вычисление на основе PMD-механик? Какова цена т.н. ложного кеш-разделения? Где и как можно использовать спекулятивный порядок чтения/записи в памяти в lockless-алгоритмах для обхода строгой когерентности, с одной стороны, и сохранения правильности, с другой стороны?
Не надо отвечать на вышеперечисленные вопросы, и так понятно, что в кублет-контейнерах, как худших сортах виртуалок, все это неподконтрольно и нереализуемо - можно довольствоваться только самой низкой производительностью user space
>Поэтому все ваши высказывания, это просто от недостатка опыта.
Делать предположения о компетенции людей на основе предположений, как минимум, странно и невежливо. Выражаясь Вашими терминами, в моем портфеле - настоящие высоконагруженные проекты, где ОДИН железный сервер DPI-анализа обрабатывает нагрузку в 120 GBps, а это интеллектуальный анализ, блокировка и модификация трафика на лету
Разумеется настоящий highload это только fine-tuned железо, кастомные сервисы работающие в kernel-режиме и PMD-драйвера, грануляция локальности и аффиности по numa-нодам процессора, возможно патчинг системного scheduler-а и так далее. Если Вы не использовали оптимизации на уровне ядра и/или гетерогенные вычисления, то вряд ли понимаете, что значит слово Highload
Разумеется никакие кублеты, докера и контейнеры - это детское балавство для разработчиков на сверхвысокоуровневых языках, и никакого отношения к настоящей нагрузке не имеет. Тот факт что можно на кублетах развернуть 1000 Nodejs или Python серверов, которые по нагрузке могут меньше, чем один настоящий железный сервак с ПО на C++/Rust, говорит только о низкой компетенции разработчиков, которые не умеют в настоящий Highload
Если что-то работает под серьезной перманентной нагрузкой
Верно подмечено, если проект вышел в фазу серьезной нагрузки, то необходимо собственное fine-tuned железо, желательно в нескольких датацентрах распределенных географически и т.д.
Ну и конечно есть Knative и т.п.
Knative же на основе кублетов? Хуже ничего не видел - стоимость астрономическая, производительность нулевая, на AWS кубы за 600 баксов работают медленнее, чем примитивная VPS-ка за 50 центов, реляционные СУБД в кубах на некоторых задачах работают в 3000 раз (на 3.5 порядка!) медленее, чем на настоящем железе
Вообще если речь о настоящих нагрузках, а не баловстве, то подходит только свой/арендованный железный сервер с руками оптимизированными параметрами ядра, hugepage-ами, афинностью по банкам памяти по numa-нодам, скорее всего кастомным планировщиком или как минимум TBB с тюнеными аренами задач под профиль нагрузки, 40-гигабитной сетевой картой в PMD-режиме и так далее
Никакие кублеты для реального highload и рядом не стояли, а если нагрузка не такая уж большая, то serverless 100% будет дешевле и проще :)
MS Edge был и остается незаменимым браузером для слабенького и/или устаревшего железа, ни никакого другого разумного альтернативного варианта для ноута 15-летней давности особо нет
На старом ноутбуке с 1GB оперативки без disk swap, MS Edge легко тянет несколько открытых вкладок, даже относительно тяжеловесных, вроде Telegram или Skype - в то время как другие браузеры, даже будучи единственным активным пользовательским приложением в системе, начинают жаловаться на нехватку памяти и почти сразу обрушивать вкладки
Не уверен как это именно устроено внутри MS Edge, но по всей видимости он как-то очень быстро умеет "замораживать" вкладки в таком случае, поскольку при переключении явно заметен эффект, что вкладка загружается заново - но комфорту работы это не мешает, да чуть медленее, зато очень стабильно без крашей вкладок
Идея для размышления для адептов LLM - а почему не считать github.com новым сильным искусственным интеллектом? Там расположены большие объемы качественного и рабочего программного кода, библиотек, и в отличие от результатов LLM-помоек, все еще компилируется и работает!
Еще google.com - тоже сильный искусственный интеллект, ведь он может ответить на большое количество вопросов, причем без галлюцинаций. А stackoverflow.com - этот вообще умеет разрабатывать на множестве языков программирования, исправлять ошибки компиляции и исполнения, советовать best practices, ревьюить код и даже решать задачи по computer science!
Что-то не складывается, да? А вот когда все вышеперечисленное заскрапили в offline-базу и прикрутили к ней поиск на нативном языке, то внезапно оказалось, что пользователи наделяют наличием интеллекта не саму петабайтную базу знаний с заготовленными ответами, а галлюционирующий поисковик по этой базе знаний
>ИИ пройдёт авторитетный IQ-тест MENSA летом 2025 года, а к 2026 году ИИ сможет сам создавать другие нейросети
Нет никаких сомнений, чо ИИ сможет решать всякие сложные задачи, синтезровать программные и в будущем аппаратные решения. Только большой вопрос, появится ли хотя бы какой-то минимальный ИИ к 2025 году? Alphacode что-то заглох, по крайней мере ничего не публикуют уже год, что грустно, а других известных ИИ что-то не видно в публичном пространстве :(
Жаль что тему с ИИ как будто бы не развивают (по крайней мере публично), а все информационное поле завалено бесполезными LLM-бредогенераторами, которые от ИИ на порядок дальше, чем банальный поисковый алгоритм Гугла, оптимизатор в LLVM или предсказатель в процессоре - вот где интеллект, а не тупая хайповая болталка на около-цифровые темы
За работу мозга не скажу, насколько мне известно, до сих пор не существует общепризнанной непротиворечивой модели его работы. Дискуссии вида естественный/искусственный интеллект это заведомо неконструктивно, холиварно и не особо интересно.
Вот что действительно интересно, это настоящий искусственный интеллект, или лучше абстрактный интеллект. Идея примерно следующая - по аналогии как в физике энтропия в какой-то мере характеризует "качество" энергии для ее последующего использования, так же в мире информации и формальной логики есть аналогичная характеристика - к примеру, конкретная тройка чисел a^n+b^n != c^n - это "низкокачественная" информация, а вот запись доказательства теоремы в языке формальной логики - "высококачественная" информация.
Основное качество интеллекта - умение по наличию входной "низкокачественной" информации получать "высококачественную", то есть в какой-то мере более сжатую, и условно говоря, отражающую реальные взаимосвязи в логическом (математика) или естественном (физика).
При таком определении всякие ИНСы и *GPT не только не являются интеллектом, но наоборот - строго являются его противоположностью. Имея на входе эксабайты очень "высококачественной" информации, взятой из научных статей, форумов с решениями задач, готовых миллиардов/триллионов строк качественного кода и так далее - ИНС способна генерировать только более "низкокачественную" информацию, но никогда не более "высококачественную".
За счет огромного входа для обучения и очень высокого качества информации в нем, падение качества на выходе ИНС недостаточно, чтобы опуститься до уровня рандомного шума, поэтому выход получается осмысленным, и иногда полезным. Однако повышение качества информации на выходе ИНС по сравнению с ее входом чисто физически невозможно, т.е. ИНС никогда не сможет решать задачи более сложные, чем уже были в обучающей выборке. В то время как для настоящего искусственного интеллекта - это как раз и есть основная работа
К Вам никаких претензий, извините, если приняли на свой счет :) Это мысль в целом об информационном/новостном пространстве, где рассуждают об ИИ и ИНС
Невероятный фейспалм каждый раз, когда термины *искусственный интеллект* (ИИ) и *искусственные нейронные сети* (ИНС) используются как взаимозаменяемые вещи
ИНС в принципе не способны на решение инженерных, научных и технических задач, хоть сколько квадриллионов нейронов в них засунуть, поскольку являются просто сортом экстраполяции по набору обучающей выборки. В областях генерации картинок или нетехнического текста это работает великолепно, поскольку эти области не требуют точности и формализма
В случае научно-технических задач подход принципиально иной. Нельзя взять набор формул из формальной теории и по их внешнему виду наэкстраполировать новых знаний, просто смешивая с определенными весами и добавляя случайные символы. Примерно так же, как невозможно доказать теорему Ферма или гипотезу Коллатца, просто перебирая и подставляя в них числа. ИНС любого размера для этих целей по определению бесполезен
ИИ в научно-технической сфере - это в сторону автоматического доказательства теорем, формальной верификации и программ высшего порядка, которые умеют генерировать другие программы и/или проверять их свойства (с учетом ограничения теоремы Райса) и так далее
Есть много интересных достижений ИИ в этой сфере, которые можно осветить, но информационное поле забито бесполезными ИНСами, генерирующими котиков, или переформулирующими готовые ответы из Google или StackOverflow
То, что в OpenSource находятся настолько гигантские залежи петабайтов кода, что большинство несложных задач, которые можно придумать за 5 минут и реализовать на популярном языке программирования, уже давно написаны?
OpenAI реализовали отличный мультимодальный поисковик, но зачем-то испортили его бесполезным фасадом в виде prompta и ответа на "человеческом языке", вместо того чтобы просто предоставлять качественную выдачу оригинальных URL-ов без каких-либо галлюцинаций и пост-обработки
В этом плане *GPT только очерняют понятие ИИ, поскольку как раз является худшим его представителем - глючным недо-поисковиком по эксабайтам существующей информации, но портящий ее галлюцинациями, даже в примитивной задаче сложения пары чисел
В то же время есть серьезные профильные ИИ-проекты, за которыми действительно будущее AI-разработки, например AlphaCode от DeepMind, который успешно решает немаленький процент олимпиадных задач, и при этом натренирован на выборке в десятках мегабайт (которую можно к тому же загрузить и посмотреть), то есть он действительно в какой-то мере понимает задачу
В отличие от *GPT-помоек, которые просто роются в эксабайтах готовой информации, но никак ее не понимают, а просто подбирают следующие токен вероятностным образом. Жаль, что хайповый продукт с перенасыщенным бюджетом смещает фокус с настоящих AI-разработок в баловство
Нет сомнений, что будущее за AI, в том числе в инженерии и науке, включая разработку, но этот AI очевидно будет (уже есть?) родственником условного AlphaCode или чего-то подобного, а не захайпленной помойки
Сравнения естественного и искусственного интеллекта, к сожалению или счастью, есть очень неконструктивная тема для дискуссии, в которой легко скатиться в псевдо-философию. В конце концов и немного упрощая, все во вселенной состоит плюс/минус из атомов, а значит любой объект как сборник атомов потенциально может обладать и интеллектом, и сознанием - хоть GPT, хотя булыжник валяющийся на дороге. Обсуждать такое для технического ресурса несерьезно, поэтому в исходном комментарии я целенаправленно удержался от любых утверждений о возможностях и сравнении ИИ и мозга
Отличий от огромной поисковой машины, точнее от поисковой машины+авторефератора, так обнаружить не удалось. Тот же пример описания шутки с телефоном и VGA-кабелем, элементарно ищется в Твиттере за историю (разумеется старую историю, когда GPT-3 еще даже в помине не было)
А вообще зачем о чем-то подобном спорить. Лучше пользоваться следующим алгоритмом:
1) Возьмите какой-нибудь кейс из обычной жизни, и придумайте на его основе какую-нибудь несложную, но не примитивную, математическую или физическую задачку
2) Методом аккуратного гугления/яндексования проверьте, что подобная задачка действительно уникальная, иначе вернуться к пункту 1
3) Попросить решение задачи у GPT и проанализировать ответ
4) Методом аккуратного гугления/яндексования проверьте, вам предоставили ответ на какую-то задачу, которая относительно похожа по тексту, но совершенно иная по смыслу
5) Повторить начиная с пункта 1, собирая статистику* для получения или опровержения статистической гипотезы о возможностях ИИ по решению принципиально новых задач
*Как мы помним из матстата, число испытаний необходимо утвердить по проведения эксперимента, чтобы избежать p-hacking-а по вкусу
Забавно конечно наблюдать, как даже вроде бы технически-грамотные инженеры ищут "интеллект" у продвинутой поисковой системы - хотя в принципе ничего нового, в каждую эпоху свои когнитивные искажения
Ответ на механизм "интеллекта" gpt-подобных систем очень простой: люди просто забывают, насколько огромен интернет, и насколько на самом деле плоховато работают классические поисковики. По состояния на 2022ой год, как указывают источники, это около 90 зеттабайт, то есть порядка 9*10^22 байт
На самом деле в интернете обсуждено и написано так много, что гораздо сложнее придумать что-то новое, что не было обсуждено. Школьники и студенты на каждый чих выкладывают задачи с просьбой помочь их решить. Диванные философы регулярно обсуждают вопросы природы сознания, сравнения работы мозга и ИИ и так далее
Единственное что делают gpt-подобные системы - это очень хороший поиск по зеттабайтам информации и реферирование/перефразирование текстов так, чтобы цитата из ответа не искалась дословным поиском (в кавычках) в поисковой системе
Не скажу за гуманитарные и общефилософские области, но при общении с gpt в технических областях всегда одно из двух - либо для ответа бота можно найти один или несколько однозначных источников, откуда ответ скомпонован с небольшими модификациями, или же в ответе бота будет откровенная рандомная галлюцинация
Арифмометр считал быстрее человека еще несколько веков назад, а чат-боты, с которыми можно поговорить о сути бытия, вполне себе были уже в 90ые годы. Здесь более продвинутый поисковик и авто-рефератор, ну ок, круто
Спекулятивное выполнение и теневые регистры же. Вас же не удивляет, что обе ветки if-else выполняются, а когда результат условия становится известен, выбирается только один путь. Спекуляций видимых за MMU/IOMMU видимо все-таки не существует по определению (Кроме хитрых lockless алгоритмов, но там другое - алгоритм умеет rollback-ить определенные жестко фиксированные случаи, которые сам же и спекулирует :)
В каком-нибудь таком случае вполне себе изменит https://godbolt.org/z/brn7brjoE , плюс все __sync_* функции все равно форсированно приводят указатель к volatile, благодаря чему оно верно и компилируется. Условный TBB от Intel тоже вполне себе использует volatile в многопоточном коде Search · volatile (github.com)
В общем, не вижу смысла в дальнейшей дискуссии. Исходный тезис был "multithreading и многопоточность несовместимы", а это не верно. Показать примеры из промышленного кода я не могу по NDA, а сидеть выдумывать аналогичные простые примеры - не вижу смысла
Чтобы подвести bottom line - смысл volatile (не технически, а скорее философски) примерно такой же, как у std::launder - надавать компилятору по рукам, где в высокооптимизированном (и скорее всего массивно-многопоточном) highload-коде проведены ручные микрооптимизации под целевую платформу, и надо отвадить компилятор от неверной кодогенерации :)
Все-таки volatile + __sync_* intrinsics дают большие возможности контроля Compiler Explorer (godbolt.org)
Atomic конечно соберется с любым процессором, но может оказаться, что там всадили lock - в каких-то случаях это плюс, но в каких-то лучше пусть не скомпилируется, зато это повод явно разработать lockless-версию для целевой платформы, и не нарваться на lock
Хотя вы конечно скажите `static_assert(std::atomic<T>::is_always_lock_free == true, "LOCK DETECTED ALARM")` - в общем, на вкус, на цвет, и на грануларность контроля :)
Я особенно ничего доказывать не хочу, мне просто слишком резанула глаз цитата про единственное исключение - все-таки исключение-то не единственное, и вполне себе можно сочетать volatile и multithreading при должно сноровке :)
А так спору нет, более того, вне экзотических случаев, лучше вообще использовать готовенький TBB, решающий большинство проблем подо все адекватные платформы :)
Так где выше хоть слово о том, что так `a=1; b=2;` надо делать - там же явно написано
При соблюдении всех требований целевой архитектуры - вполне себе рабочее решение :)
Разве ж C и C++ отличаются в поведении относительно volatile?
Проверенная годами и highload-нагрузкой схема - volatile, CAS, выравнивание по линейке кеша, серийник в старших битах для обхода ABA-проблемы - и примитив для многопоточного lockless-алгоритма на X86-64 архитектуру, даже с множеством numa-нод готов - в большинстве случаев даже fence-ы не нужны
Понятно что есть красивый фасад в виде std::atomic вокруг кучи intrinsic-ов, и джунам лучше использовать его, чтобы не выстрелить себе в ногу, но в целом же это банальный синтаксический сахар, и странно говорить что volatile не подходит для многопоточности, в то время как он отлично подходит в решениях, проверенных годами
В конце концов, интринсик всего лишь или вставляет машинную инструкцию, или же инструктирует компилятор об аспектах кодогенерации (например запрещает переставлять операции в целях оптимизации, или маркирует неявную возможную замену объекта при девиртуализации в std::launder, к примеру)
Это примерно из того же разряда, как проверять свойства типов в compile time - классическим SFINAE или через темплейтную auto-лямбду? У второго подхода есть свои плюсы, но странно говорить, что старый добрый SFINAE уже не подходит для этого
Да-да, конечно, ведь лучше запрятаться за высокоуровневыми абстракциями, чтобы потом получать приложения, тормозящие даже на дорогущем оборудовании
При наличии прямых рук нет ничего лучше, чем хорошо спроектированный lockless с соответствующими volatile-ами и барьерами - тот же DPDK юзает в хвост и гриву все вышеуказанное
Для C++-ных junior-ов да, лучше использовать высокоуровневые абстракции типа std atomic-ов, но в целом для highload многопоточных приложений без volatile, барьеров, фенов, CAS-ов - никуда
Это настолько очевидная правда, но для ново-левых активистов признать это страшнее, чем расстаться с жизнью
Возможно ново-левые активисты насколько верят в свою новенькую "вокеистскую религию", что считывают затыкания ртов, цензурирование контента и культуры отмены чем-то настолько естественным, что даже не могут представить обратное даже как гипотезу
Подумаешь, ты усомнился с правильности действия толпы из гетто, громящей улицы после сметри от передоза темнокожего уголовника-рецедевиста - все, получай пожизненный теневой (или настоящий бан) и публичное порицание от новолевых активистов-экстремистов
Оурвеллу такое даже не снилось в страшных снах, а Вы говорите конкуренты :)
Здесь Вы правы, только вот потеря производительности в кублето-контейнерах колоссальная - это даже не разы, а вполне себе несколько порядков - тысячи и десятки тысяч раз
Сколько стоит одно переключение контекста? Сколько стоит блокирующий системный вызов, где могло быть непрерывное вычисление на основе PMD-механик? Какова цена т.н. ложного кеш-разделения? Где и как можно использовать спекулятивный порядок чтения/записи в памяти в lockless-алгоритмах для обхода строгой когерентности, с одной стороны, и сохранения правильности, с другой стороны?
Не надо отвечать на вышеперечисленные вопросы, и так понятно, что в кублет-контейнерах, как худших сортах виртуалок, все это неподконтрольно и нереализуемо - можно довольствоваться только самой низкой производительностью user space
>Поэтому все ваши высказывания, это просто от недостатка опыта.
Делать предположения о компетенции людей на основе предположений, как минимум, странно и невежливо. Выражаясь Вашими терминами, в моем портфеле - настоящие высоконагруженные проекты, где ОДИН железный сервер DPI-анализа обрабатывает нагрузку в 120 GBps, а это интеллектуальный анализ, блокировка и модификация трафика на лету
Разумеется настоящий highload это только fine-tuned железо, кастомные сервисы работающие в kernel-режиме и PMD-драйвера, грануляция локальности и аффиности по numa-нодам процессора, возможно патчинг системного scheduler-а и так далее. Если Вы не использовали оптимизации на уровне ядра и/или гетерогенные вычисления, то вряд ли понимаете, что значит слово Highload
Разумеется никакие кублеты, докера и контейнеры - это детское балавство для разработчиков на сверхвысокоуровневых языках, и никакого отношения к настоящей нагрузке не имеет. Тот факт что можно на кублетах развернуть 1000 Nodejs или Python серверов, которые по нагрузке могут меньше, чем один настоящий железный сервак с ПО на C++/Rust, говорит только о низкой компетенции разработчиков, которые не умеют в настоящий Highload
Верно подмечено, если проект вышел в фазу серьезной нагрузки, то необходимо собственное fine-tuned железо, желательно в нескольких датацентрах распределенных географически и т.д.
Knative же на основе кублетов? Хуже ничего не видел - стоимость астрономическая, производительность нулевая, на AWS кубы за 600 баксов работают медленнее, чем примитивная VPS-ка за 50 центов, реляционные СУБД в кубах на некоторых задачах работают в 3000 раз (на 3.5 порядка!) медленее, чем на настоящем железе
Вообще если речь о настоящих нагрузках, а не баловстве, то подходит только свой/арендованный железный сервер с руками оптимизированными параметрами ядра, hugepage-ами, афинностью по банкам памяти по numa-нодам, скорее всего кастомным планировщиком или как минимум TBB с тюнеными аренами задач под профиль нагрузки, 40-гигабитной сетевой картой в PMD-режиме и так далее
Никакие кублеты для реального highload и рядом не стояли, а если нагрузка не такая уж большая, то serverless 100% будет дешевле и проще :)
Если речь конечно о bare metal instances с возможностью тюнить ядро (вроде таких https://aws.amazon.com/about-aws/whats-new/2022/04/amazon-ec2-bare-metal-instances/), то конечно норм, но это фактически тот же железный сервер с автоматической арендой - кубы тут тоже непричем