Если речь про boost::unordered_map - нет. По умолчанию решение не потокобезопасно, но это решается через разделяемые мютексы, в boost есть boost::interprocess::named_mutex и др., кроме того аллокатор тоже не потокобезопасен и при конкуретнтном доступе может попортить память, так что нужно быть осторожным в этом плане.
Хорошие результаты показывают пайплайны из нескольких агентов, один трансформирует пользовательский запрос, другой его обрабатывает, третий оценивает адекватность работы второго и т.д.
Реши логическую задачу. Вы едете на электричке от вокзала. Навстречу вам, в сторону вокзала, едут другие электрички, которые вы встречаете каждые 5 минут. Скорости всех электричек, вашей и встречных, одинаковы. Сколько электричек прибывает к вокзалу за один час?
GPT-4o:
Задача решается через анализ встречных электричек, их периодичности и взаимосвязи со скоростью.
Условие: вы встречаете электричку каждые 5 минут, и все электрички движутся с одинаковой скоростью, включая вашу.
Так как скорости электричек одинаковы, можно предположить, что ваша скорость и скорость встречных электричек складываются. Это означает, что встречные электрички движутся относительно вас в два раза быстрее, чем каждая электричка по отдельности. Если вы встречаете электричку каждые 5 минут, это значит, что в одну сторону (к вокзалу) электрички отправляются каждые 10 минут.
Следовательно, за один час:
Таким образом, за один час 6 электричек прибывает к вокзалу.
Просто немного переформулировал промпт. В чем смысл подобных статей? Показать как на каком-то одном синтетическом кейсе gpt справляется/не справляется? Хватит уже этого...
Думаю, в профессиональной разработке для креатива остаётся очень мало места. Задача разработчика — не придумывать что-то в стиле "А что если сделать вот так или вот так, а добавлю-ка я ещё вот это". В серьёзном проекте такое непозволительно: задачи нужно решать наиболее эффективным способом, с соблюдением установленных стандартов и паттернов. Для изобретения чего-то нового лучше применять инженерный подход: выдвигать обоснованные гипотезы, проверять их, заниматься R&D и т.д. Потом еще вероятно защищать свое решение придется перед кем-то. Не думаю, что здесь есть место креативу, до какого-то уровня да, в пет проектах или небольших компаниях это может встречаться.
Я скорее имел ввиду полный рефакторинг, нежели именно переход на новый стандарт С, да это мало что даст. Быстрее библиотека стала работать точно не из-за того, что Rust быстрее С. А так получается мы просто получили копию библиотеки но вместо С тут Rust. Окей, Раст гарантирует нам, что мы не отстрелом себе правую ногу, но по всем остальным конечностям все ещё можно стрелять. Так что если бы это была новая библиотека, без обратной совместимости и т.д. это дело было бы однозначно хорошее, но такая библиотека уже есть. А так, какой смысл в точно такой же либе, но без того комьюнити и поддержки, что делает оригинал?
Более того, на сколько я понял из статьи они переписали все as is, без погружения в детали алгоритмов и т.д. так что если где-то были логические баги, есть вероятность, что они остались и в новой реализации.
Интересно, а можно было переписать с "небезопасного С" на более безопасный С(с соблюдением современных стандартов, рекомендаций, использованием стат. анализаторов и т.д.). Уверен, что прирост в производительности был бы измерим. А вот на сколько одно "безопаснее" другого, тут был бы вопрос. Да и времени наверняка бы меньше ушло.
Если не ошибаюсь, полное сопоставление содержимого файлов после срабатывания всех проверок в стратегии дедупликации никто не делает, что на практике оставляет бесконечно малую вероятность того, что после загрузки ваш файл превратится в другой, чужой файл.
Пфф, тут некоторые запрещают вкладку с лайвкодингом переключать во время собеседования. И это далеко не Amazon.
Спасибо, исправл std::basic_string на boost::interprocess::basic_string который использует offset_ptr
Спасибо за замечание. Да, не может, необходим boost::interprocess::basic_string который работает с этим указателем. Поправил в статье.
Через boost::interprocess::offset_ptr
Если речь про boost::unordered_map - нет. По умолчанию решение не потокобезопасно, но это решается через разделяемые мютексы, в boost есть boost::interprocess::named_mutex и др., кроме того аллокатор тоже не потокобезопасен и при конкуретнтном доступе может попортить память, так что нужно быть осторожным в этом плане.
Простите, что не по теме, но КДВП вызывает жуткое чувство зловещей долины. Вы только посмотрите на улыбку парня слева... а его палец!
Хорошие результаты показывают пайплайны из нескольких агентов, один трансформирует пользовательский запрос, другой его обрабатывает, третий оценивает адекватность работы второго и т.д.
Ну, может, хоть вы расскажете про Вторую Пчелиную войну?
Реши логическую задачу. Вы едете на электричке от вокзала. Навстречу вам, в сторону вокзала, едут другие электрички, которые вы встречаете каждые 5 минут. Скорости всех электричек, вашей и встречных, одинаковы. Сколько электричек прибывает к вокзалу за один час?
GPT-4o:
Задача решается через анализ встречных электричек, их периодичности и взаимосвязи со скоростью.
Условие: вы встречаете электричку каждые 5 минут, и все электрички движутся с одинаковой скоростью, включая вашу.
Так как скорости электричек одинаковы, можно предположить, что ваша скорость и скорость встречных электричек складываются. Это означает, что встречные электрички движутся относительно вас в два раза быстрее, чем каждая электричка по отдельности. Если вы встречаете электричку каждые 5 минут, это значит, что в одну сторону (к вокзалу) электрички отправляются каждые 10 минут.
Следовательно, за один час:
Таким образом, за один час 6 электричек прибывает к вокзалу.
Просто немного переформулировал промпт. В чем смысл подобных статей? Показать как на каком-то одном синтетическом кейсе gpt справляется/не справляется? Хватит уже этого...
Думаю, в профессиональной разработке для креатива остаётся очень мало места. Задача разработчика — не придумывать что-то в стиле "А что если сделать вот так или вот так, а добавлю-ка я ещё вот это". В серьёзном проекте такое непозволительно: задачи нужно решать наиболее эффективным способом, с соблюдением установленных стандартов и паттернов. Для изобретения чего-то нового лучше применять инженерный подход: выдвигать обоснованные гипотезы, проверять их, заниматься R&D и т.д. Потом еще вероятно защищать свое решение придется перед кем-то. Не думаю, что здесь есть место креативу, до какого-то уровня да, в пет проектах или небольших компаниях это может встречаться.
Я скорее имел ввиду полный рефакторинг, нежели именно переход на новый стандарт С, да это мало что даст. Быстрее библиотека стала работать точно не из-за того, что Rust быстрее С. А так получается мы просто получили копию библиотеки но вместо С тут Rust. Окей, Раст гарантирует нам, что мы не отстрелом себе правую ногу, но по всем остальным конечностям все ещё можно стрелять. Так что если бы это была новая библиотека, без обратной совместимости и т.д. это дело было бы однозначно хорошее, но такая библиотека уже есть. А так, какой смысл в точно такой же либе, но без того комьюнити и поддержки, что делает оригинал?
Более того, на сколько я понял из статьи они переписали все as is, без погружения в детали алгоритмов и т.д. так что если где-то были логические баги, есть вероятность, что они остались и в новой реализации.
Интересно, а можно было переписать с "небезопасного С" на более безопасный С(с соблюдением современных стандартов, рекомендаций, использованием стат. анализаторов и т.д.). Уверен, что прирост в производительности был бы измерим. А вот на сколько одно "безопаснее" другого, тут был бы вопрос. Да и времени наверняка бы меньше ушло.
Жду стабильную версию и набор SDK к ней
Все же в статье речь идет о свежеустановленной ОС без доступа в интернет.
А ведь в современных Linux-дистрибутивах компиляторы и утилиты для разработки не всегда поставляются. Windows 1 — 0 Linux.
Горшочек, не вари!
Казалось бы, при чем тут PHP 8
Если не ошибаюсь, полное сопоставление содержимого файлов после срабатывания всех проверок в стратегии дедупликации никто не делает, что на практике оставляет бесконечно малую вероятность того, что после загрузки ваш файл превратится в другой, чужой файл.