Помните план США и TSMC по строительству завода в Аризоне?

В одном из чатов по ПЛИСам наткнулся на крутую статью "TSMC’s debacle in the American desert" от 23-го апреля.

Крайне рекомендую ознакомиться.

В статье описываются трудности, с которыми столкнулись американские инженеры во время стажировки на тайваньском заводе Fab 18, где они пытались адаптироваться к местной рабочей культуре.

В частности, они столкнулись с проблемами, вызванными языковым барьером и различиями в подходах к работе: тайваньские инженеры привыкли работать по 12 часов в день, тогда как их американские коллеги предпочитали более сбалансированный рабочий график.

Кроме того американские сотрудники столкнулись с серьёзными проблемами из-за языковых барьеров. Почти всё общение на заводе, включая обучение и собрания, велось на тайваньском или китайском языках, что затрудняло понимание задач.
В теории, будущие тайваньские сотрудники Аризонского завода должны были помогать американским коллегам с переводом, но на практике у многих не хватало времени или опыта для этого.
В результате американские инженеры были вынуждены полагаться на Google Translate и программы для распознавания рукописного текста, которые часто давали неудовлетворительные результаты.

Другим аспектом культурных различий стало то, что некоторые тайваньские инженеры держали на своих рабочих столах календари с изображениями моделей в бикини и обменивались эротическими мемами в рабочих чатах. Это вызвало недовольство среди американских сотрудников, которые считали такие материалы неуместными и просили коллег их убрать.

Как итог — некоторые американские инженеры начали искать новые карьерные предложения в компаниях с менее жесткими требованиями и лучшими карьерными перспективами. В статье также упоминается, что один инженер, работавший как в Intel, так и в TSMC, рассказал, что его тайваньские коллеги интересовались вакансиями в Intel, где они надеялись на лучший баланс между работой и личной жизнью.

На codeforces уже появился пост про анализ o1-mini: https://codeforces.com/blog/entry/133887

o1-mini по идее не отличается от o1-preview в плане умения решать задачи на codeforces, так как заточена на такие вещи.

Короткий вывод: моделька неплохо решает простые задачи, но плохо решает задачи среднего уровня.

Для тех, кто не знает как устроены соревнования на codeforces. Есть 4 дивизиона, для каждого есть диапазон рейтинга, по которому осуществляется доступ к соревнованиям в дивизионе. Классическое соревнование состоит из 6 задач с возрастающей сложностью. Рейтинг человеку прибавляется или убавляется в завимости от места в соревновании. Место зависит от количества и скорости решения задач.

В посте говорят, что первые две задачи Div2 по сложности o1 решает весьма неплохо. Но начиная с третьей задачи Div2 модель справляется уже не очень. При этом четвертая задача Div2 - это эквивалент первой задачи Div1. Все, кто занимается олимпиадным программированием более менее серьезно - это Div1 уровень. То есть модель не дотягивает до Div1.

С нуля докачка до выхода в Div1 занимает около двух-трех лет, если уделять среднее количество времени тренировкам. Что значит выйти в Div1 - это стабильно решать 4 задачи Div2 и иногда решать 5 задач Div2. То есть на 2-3 задачи больше, чем умеет модель.

Само по себе очень смешно, что мы такие «а, ну всего лишь div2 решает парочку, фигня»!

А ведь всего лишь несколько лет назад предположение, что нейросетки будут решать задачи на codeforces, казалось бредом)

Но теперь нейросетка сравнялась с человеком, который тренируется в спортивном программировании около года…

Будни #bootstrap

Меня тут в комментариях спросили, как я заставил git ходить только по HTTP/1.1

Я там ответил, что в git есть опция, http.version, и что я ее и выставляю.

Как оказалось, это работает не всегда. Я так и не понял, когда и почему это ломается, но продолжал ловить ошибко про то, что по HTTP/2 не получается ничего забрать.

В итоге я сдался, и соорудил очередную #herobora.

А конкретно, собрал git с libcurl, в которой нет ничего, кроме HTTP/1.1

https://github.com/pg83/ix/blob/main/pkgs/lib/curl/http1/ix.sh
https://github.com/pg83/ix/blob/main/pkgs/bld/git/ix.sh

Удивительно, но после этого, ошибки у меня пропали.

Мораль? Никто не проверяет краевые случаи, ага.

Кстати, вспомнил, что cmake у меня собран с libcurl, которая вообще не умеет ходить по сети, в ней принудительно отключены вообще все протоколы.

Зачем?

Меньше зависимостей, граф сборки площе, ну и возможность отрубить любое хождение по сети не в любой OS есть (или доступно из коробки).

https://oneirical.github.io/gsocfinal/

Чувак хвастается, как, в рамках GSoC, переписал кучу тестов Rust, с Makefile на Rust.

TL;DR - ему нравится недо-DSL, который он запилил для этого на Rust, а мне вот не нравится, потому что тесты на Makefile были проще и понятнее (любому, кто хоть немного знает make и posix shell).

Что там стало лучше, мне непонятно, наверное стало чутка безопастнее.

#perf #fork

Авторы форка Redis занялись его оптимизацией, и запилили неплохую статью по этому поводу.

https://valkey.io/blog/unlock-one-million-rps-part2/

Там представлена интересная техника хождения по ссылочным структурам данных, за счет параллельного хождения одновременно по нескольким структурам получилось лучше использовать кеш памяти.

Другое дело, что там надо, прежде всего, выкинуть списочные структуры, ну или выделять память для узлов в каком-нить пуле, чтобы она и так рядом ложилась.

Не прошло и двух лет, как эту схему решили реализовать в https://www.phoronix.com/news/Casilda-Wayland-GTK4-Widget

Удивительный факт - KDE выглядят более клиентоориентированными, но у них все сделано через жопу загрузку плагинов #KParts, а в #GNOME - все с точностью до наоборот.

Не надо загружать в свое адресное пространство хер его знает какой код, надо результат работы стороннего приложения показывать в своем UI.

https://www.phoronix.com/review/ampereone-clang-gcc/5

На этот раз Миша сравнивает clang с gcc на aarch64.

Сразу даю ссылку на геометрическое среднее, отдельные тесты интереса не представляют.

TL;DR - clang довольно уверенно отрывается от gcc на 2 - 3 процента, как и в прошлый раз.

И новости из дурки - https://www.opennet.ru/opennews/art.shtml?num=61871

Будни #bootstrap

Добавлю еще немного про более плоский граф сборки, и почему это важно.

Когда я только собирал свою пакетную базу, зависимости у меня были очень широкие, и clang/llvm я пересобирал по 2 раза в день.

Сейчас зависимости стали более аккуратными, и clang/llvm я пересобираю даже не каждую неделю.

Добился это, например, тем, что тот же cmake стал зависеть от гораздо более лайтовой libcurl, или фиксацией версий зависимостей у grep/make/ninja/sed/coreutils/etc.

Да, теперь у меня пользователю доступны более новые grep/make/etc, чем в процессе сборки, но зато одна из самых тяжелых программ не пересобирается почем зря.

"На колу мочало, начинай сначала" (стоило только вспомнить про clang https://xn--r1a.website/itpgchannel/2210)

https://www.phoronix.com/news/LLVM-19.1-Released

Надеюсь, этот будет лучше, чем тот.

Будни #bootstrap

https://xn--r1a.website/itpgchannel/1640
https://xn--r1a.website/itpgchannel/2210
https://xn--r1a.website/itpgchannel/471

Вот, кстати, вспомнилось, в продолжение этих трех (!) тем.

(Меня, кстати, иногда удивляет своя последовательность в этом безумии, год от года ничего не меняется, пилю граф площе и площе, отрывая лишнее маленькими кусочками, но это так, в сторону)

Недавно вышла новая версия makeinfo, от проекта GNU, и я решил, что не хочу пересобирать world еще и из-за этого, и, вместо makeinfo, начал подсовывать в сборки свою заглушку - https://github.com/pg83/ix/blob/main/pkgs/bld/texinfo/ix.sh

Тем более что документацию в формате texinfo пишут только сумасшедшие #GNU фанатики, ну и, как я уже однажды писал, она всегда доступна в веб, а если надо, то можно собрать нужный таргет и с настоящими makeinfo.