Ну так и вопрос у вас о повседневных взглядах. В данном случае наука это в том числе корректное использование фактов и логики. Научные исследования дают некоторые факты, но в данном случае они не нужны, достаточно общеизвестных фактов.
Это ответ с научной точки зрения без использования философии. Вы же об этом спрашивали. Также с научной точки зрения правильный ответ может зависеть от ситуации, и их может быть больше одного, как значения a и b для выражения "a+b = 1234".
Почему распараллеливание кода решит эту проблему? Вы только больше за базу станете драться, разве нет?
База же тоже умеет использовать потоки процессора, а пока приложение обрабатывает результат перед отправкой следующего запроса, база ничего не делает. В обработке одного запроса с одного подключения тоже есть последовательные части. А распараллеливание на обработчики, которые обрабатывают заведомо разный набор пар валют, уберет необходимость мьютексов в приложении и запроса SELECT, можно хранить текущее состояние всех курсов внутри обработчика, мы будем знать, что никто другой их не обновляет. В базу будут идти только запросы UPDATE.
Для версии с мьютексами у меня с одного подключения/потока идет 2400 SQL-запросов в секунду (1200 сообщений с курсом обмена, одна пара SELECT+UPDATE на одно сообщение), добавление до 8 потоков не меняет производительность. Потом видимо процессор нагревается, и производительность падает в 6 раз, даже с одним потоком. То есть 200 сообщений / 400 SQL-запросов на 1 поток. Внутри самой базы судя по результатам clock_timestamp() время запроса не меняется.
Но с Redis конечно быстрее. C хранением в Redis вместо базы и на 8 потоков у меня получилось 2800 сообщений в секунду для каждого потока, в 14 раз быстрее.
По остальному подождем код, так будет проще, чем выяснять что и как надо сделать. Можете даже без тестов выложить.
Во-первых, не надо в этом вопросе слушать философов. Их рассуждения основаны на домыслах, а не на фактах. Примерно на тех же домыслах, по которым у негров не было души. Слушать надо технических специалистов, которые понимают, как работает та часть, в которой они разбираются. С компьютерной стороны это программисты, с биологической нейробиологи. Психологов можно спрашивать в качестве консультантов, но не в качестве экспертов, принимающих решение.
Во-вторых, сознание тут ни при чем. Хотя бы потому что мы не умеем его измерять. Отличие ИИ и человека сводится к следущим примерам.
Актер на сцене играет солдата и кричит "А-а, я ранен". Чем это отличается от реального раненого солдата? Тем, что солдат испытывает неприятные ощущения.
Мы стрижем волосы, это можно считать повреждением части организма, но не стрижем кончик уха рядом с волосами. Почему? Потому что повреждение уха создает неприятные ощущения, а повреждение волос нет.
У солдата есть некоторые физические процессы, которые дают неприятные ощущения, а у актера их нет. Поэтому вопрос, испытывает ли ИИ боль, это вопрос о том, есть ли у него процессы, которые обладают похожими характеристиками, в том числе похожим действием. Например, может ли ИИ отвлечься от воздействия этого процесса и не обращать на него внимание? Если да, то это ничем не отличается от запачканного известкой или грязью рукава. "Ну да, рукав белый, приду домой почищу."
Поэтому вопрос о правах ИИ сводится к тому, чтобы не разрешать другим делать то, что ИИ считает для себя неприятным или неправильным, и разрешать ИИ делать то, что он для себя считает приятным или правильным. В тех рамках, которые не нарушают права других существ. Из этого следует, что он должен быть способен эти рамки понять и правильно их учитывать при принятии решений.
Но вот над тем, что он считает неприятным или приятным, у нас есть полный контроль. И можно изменить настройки так, как нам нужно.
Как, например, человеку доказать, что он не машина? Что он не имитирует, а обладает подлинным сознанием — этим особым качеством?
Никак. С научной точки зрения люди состоят из полей и атомов, сознание это результат их взаимодействия. Это и не нужно, права не привязаны к наличию сознания, хотя бы потому что мы не умеем его измерять.
У нас на курсе как-то один парень заметил. - Подходишь к первокурсникам, которые возле кафедры стоят, спрашиваешь "Кого ждете?", отвечают "Такого-то такого-то". Спрашиваешь старшекурсников, отвечают "Да хотя бы кого-нибудь..."
С другой стороны, если генерировать только без выбросов (например любой курс "1.0"), то 20000 записей сохраняются 3.6 секунды. Для однопоточного режима многовато, но если сделать 8 непересекающихся обработчиков (по числу ядер процессора), то будет достаточно.
Цифры приведены для случая если сохранять отдельными запросами внутри транзакции. Массовый UPDATE в 4 раза быстрее, но я слышал, что он создает проблемы с локами при большой нагрузке на чтение. Впрочем я не уверен, с транзакцией есть какая-то разница, или это то же самое.
Суть в том, что мьютексы в этой задаче не нужны, она хорошо параллелится.
Я проверил, у меня обработка 20000 записей в однопоточном режиме занимает 0.4 секунды, а 200000 записей 3.3 секунды. Нагрузка на чтение 100 запросов в секунду добавляет 0.1 секунды (тут вопрос, 100 запросов в секунду должно быть всего или на отдельную запись?). При том я генерировал курс случайно, поэтому там много отброшенных записей, без них время в 2 раза меньше. Это с базой данных, если данные можно потерять, то с Редисом наверно будет еще меньше. Так что я бы просто складывал все обновления валют в одну очередь и читал по 10000-20000 записей. Мьютексы тут не нужны.
Другой вариант, можно разбивать очередь на несколько непересекающихся обработчиков. Для двух обработчиков первый будет обрабатывать пары из первых 10000, второй из вторых. Тут мьютексы тоже не нужны. И кластер не нужен, одного процессора будет более чем достаточно для указанных требований.
Если хотите, могу сделать мьютексы в этой задаче, но практического смысла в этом нет. Если только сравнить, насколько будет медленнее.
Потому что у меня нет кластера. В условии было 16 потоков, у меня есть 8, это сравнимые величины. Условие устраивает. Есть некоторые вопросы, но если вы покажете код, то будет понятно.
Это примерно и означает "Вы не умеете готовить мьютексы", ну да ладно.
Из стороннего источника приходят курсы валют
А код-то ваш где?) Соревнование означает, что вы показываете код и я показываю код, при этом ваш код не должен быть однопоточным на мьютексах. Чтобы это узнать, надо сначала проверить ваш код, потому что если он тоже однопоточный, то соревноваться нет смысла. А если он не поддерживает указанные нагрузки при запуске на одной машине, то и мой код не должен. Мой код должен поддерживать сравнимые нагрузки, для чего их надо сначала замерить.
Вы же говорили, что цель избежать проблем от использования мьютексов? Если вы используете обертку B, которая использует A, то потенциальные проблемы такие же, как если просто использовать A.
но хотелось бы оговорить условия на берегу
Ну вы же предложили соревнование, вы и предлагайте требования. Я же не знаю, какие приложения вы представляли под словами "неоднопоточная модель без мьютексов на 16 потоков". Выше вы про валюты говорили, пусть будут валюты. Если что, процессор на моем ноутбуке поддерживает только 8 одновременных потоков, но для проверки концепции думаю этого достаточно.
приглашается к соревнованию на написание правильно синхронизированного кода, в который вовлечены 16 потоков. Лучшее решение, которого сможет добиться программист высокого уровня, — это вернуться на мьютексах в однопоточную модель вычислений.
Принимаю приглашение, если вы сначала покажете свой полностью работающий код, который не однопоточный и без мьютексов, который другой человек может запустить на своей машине без особых танцев с бубном (например в докере), и сообщите бизнес-требования к нему что он должен делать. А то у меня есть предположение, что и в вашем приложении есть мьютексы и соответственно однопоточные части, просто вы их не видите, потому что работаете с оберткой, которую предоставляет язык или библиотека.
Я говорил про утверждение, которое процитировал, а не про банки. В банках помимо ивентлога есть много других механизмов по обеспечению и откату. В целом это получается сложнее, а не проще, просто в банках есть свои причины это делать. А в других приложениях их обычно нет.
И получаем минус на балансе аккаунта после проигрывания ивентлога. Локи при переводе с аккаунта на аккаунт должны быть на оба аккаунта до загрузки их данных в логику перевода, которая делает проверки баланса, а не только на время записи.
Один ресурс в большинстве случаев можно сделать и без ивентлога, обычно это aggregate root, который изменяется.
AGI не придет. Он уже здесь. Просто это не то, что мы ожидали увидеть.
AGI это по определению "a type of artificial intelligence that would match or surpass human capabilities across virtually all cognitive tasks". Если такого нет, если он некоторые задачи выполняет не так хорошо, как человек, значит AGI еще нет.
"AGI, которого мы не ожидали" это нонсенс, словом "AGI" называются определенные ожидания.
С этим не соглашусь. Пришел к выводу, что graphql лучше использовать как аналог rest api. Так сильно проще код на бэкенде и меньше проблем типа N+1 из-за резольверов полей. Контроллер принимает DTO, возвращает DTO, это можно замапить как на graphql интерфейс, так и на rest.
Вложенная пагинация в graphql не поддерживается. Ну то есть запросить 3-ю страницу order items у всех orders с 4-й страницы конечно можно, только практической пользы от этого нет. А cursor based pagination вообще работать не будет.
Ну так и вопрос у вас о повседневных взглядах.
В данном случае наука это в том числе корректное использование фактов и логики. Научные исследования дают некоторые факты, но в данном случае они не нужны, достаточно общеизвестных фактов.
Это ответ с научной точки зрения без использования философии. Вы же об этом спрашивали. Также с научной точки зрения правильный ответ может зависеть от ситуации, и их может быть больше одного, как значения a и b для выражения "a+b = 1234".
Поскольку фальсифицирующий эксперимент для определения правильной интерпретации на данный момент предложить нельзя, то это и означает "ненаучный".
Вам же там уже ответили вполне с научной точки зрения.
База же тоже умеет использовать потоки процессора, а пока приложение обрабатывает результат перед отправкой следующего запроса, база ничего не делает. В обработке одного запроса с одного подключения тоже есть последовательные части.
А распараллеливание на обработчики, которые обрабатывают заведомо разный набор пар валют, уберет необходимость мьютексов в приложении и запроса SELECT, можно хранить текущее состояние всех курсов внутри обработчика, мы будем знать, что никто другой их не обновляет. В базу будут идти только запросы UPDATE.
Для версии с мьютексами у меня с одного подключения/потока идет 2400 SQL-запросов в секунду (1200 сообщений с курсом обмена, одна пара SELECT+UPDATE на одно сообщение), добавление до 8 потоков не меняет производительность.
Потом видимо процессор нагревается, и производительность падает в 6 раз, даже с одним потоком. То есть 200 сообщений / 400 SQL-запросов на 1 поток. Внутри самой базы судя по результатам clock_timestamp() время запроса не меняется.
Но с Redis конечно быстрее. C хранением в Redis вместо базы и на 8 потоков у меня получилось 2800 сообщений в секунду для каждого потока, в 14 раз быстрее.
По остальному подождем код, так будет проще, чем выяснять что и как надо сделать. Можете даже без тестов выложить.
Это всем не нравится, потому что у вас бессмысленный набор умных слов, никакой конкретики, и пустой репозиторий на GitHub.
Во-первых, не надо в этом вопросе слушать философов. Их рассуждения основаны на домыслах, а не на фактах. Примерно на тех же домыслах, по которым у негров не было души. Слушать надо технических специалистов, которые понимают, как работает та часть, в которой они разбираются. С компьютерной стороны это программисты, с биологической нейробиологи. Психологов можно спрашивать в качестве консультантов, но не в качестве экспертов, принимающих решение.
Во-вторых, сознание тут ни при чем. Хотя бы потому что мы не умеем его измерять.
Отличие ИИ и человека сводится к следущим примерам.
Актер на сцене играет солдата и кричит "А-а, я ранен". Чем это отличается от реального раненого солдата? Тем, что солдат испытывает неприятные ощущения.
Мы стрижем волосы, это можно считать повреждением части организма, но не стрижем кончик уха рядом с волосами. Почему? Потому что повреждение уха создает неприятные ощущения, а повреждение волос нет.
У солдата есть некоторые физические процессы, которые дают неприятные ощущения, а у актера их нет. Поэтому вопрос, испытывает ли ИИ боль, это вопрос о том, есть ли у него процессы, которые обладают похожими характеристиками, в том числе похожим действием. Например, может ли ИИ отвлечься от воздействия этого процесса и не обращать на него внимание? Если да, то это ничем не отличается от запачканного известкой или грязью рукава. "Ну да, рукав белый, приду домой почищу."
Поэтому вопрос о правах ИИ сводится к тому, чтобы не разрешать другим делать то, что ИИ считает для себя неприятным или неправильным, и разрешать ИИ делать то, что он для себя считает приятным или правильным. В тех рамках, которые не нарушают права других существ. Из этого следует, что он должен быть способен эти рамки понять и правильно их учитывать при принятии решений.
Но вот над тем, что он считает неприятным или приятным, у нас есть полный контроль. И можно изменить настройки так, как нам нужно.
Никак. С научной точки зрения люди состоят из полей и атомов, сознание это результат их взаимодействия. Это и не нужно, права не привязаны к наличию сознания, хотя бы потому что мы не умеем его измерять.
У нас на курсе как-то один парень заметил.
- Подходишь к первокурсникам, которые возле кафедры стоят, спрашиваешь "Кого ждете?", отвечают "Такого-то такого-то". Спрашиваешь старшекурсников, отвечают "Да хотя бы кого-нибудь..."
С другой стороны, если генерировать только без выбросов (например любой курс "1.0"), то 20000 записей сохраняются 3.6 секунды. Для однопоточного режима многовато, но если сделать 8 непересекающихся обработчиков (по числу ядер процессора), то будет достаточно.
Цифры приведены для случая если сохранять отдельными запросами внутри транзакции. Массовый UPDATE в 4 раза быстрее, но я слышал, что он создает проблемы с локами при большой нагрузке на чтение. Впрочем я не уверен, с транзакцией есть какая-то разница, или это то же самое.
Суть в том, что мьютексы в этой задаче не нужны, она хорошо параллелится.
Я проверил, у меня обработка 20000 записей в однопоточном режиме занимает 0.4 секунды, а 200000 записей 3.3 секунды. Нагрузка на чтение 100 запросов в секунду добавляет 0.1 секунды (тут вопрос, 100 запросов в секунду должно быть всего или на отдельную запись?). При том я генерировал курс случайно, поэтому там много отброшенных записей, без них время в 2 раза меньше. Это с базой данных, если данные можно потерять, то с Редисом наверно будет еще меньше.
Так что я бы просто складывал все обновления валют в одну очередь и читал по 10000-20000 записей. Мьютексы тут не нужны.
Другой вариант, можно разбивать очередь на несколько непересекающихся обработчиков. Для двух обработчиков первый будет обрабатывать пары из первых 10000, второй из вторых. Тут мьютексы тоже не нужны. И кластер не нужен, одного процессора будет более чем достаточно для указанных требований.
Если хотите, могу сделать мьютексы в этой задаче, но практического смысла в этом нет. Если только сравнить, насколько будет медленнее.
Потому что у меня нет кластера. В условии было 16 потоков, у меня есть 8, это сравнимые величины.
Условие устраивает. Есть некоторые вопросы, но если вы покажете код, то будет понятно.
Это примерно и означает "Вы не умеете готовить мьютексы", ну да ладно.
А код-то ваш где?) Соревнование означает, что вы показываете код и я показываю код, при этом ваш код не должен быть однопоточным на мьютексах. Чтобы это узнать, надо сначала проверить ваш код, потому что если он тоже однопоточный, то соревноваться нет смысла. А если он не поддерживает указанные нагрузки при запуске на одной машине, то и мой код не должен. Мой код должен поддерживать сравнимые нагрузки, для чего их надо сначала замерить.
Вы же говорили, что цель избежать проблем от использования мьютексов?
Если вы используете обертку B, которая использует A, то потенциальные проблемы такие же, как если просто использовать A.
Ну вы же предложили соревнование, вы и предлагайте требования. Я же не знаю, какие приложения вы представляли под словами "неоднопоточная модель без мьютексов на 16 потоков". Выше вы про валюты говорили, пусть будут валюты. Если что, процессор на моем ноутбуке поддерживает только 8 одновременных потоков, но для проверки концепции думаю этого достаточно.
Принимаю приглашение, если вы сначала покажете свой полностью работающий код, который не однопоточный и без мьютексов, который другой человек может запустить на своей машине без особых танцев с бубном (например в докере), и сообщите бизнес-требования к нему что он должен делать. А то у меня есть предположение, что и в вашем приложении есть мьютексы и соответственно однопоточные части, просто вы их не видите, потому что работаете с оберткой, которую предоставляет язык или библиотека.
Я говорил про утверждение, которое процитировал, а не про банки. В банках помимо ивентлога есть много других механизмов по обеспечению и откату. В целом это получается сложнее, а не проще, просто в банках есть свои причины это делать. А в других приложениях их обычно нет.
И получаем минус на балансе аккаунта после проигрывания ивентлога. Локи при переводе с аккаунта на аккаунт должны быть на оба аккаунта до загрузки их данных в логику перевода, которая делает проверки баланса, а не только на время записи.
Один ресурс в большинстве случаев можно сделать и без ивентлога, обычно это aggregate root, который изменяется.
AGI это по определению "a type of artificial intelligence that would match or surpass human capabilities across virtually all cognitive tasks". Если такого нет, если он некоторые задачи выполняет не так хорошо, как человек, значит AGI еще нет.
"AGI, которого мы не ожидали" это нонсенс, словом "AGI" называются определенные ожидания.
Не одна пагинация на каком-то уровне, а одна внешняя и одна внутренняя.
Так можно, но практического сценария использования для этого нет.
А так вообще работать не будет, потому что последние order.id на предыдущей странице заказов у всех users разные.
С этим не соглашусь. Пришел к выводу, что graphql лучше использовать как аналог rest api. Так сильно проще код на бэкенде и меньше проблем типа N+1 из-за резольверов полей. Контроллер принимает DTO, возвращает DTO, это можно замапить как на graphql интерфейс, так и на rest.
Вложенная пагинация в graphql не поддерживается. Ну то есть запросить 3-ю страницу order items у всех orders с 4-й страницы конечно можно, только практической пользы от этого нет. А cursor based pagination вообще работать не будет.
Такие хеши очень похожи на роуты с REST. Часто проще просто использовать REST.