All streams
Search
Write a publication
Pull to refresh
191
0.8

Программист

Send message

У меня более новый dell, но он почему-то очень любит гудеть вентиляторами даже без нагрузки (и даже во время сна, из-за чего я сном на ноубуке не пользуюсь). Кажется, моя проблема тоже где-то рядом.

counts[0] += (*val == bucket_value!(0)) as usize;

Прикольно, оказывается в х86 есть CMOVcc и SETcc, которые выполняются или нет в зависимости от сравнения, но не сбрасывают конвейер. Так что код вида cond ? a : b тоже так может.

Я почему-то раньше думал, что такое только в ARM есть.

К сожалению, почти все модели на английском/китайском работают заметно лучше, чем на русском (в зависимости от того, кто их учил).

Я был приятно удивлён, когда запустил 8B модельку от яндекса, в дооубчении которой 30% русского и токенайзер подогнанный под русский язык - не смотря на свой размер, она отвечала довольно складно. Но та модель маленькая, я бы от неё многого не ждал. (Яндекс вроде бы её в Алисе использует)

Да нет, erlang и модель акторов вполне реальные и иногда используются.
И каналы в го - по-сути каналы для сообщений.

Это было в 2003 году. В современных языках, даже в мейнстримных и системы типов довольно продвинутые и ide поверх них работают на порядок лучше.
Вместо динамического js сейчас вовсю используют ts, а Python обмазывают аннотациями (они там необязательные, и типизация в рантайме всё равно динамическая, но их активно добавляют и доделывают последние лет 10)

Кажется, на фоне расходов на сам системный вызов это мало. Тут мои знания очень поверхностные, но кажется что для обработки системного вызова надо ещё переключиться в контекст ядра, сохранить все регистры, переключить стек на ядерный, что-то сделать, а потом вернуть регистры обратно и переключиться обрано в юзерспейс. Ещё я знаю что есть TLB, но не знаю сбрасывают ли его внутри системного вызова или как-то обходятся без этого. Т.е. системный вызов сильно сложнее внутри, чем просто вызов функции.

Если при записи окажется открыто больше одного регистра, одинаковые данные попадут сразу во все. Еще хуже ситуация при чтении: ячейки из разных регистров начнут выставлять разные значения на одни и те же битовые шины. В результате возможна непредсказуемая перезапись — данные из одних ячеек могут затереть другие из-за технологического разброса параметров. Это приведет к повреждению информации в памяти, чего допускать нельзя.

А чем плохо, когда данные попадут сразу в несколько регистров? По-моему, это наоборот интересная возможность, например, можно одним махом занулить сразу несколько регистров. Разве так не делают? Из потенциальных проблем я вижу только то, что сигнал пойдёт в сразу несколько ячеек и будет нужен ток побольше.

В cps можно жонглировать и вести/приостанавливать сразу несколько потоков управления. Как с корутинами, но в языке без корутин.
Ещё есть интересная идея, что contination можно несколько раз продолжить с одного и того же места. Тогда поток исполнения вместо линейного превращается в что-то типа дерева.

Спасибо, не знал :)

Были, но это не значит что они легко доставались.
Вроде бы лошадь в день может есть порядка 10 кг сена и провести телегу на 25-50 км (+ оплата на еду и на жизнь кучеру. Лесоруб за день может заготовить порядка 1-3 кубометра дров. Железо, кстати, тоже очень интересно добывалось и обрабатывалось.

Меня в этом плане ещё развитие железных дорог в 19 веке очень впечатлило, когда я начал смотреть на цифры : во-первых, на рельсы понадилось огромное количество железа (в разы больше чем до железных дорог), во-вторых паровозы ели уголь/древесный уголь буквально тоннами за поездку, а в третьих несмотря на всю сложность задачи, это оказалось в разы быстрее и дешевле, чем более старые виды транспорта.
Типа каретами путь из Москвы в Питер занимал несколько недель, а на поезде вроде получалось за сутки.

И до железных дорог задача перевозки была сильно сложнее и дороже.

Я подозревал, что когда-то давно соль ценилась, но что её настолько замороченно готовили/очищали и возили через пол-континента - не знал.
И ещё легко сказать "мальчишка, который подбрасывал дрова в топку", но ещё кто-то эти дрова рубил и подвозил, и кажется, что расходовались они кубометрами.

Я вообще не понимаю, зачем администрация хабра (компании, зарегистрированной на Кипре) транслирует нам этот бред.

Может у меня был неправильные пластики, но разница заметна.
PLA более жёсткий и хрупкий, PETG более пружинистый. Даже если максимальная нагрузка схожа, вести себя перед разрушением они будут по-разному.
От модели PLA ощущения ближе к тому, что держишь модельку из дерева/кости.

Забить на шов и не париться.
Ещё есть вариант выбрать рандомное начало печати в каждом слое, тогда вместо заметного шва будет куча маленьких отклонений.

Кстати, ещё забавный момент - есть моноколёса и там тоже нужно контрруление, хотя колесо только одно. И тоже как на мотоцикле траектория в повороте задаётся ускорением вперёд или назад - ускорение выпрямляет траекторию, замедление закручивает внутрь.
Мне резко стало проще на моноколесе учиться ездить, когда я эту аналогию с мотоциклом понял.
P.s. я ещё подозреваю, что с опытом моноколёса будет легче уницикл освоить, но пока не пробовал.

У двигателя мотоцикла есть небольшой рывок при переходе из состояния "нет тяги" в "тяга есть". Если пытаться на низкой скорости маневрировать чисто газом, то мотоцикл будет дёргаться и нестабильно ехать в повороте - либо заваливаться внутрь, либо разгоняться наружу.
Педаль тормоза позволяет эту тягу точно контролировать и не дергать ручку газа.

А ещё двигатель на холостых оборотах довольно легко глохнет под нагрузкой, но если приоткрыть газ и притормозить - на тех же оборотах работает лучше.

На колодки и бензин вообще пофиг, эффект расхода практически нулевой, потому что скорость низкая, а работа это сила на скорость и то что там сила типа сотни ньютонов тянет назад на скорости в 1 м/с - это жалкие 100 ватт и ни тормозам не двигателю хуже не станет.

Я понимаю, к Вам никаких претензий. Моё недовольство направлено в сторону хабра и сложившейся ситуации.

Читаю технические статьи и стараюсь игнорировать кликбейтные заголовки.

  • "Разработка высоконагруженных API: проблемы, решения, практические рекомендации" - сразу понятно, что там и захочу ли я читать (статья, кстати, топовая)

  • "Тебе не поступить на программиста. Всё кончено" - вижу кликбейт и в общем-то мне и уже и не нужно никуда поступать.

  • "Я ставлю датчик, иду на Авито и зарабатываю 2 млн в месяц на курьерах" - сразу понятно, что это Слава Рюмин и читать я это не хочу.

  • "Я 10 лет искал причину головной боли, оказалось — чипсы" - у меня такая же голова и она не болит, можно не тратить время

  • "Крах ИИ: Почему нейросети не пережили свою первую зиму" - не знаю кто там что не пережил, гоняю локально LLM и Stable diffusion, всё нравится. Возможно автор думает, что он провокационным заголовком заставит меня зайти. Ему не удалось.

  • "AGI математически невозможен, но хайп уже не остановить" - пока одни рукомахательно рассуждают что там невозможно, другие берут и делают. Тех кто реально что-то делает, читать на пару порядков интереснее.

Забавно, что даже среди перечисленных "лучших" статей я не читал практически ничего (исключение - несколько технических типа той что про OpenCV), и даже сейчас по их заголовкам желания читать их не возникло.

У Питона очень низкий порог вхождения и это очень гибкий язык. Он не ограничивает программиста, и надо иметь очень много опыта и дисциплины, чтобы писать хорошо.

Сам язык ничего выдающегося из себя не представляет, но к нему есть много хороших библиотек, не всегда доступных для других языков. (Особенно если учить нейронки) По-факту питон это просто клей между такими библиотеками, описывающий какую-то высокоуровневую логику.

Но у этих библиотек из-за гибкости и динамичности питона свой синтаксис и их тоже надо осваивать. Например, в numpy есть куча всяких мощных операторов, функций и правил броадкастинга многомерных массивов, но их знание не имеет ничего общего со знанием языка.

И к сожалению не все популярные библиотеки с хорошим api, например pandas или matplotlib на мой взгляд совсем неочевидные, каждый раз когда приходится сталкиваться с ними, написание кода похоже на шаманство.

Information

Rating
1,785-th
Location
Белград, Сербия
Registered
Activity

Specialization

Software Developer, ML Engineer
Kotlin
Scala
Java
Python
Neural networks
Algorithms and data structures
Android development
OpenGL