Если я правильно понимаю, гомоморфные вычисления они же вроде подразумевают не "зашифрованные данные" скармливают нейронке.
А сами вычисления необходимые для инференса происходят в зашифрованном виде без необходимости расшифровки. Чисто отдельные перемноженная матриц например - прилетает две зашифрованные матрицы, нода перемножила, обратно возвращается результат вычисления во все еще зашифрованном виде. И где-то у клиента собираются обратно во что-то полезное.
Ого, первый человек в мире который хотел бы чтобы тестовые задания давали :)
Устные собесы это буквально самый слабый и простой способ фильтрации. Я искренне не понимаю почему их так не любят, с ними же наоборот проще. После третьего-четвертого уже все от зубов должно отскакивать. Волки в целом только за счет того и существуют что к собесам известны/узнаются все вопросы и подготовить к ним можно хоть обезьяну. Любые альтернативы будут сложнее и отсекать только больше 🤷
А все остальное и так есть Набор по сарафанному радио практикуют, практически везде есть бонусы за приглашение. Опенсорс в резюме огромный зеленый флаг и так, при разборе резюме это всегда круто видеть. Инкубаторы у крупных компаний тоже есть, это всякие ШАД, "интернатуры", "школы программистов" и т.д. Надо только ловить даты и кидать заявки
Автор более того своими руками этому безумию тем что популяризировал накрутку опыта везде где только можно.
Мусорные кандидаты накручивают опыт - HR'ы поднимают планку - больше кандидатов накручивают опыт - HR'ы начинают требовать документы - еще больше кандидатов накручивают опыт - требуем тестовое от всех - ...
Так чистый хардскилист на руководящих даже до стадии формулирования задачи не дойдет. Потому что некому ее будет давать если он сам не сформирует команду. Команды не будет если он не выбьет бюджет и ресурсы. Ресурсов не будет если он не "продаст" ценность тому у кого есть деньги. И т.д. В любой орг. вертикали есть места где софты начинают перевешивать харды
Так вроде для "высоких постов" умение "болтологии и заговаривать зубы" (aka софтскил) это обязательное требование. Оно буквально необходимо для качественной работы на этих "высоких постах"
Повторяюсь, дело не в «крутости» и «открытости», как раз эти два слова это просто шелуха, более важными являются стабильность и инструменты. Открытость сама по себе не позволит вам работать быстрее, а какой ни будь sourcetree например может помочь. MacOS это не Windows + cygwin, macos это самый настоящий unix с самым настоящим bash и самой настоящей linux-like фс, но и на нее можно без проблем и открытую ноду поставить в одну команду и закрытый фотошоп.
Ну так дело не в закрытости/открытости или трушности, когда уже начинаешь серьезно работать нет времени ковыряться в системе, от нее требуется только стабильность, чтобы все работало и чтобы все нужные инструменты были, а в этом плане MacOS в большинстве случаев идеально подходит, потому что 80% инструментов за которые любят Linux системы доступны и на MacOS, плюс есть некоторые свои эксклюзивы. Т. е. как бы и консоль есть и не надо сломавшиеся зависимости в apt после обновления чинить.
Да и браки были в том же Египте и вообще существовало и существует множество различных взаимоотношений. Даже если сравнивать по продолжительности, то табу на любые негетеросексуальные отношения существует значительно меньшее количество времени чем все эти виды отношений.
delete из одного алгоритма будет некорректно работать с объектом, полученным new другого алгоритма.
Это вообще пушка, new и delete определяются для класса и если уж их переопределяют так обычно оба, если у вас есть объект то он будет использовать эти new и delete, хоть в какой функции.
Если вам так хочется использовать пакующий сборщик мусора, ради бога, вы можете спуститься вплоть до malloc'ов и alloc'ов и реализовать хоть какое угодно чудное управление памятью, можете даже переписать алокаторы для классов стандартной библиотеки, другое дело что это практически никому не нужно. В С++ используются умные указатели и RAII как самые быстрые. Гибкость С++ в этом плане именно в том что вы можете спускаться хоть до ассемблерных вставок и выбирать то что вам нужно и реализовывать это как хотите, но за это заплатите сложностью. Идеального сборщика мусора тоже не существует и при этом у вас нет альтернативы.
Вы считаете что аллокация (реализация new) не обязана знать, как реализуется освобождение?
Зачем ему это знать?
Сборщик мусора может не только удалить объект, но и переместить его в более подходящее место. При этом он должен скорректировать все ссылки на этот объект.
Это ваш сборщик мусора перемещает объекты, в С++ под сборщиком мусора подразумевается всего лишь автоматическое удаление, объект переместится если только ты сам ему скажешь это сделать.
Накладные расходы счетчика ссылок не надо недооценивать. Инкремент-декримент надо делать при каждом присваивании, в том числе при передачи ссылки в качестве параметра. Кроме того, при изменении счетчика велика вероятность промаха в кеше или странице виртуальной памяти.
Про накладные расходы инкремента/декремента вообще смешно, компилятор успешно превращает их в ничто по сравнению со всякими маркировками да перемещениями применимыми в сборщиках встроенных в языки, то же самое и про промахи.
Не понял вашего комментария.
В С++ сборка мусора поддерживается исключительно библиотеками а не языком, причем каждая библиотека использует свою подходящую ей методику управления временем жизни объекта. И при чем здесь вообще аллокация если сборка мусора отвечает только за удаление не используемых объектов а не их создание? Какой еще пакующий сборщик мусора? Сформулирую немного по другому в С++ сборка мусора это не отдельная сущность со своими эвристиками, решающая кому жить а кому умереть, в С++ это просто способ реализовать автоматическое удаление объектов, причем обычно эту задачу перекладывают на сами объекты. Например тот же подсчет ссылок на котором реализовано большинство shared-указателей, сам объект хранит число указателей указывающих на него, при удалении одного указателя этот счетчик уменьшается на единицу, при создании увеличивается на единицу. Как только счетчик обнулится объект уничтожает сам себя. Очень простая идея с минимальными накладными расходами а решает львиную долю проблем слежения за разделяемыми ресурсами. Примерно так выглядит сборка мусора в С++.
P.S. К слову с новым стандартом семантику перемещения (&&) поддерживают все объекты.
Вы видимо воспринимайте сборщик мусора как некую мистическую штуку предоставляемую языком, но на самом деле и подсчет ссылок и RAII и пулы объектов это все способы сборки мусора. Грубо говоря С++ предоставляет множество способов сборки мусора в отличии от Java или C#, но программист сам должен выбрать будет ли он заворачивать все в умные указатели, либо лично выделять и удалять память либо придумает какой то свой способ. Вообще С++ дает слишком много свободы, и для программиста очень важно не мотаться от одного способа к другому а выбрать какую-то одну идеологию либо принять ту которой следует фреймворк в котором он работает и стараться следовать ей, да это требует дисциплины, но мне кажется это не такая высокая цена за высочайшую скорость и гибкость.
Вообще да, большинство фич с++11 не для общего пользования а для конкретных задач, самые распространенные (лямбды, авто) стабильно работают, даже regex уже запилен, осталась только минимальная поддержка сборщика мусора, а вот с msvc особенно обидно за constexpr но основная часть (по впечатлением от тех кто с ним работал) уже работает.
Про С++11 правильнее говорить не о стабильности а о поддержке его фич компиляторами. В этом плане gcc и clang поддерживают практически все, а вот msvc похуже.
В wwdc прямым текстом говорилось что флаг исчезнет в следующем релизе
https://developer.apple.com/videos/play/wwdc2025/102/?time=1143
Если я правильно понимаю, гомоморфные вычисления они же вроде подразумевают не "зашифрованные данные" скармливают нейронке.
А сами вычисления необходимые для инференса происходят в зашифрованном виде без необходимости расшифровки. Чисто отдельные перемноженная матриц например - прилетает две зашифрованные матрицы, нода перемножила, обратно возвращается результат вычисления во все еще зашифрованном виде. И где-то у клиента собираются обратно во что-то полезное.
Еще возможно там что-то похожее по смыслу на то что Apple выкатывал
https://security.apple.com/documentation/private-cloud-compute
Не шарю за детали, но по задаче звучит как-то похоже.
Ого, первый человек в мире который хотел бы чтобы тестовые задания давали :)
Устные собесы это буквально самый слабый и простой способ фильтрации.
Я искренне не понимаю почему их так не любят, с ними же наоборот проще. После третьего-четвертого уже все от зубов должно отскакивать.
Волки в целом только за счет того и существуют что к собесам известны/узнаются все вопросы и подготовить к ним можно хоть обезьяну.
Любые альтернативы будут сложнее и отсекать только больше 🤷
А все остальное и так есть
Набор по сарафанному радио практикуют, практически везде есть бонусы за приглашение.
Опенсорс в резюме огромный зеленый флаг и так, при разборе резюме это всегда круто видеть.
Инкубаторы у крупных компаний тоже есть, это всякие ШАД, "интернатуры", "школы программистов" и т.д. Надо только ловить даты и кидать заявки
А в чем сломанность?
Какой найм тогда должен быть?
Автор более того своими руками этому безумию тем что популяризировал накрутку опыта везде где только можно.
Мусорные кандидаты накручивают опыт - HR'ы поднимают планку - больше кандидатов накручивают опыт - HR'ы начинают требовать документы - еще больше кандидатов накручивают опыт - требуем тестовое от всех - ...
Так чистый хардскилист на руководящих даже до стадии формулирования задачи не дойдет.
Потому что некому ее будет давать если он сам не сформирует команду.
Команды не будет если он не выбьет бюджет и ресурсы.
Ресурсов не будет если он не "продаст" ценность тому у кого есть деньги.
И т.д.
В любой орг. вертикали есть места где софты начинают перевешивать харды
Так вроде для "высоких постов" умение "болтологии и заговаривать зубы" (aka софтскил) это обязательное требование. Оно буквально необходимо для качественной работы на этих "высоких постах"
Это вообще пушка, new и delete определяются для класса и если уж их переопределяют так обычно оба, если у вас есть объект то он будет использовать эти new и delete, хоть в какой функции.
Если вам так хочется использовать пакующий сборщик мусора, ради бога, вы можете спуститься вплоть до malloc'ов и alloc'ов и реализовать хоть какое угодно чудное управление памятью, можете даже переписать алокаторы для классов стандартной библиотеки, другое дело что это практически никому не нужно. В С++ используются умные указатели и RAII как самые быстрые. Гибкость С++ в этом плане именно в том что вы можете спускаться хоть до ассемблерных вставок и выбирать то что вам нужно и реализовывать это как хотите, но за это заплатите сложностью. Идеального сборщика мусора тоже не существует и при этом у вас нет альтернативы.
Зачем ему это знать?
Это ваш сборщик мусора перемещает объекты, в С++ под сборщиком мусора подразумевается всего лишь автоматическое удаление, объект переместится если только ты сам ему скажешь это сделать.
Про накладные расходы инкремента/декремента вообще смешно, компилятор успешно превращает их в ничто по сравнению со всякими маркировками да перемещениями применимыми в сборщиках встроенных в языки, то же самое и про промахи.
В С++ сборка мусора поддерживается исключительно библиотеками а не языком, причем каждая библиотека использует свою подходящую ей методику управления временем жизни объекта. И при чем здесь вообще аллокация если сборка мусора отвечает только за удаление не используемых объектов а не их создание? Какой еще пакующий сборщик мусора? Сформулирую немного по другому в С++ сборка мусора это не отдельная сущность со своими эвристиками, решающая кому жить а кому умереть, в С++ это просто способ реализовать автоматическое удаление объектов, причем обычно эту задачу перекладывают на сами объекты. Например тот же подсчет ссылок на котором реализовано большинство shared-указателей, сам объект хранит число указателей указывающих на него, при удалении одного указателя этот счетчик уменьшается на единицу, при создании увеличивается на единицу. Как только счетчик обнулится объект уничтожает сам себя. Очень простая идея с минимальными накладными расходами а решает львиную долю проблем слежения за разделяемыми ресурсами. Примерно так выглядит сборка мусора в С++.
P.S. К слову с новым стандартом семантику перемещения (&&) поддерживают все объекты.
В ответ могу сказать что «Мсье недоучил старое».