Latency vs space стандартное противоречие в реализации. На самом деле самое оптимальное решение находится в интервале т.к. нужно обеспечить самую большую вычислительную мощность на единицу площади. посмотрите исходники кандидатов SHA3. Там предоставляются сразу как минимум 2 реализации (min latency, min space, не помню есть ли 3-я max hash/s/space).
По поводу первых 32 бит, которые должны быть нулями. Можно и нужно считать их сразу все вместе. Получится, во-первых, меньше логики, во-вторых, в ПЛИСах уже есть DSP блоки, на которые можно повесить дорогое сложение вместо драгоценных ячеек (в ASIC'ах всё по-другому).
По поводу параллельного вычисления нескольких хэшей. Уже много лет как есть midstate. Все обертки для майнеров уже загружают в любые (CPU/GPU/FPGA/ASIC) майнеры не оригинал, с которого нужно взять sha256, а промежуточный результат (состояние всех блоков в SHA256 на определённом раунде), который уже вычислен на процессоре.
Про самый главный трюк, который реально позволяет выжимать всё из кремния не рассказали. Вместо того, чтобы увеличивать частоту можно наоборот уменьшать её, но при этом увеличивать набор логики между защелками. Тогда можно сэкономить на «слишком хороших» задержках, которые всегда оказываются при слишком большом дроблении. Например, совместив 8 раундов в одном такте мы скорее всего выровняем фронт лучше, чем для одного раунда на такт.
С ASIC можно пойти дальше. Нам же никто не мешает использовать кристалл по-больше. Следовательно мы можем к всему прочему понизить вольтаж, но увеличить количество элементов на кристалле. Сбойные блоки можно отключить при тестировании. Остальные не влияют, т.к. задача майнинга специфична, можно перепроверять на надёжном процессоре. Итого потребление то же, а производительность больше. Понятное дело понижать получится до определённого предела и где-то будет оптимум.
// Скорее всего я здесь допустил много неточностей в терминах и некоторых формулировках, но примерная суть должна быть ясна.
По поводу терминологии.
Я перепутал прибыль и доход. Каждый сотрудник компании (в идеале) должен быть в плюс.
Я перепутал ЗП и «деньги на руки». От денег на руки урезается не такой и большой процент.
Если агрегировать всё, что было в комментариях, то получается несколько групп людей
Люди, которые генерируют прибыль компании своими действиями, которые не являются типовыми
Люди, которые генерируют прибыль компании своими действиями, которые являются типовыми
Дежурные, у которых нагрузка варьируется от обстоятельств (условные пожарные)
Для первых указанная в статье система применима напрямую.
Для вторых применима плата за конкретный результат либо за затраченные часы, с некоторой натяжкой можно применять ту же систему, что и для п.1 (т.к. сферических сотрудников в вакууме не бывает, сегодня он во второй группе, а завтра в первой).
Для третьих применима ставка и может быть доплата за затраченные часы (доплата может быть отрицательной, если делать как на заводах Форда). Если доплату таки делать отрицательной, то вообще-то система, внезапно, становится условно применима. Условно потому, что нужно достаточно хорошо подстраивать систему под прикладную сферу.
Любой сотрудник нанимается только тогда, когда он может принести компании больше прибыли, чем он стоит. (Исключение начало жизни компании, там всё по-другому)
Fixed rate сотруднику уже платится по рынку. Бонусы сверху. И для бонусов всегда будет пространство см. п 1.
Если компания настолько плохо организована, что она не может это соблюдать, то смысл существования такой компании под вопросом
По поводу оборудования. Обычно оборудование стоит сильно меньше чем суммарная ЗП сотрудников за месяц.
Но рассмотрим достаточно экстремальный случай, когда это не так. Пускай у нас команда из 15 сотрудников. Каждому в среднем платим 2k$ fixed rate'а. Итого расход 30k$. Пускай компания имеет прибыль 45k$. Период премии 3 месяца. До покупки оборудования у нас было 15k$ прибыли. 50% из них отдавалась на бонусы. Т.е. 7,5k$. Т.е. +500$ в среднем каждому (с учётом разброса это будет 300-700$ в зависимости кто как работал).
Мы хотим купить оборудование на 50k$. Во-первых, мы должны понимать, что покупка нового оборудования должна окупиться. Иначе мы просто тратим деньги. Ладно, самый худший случай. Если мы не купим оборудование, то понесём убытки.
Пускай у нас есть свободные деньги компании на покупку 50k$. Такая покупка автоматически делает -50k$ в отчете компании. За 3 месяца это едва ли окупится в ноль. 15*3=45k$. Получается, что за этот период премии вообще не будет.
С вот этими расчетами собирается команда (15 человек) и решается мы покупаем это оборудование или есть другое решение.
Даже в таком стеснённом сценарии получается, что отнимется от ЗП не такой уж и большой процент. Да, премия отнимается на 100%. Но решение о покупке не принимается одним лицом. Если хозяин компании хочет купить что-то сам, не согласовывая с коллективом — пускай вкладывает свои деньги (он же получает прибыль от компании не как ЗП).
Итого. В сухом остатке используя предложенный подход, мы формально купили за деньги то, что нельзя купить за деньги. А именно производственные отношения и согласованность. Если работать по-старинке, то потери бизнеса от простоя и прочих эффектов от неправильного управления бывают и меньше (если начальству повезло и с принятием решений, и с ситуацией во внешнем мире), и сильно больше (ну если с чем-то не повезло).
Максимум сигмоиды зависит от прибыли компании и увеличения прибыли компании за период (последнее дает более быстрый feedback для новичков). А конкретное значение от усилий сотрудника.
Формально граница дохода есть, но она растет с прибылью компании (ну и падает тоже).
Я правильно понимаю, что вариант банкротства крупного заказчика (и последущего провала выручки) бьет по карману всем?
Да. И это правильно т.к. коллектив будет заинтересован выйти из такой ситуации. Весь. А не только кучка управляющих. См. комментарий raptor. В видео был момент, где описывается подобная ситуация.
Я правильно понимаю, что инвестиция в средства производства (скажем, закупка крутого блейд-сервака под виртуалки для проекта) бьет по карману всем?
По моему опыту железо стоит дешевле чем ЗП сотрудников. Да, формально влияет. Но это тоже правильно. Это даст сигнал команде, что мы можем тратить деньги на оборудование, а можем переписать часть проекта, чтобы оно быстрее работало и нам не придется покупать новое оборудование.
N.B. Достаточное мерзкий момент в работе, когда начальник считает «это сотрудник не должен знать». При таком формате увеличивается вероятность того, что сотрудник будет делать не то, что надо, и будет делать не различая задания, которые нужно сделать быстро, и задания, которые нужно сделать качественно.
Я правильно понимаю, что найм уборщицы вместо установления графика дежурств бьет по карману всем?
Я понимаю, что уборщица это самый прикольный пример. Я уже выше писал
Сотрудник, который просто пришел, сделал свою работу, получил деньги — это хороший исполнитель. Его не обязательно нанимать в штат, можно просто договориться за конкретные деньги на конкретное задание. Ему вообще не обязательно платить регулярно.
И еще раз. Мой ответ да. Сотрудники должны понимать, что офисное пространство занимает часть бюджета. Обслуживание офисного пространства тоже занимает часть бюджета. На каком-то этапе сотрудники вполне имеют право собраться и сказать «нам этот офис слишком дорого обходится, давайте мы переедем в другой офис, который по-дешевле». В случае прямого управления этой возможности просто нету.
Посмотрел. Фильм на хорошую 4. Чем-то отдалённо напомнил войны Пентагона (например некоторыми актерами).
По моей оригинальной задумке сотрудник не должен задалбываться вопросами «а не хочешь ли ты перейти». Максимум напомнить раз в пол года. Но можно даже этого не делать.
А вообще есть комментарий raptor чуть ниже, где предлагают просто ввести систему оценки принудительно и для всех сразу, включая директоров. И у них это работает.
ИМХО метрики и коэффициенты должны направлять сотрудника на более приоритетные задания и приводить к тому, что команда сама была заинтересована в том, чтобы достичь конечного результата. Отсеивание неэффективных сотрудников — дополнительный положительный эффект для компании.
Еще не смотрел. Посмотрел трейлер. Понравился.
Но если по делу. Какой бы ни была работа, как бы она не была организована, она будет нелогичной и противоестественной. Поскольку у человека заложен механизм энергосбережения (лень, а следовательно работа противоестественна) и природное желание жить лучше (которое порождает конфликт с ленью, что и приводит к нелогичности).
Если уже совсем конкретно. Проблемы в управлении компании всегда будут влиять на доход сотрудников. Либо это будет выражаться в том, что не поднимают регулярно ЗП, либо в том, что будут сокращения.
В классическом случае этот эффект достаточно сильно задерживается.
В предложенном варианте всё достаточно прозрачно и все сотрудники компании достаточно быстро могут ощутить, что что-то пошло не так. И это хорошо т.к. это может активизировать внутренние силы для решения проблем. Смысл бонусов сделать так, чтобы сотрудники работали лучше в целом.
Смысл бонусов «чтобы угодить всем» — это очень серьезное заблуждение.
В статье сказано «Некоторую фиксированную часть от бонуса жизненно необходимо сделать субъективной. Эта часть должна отражать отношение менеджера к тому как работает данный отдельный сотрудник.» Это может сглаживать тот момент, что кто-то работал лучше, а кто-то хуже. По-среднему, уже не получится, только если этого не захочет начальник напрямую, что действительно приводит к тому что вы описываете и к тому что было сказано в статье см. «Тут есть один антипаттерн, которого нужно избежать».
Здесь немного о другом.
Сотрудник, который просто пришел, сделал свою работу, получил деньги — это хороший исполнитель. Его не обязательно нанимать в штат, можно просто договориться за конкретные деньги на конкретное задание. Ему вообще не обязательно платить регулярно.
Любой менеджер, который нанимает сотрудника на ЗП будет хотеть получить от сотрудника максимум. Другое дело какими методами. Методы в оригинальной статье достаточно бесчеловечны и сильнее подвержены игре в крысиные бега с полным увольнением адекватных сотрудников. В моем варианте сотрудник УЖЕ получает ту ЗП на которую договаривался.Не меньше.
Если сотрудник инициативный и хочет приносить компании больше пользы, то здесь открывается больше возможностей приносить реальную пользу вместо того, чтобы просто «сделать больше коммитов, тасков, прочего».
Здесь нет принудиловки в том, что твоя ЗП исключительно зависит от прибыли компании.
Да, и кстати, по поводу бонусов вообще. Как бы бонусы не начислялись всегда найдутся те, кто будет считать, что это несправедливо. (Даже вынес это в disclaimer)
Да, влияет. По правильному за несоблюдения условий работы труда должен полагаться штраф (по аналогии с тем как полагается штраф от санэпидемстанции за несоблюдение условий хранения продуктов в магазине). Труд уборщицы уменьшает расходы, которые необходимо было бы заплатить в качестве штрафа. Существование такого штрафа для оценки полезности уборщицы не критично, такой штраф можно придумать. Пускай к вам в офис пришел партнер договариваться, а у вас не убрано. Сделка сорвалась. После этого быстро станет понятно, что отсутствие уборщицы принесло вам убыток.
Условия труда для сотрудника не меняются в худшую сторону. Если он хочет оставаться по-классике на fixed-rate, пусть остается. Но сверху ему все-равно добавляются бонусы.
Если компания нанимает людей просто чтобы нанять, то у компании проблемы с управлением.
Если компания нанимает людей и занимает их какой-то ерундой, а не нужными заданиями, то у компании проблемы с управлением.
Если компания нанимает людей и занимает и не может нормально расставить приоритеты, то у компании проблемы с управлением.
Если компания построила рабочий процесс так, что то, что делают сотрудники, не влияет на прибыль компании то зачем компании вообще сотрудники и так всё хорошо, то у компании проблемы с управлением.
На самом деле
Вообще если у компании есть какие-то проблемы, то в основном это означает у компании проблемы с управлением.
BTW. Одна из интересных особенностей. Вообще-то сотрудник на каком-то этапе может сказать «а вот это задание я делать не буду, т.к. оно принесёт компании ущерб».
Подобная концепция уже была реализована. См. jetbrains mps.
Ваша реализация есть. Это уже хорошо.
Хорошим показателем пригодности подхода являются результаты. Есть хотя бы один живой проект написанный при помощи этой системы? (За примерами далеко ходить не надо Facebook использует React, Google использует Tensor flow, т.е. продукт не создавался в вакууме, а потом ему находили применение, а сначала показали применение, а потом сказали «а знаете, а давайте теперь все будем это поддерживать, потому что мы задолбались» Прим. бывают и другие мотивы)
Первым проектом может быть замыкание на себя. Обычная практика если ты пишешь новый ЯП, переписать как можно быстрее его же транслятор/компилятор на нём же. См. coffeescript. См. http://hiasm.com/, сайт написан на своей же системе.
Это уже сделано?
Прим. Еще будет огромная проблема с созданием нормальной системы контроля версий под проекционные языки программирования (если вы храните всё в AST). Если вы не храните в AST будет другая проблема, загрузка большого проекта может занимать 15 минут т.к. все DSL и прочее требуют строгой очерёдности парсинга. Использование git'а для xml или json будет порождать необходимость делать merge за пределами няшной IDE, что добавляет трудности и очевидный вопрос «если мне merge'ить все-равно приходится в текстовом редакторе, то может я и код буду писать в текстовом редакторе?»
По поводу первых 32 бит, которые должны быть нулями. Можно и нужно считать их сразу все вместе. Получится, во-первых, меньше логики, во-вторых, в ПЛИСах уже есть DSP блоки, на которые можно повесить дорогое сложение вместо драгоценных ячеек (в ASIC'ах всё по-другому).
По поводу параллельного вычисления нескольких хэшей. Уже много лет как есть midstate. Все обертки для майнеров уже загружают в любые (CPU/GPU/FPGA/ASIC) майнеры не оригинал, с которого нужно взять sha256, а промежуточный результат (состояние всех блоков в SHA256 на определённом раунде), который уже вычислен на процессоре.
Про самый главный трюк, который реально позволяет выжимать всё из кремния не рассказали. Вместо того, чтобы увеличивать частоту можно наоборот уменьшать её, но при этом увеличивать набор логики между защелками. Тогда можно сэкономить на «слишком хороших» задержках, которые всегда оказываются при слишком большом дроблении. Например, совместив 8 раундов в одном такте мы скорее всего выровняем фронт лучше, чем для одного раунда на такт.
С ASIC можно пойти дальше. Нам же никто не мешает использовать кристалл по-больше. Следовательно мы можем к всему прочему понизить вольтаж, но увеличить количество элементов на кристалле. Сбойные блоки можно отключить при тестировании. Остальные не влияют, т.к. задача майнинга специфична, можно перепроверять на надёжном процессоре. Итого потребление то же, а производительность больше. Понятное дело понижать получится до определённого предела и где-то будет оптимум.
// Скорее всего я здесь допустил много неточностей в терминах и некоторых формулировках, но примерная суть должна быть ясна.
Я перепутал прибыль и доход. Каждый сотрудник компании (в идеале) должен быть в плюс.
Я перепутал ЗП и «деньги на руки». От денег на руки урезается не такой и большой процент.
Если агрегировать всё, что было в комментариях, то получается несколько групп людей
Для первых указанная в статье система применима напрямую.
Для вторых применима плата за конкретный результат либо за затраченные часы, с некоторой натяжкой можно применять ту же систему, что и для п.1 (т.к. сферических сотрудников в вакууме не бывает, сегодня он во второй группе, а завтра в первой).
Для третьих применима ставка и может быть доплата за затраченные часы (доплата может быть отрицательной, если делать как на заводах Форда). Если доплату таки делать отрицательной, то вообще-то система, внезапно, становится условно применима. Условно потому, что нужно достаточно хорошо подстраивать систему под прикладную сферу.
По поводу оборудования. Обычно оборудование стоит сильно меньше чем суммарная ЗП сотрудников за месяц.
Но рассмотрим достаточно экстремальный случай, когда это не так. Пускай у нас команда из 15 сотрудников. Каждому в среднем платим 2k$ fixed rate'а. Итого расход 30k$. Пускай компания имеет прибыль 45k$. Период премии 3 месяца. До покупки оборудования у нас было 15k$ прибыли. 50% из них отдавалась на бонусы. Т.е. 7,5k$. Т.е. +500$ в среднем каждому (с учётом разброса это будет 300-700$ в зависимости кто как работал).
Мы хотим купить оборудование на 50k$. Во-первых, мы должны понимать, что покупка нового оборудования должна окупиться. Иначе мы просто тратим деньги. Ладно, самый худший случай. Если мы не купим оборудование, то понесём убытки.
Пускай у нас есть свободные деньги компании на покупку 50k$. Такая покупка автоматически делает -50k$ в отчете компании. За 3 месяца это едва ли окупится в ноль. 15*3=45k$. Получается, что за этот период премии вообще не будет.
С вот этими расчетами собирается команда (15 человек) и решается мы покупаем это оборудование или есть другое решение.
Даже в таком стеснённом сценарии получается, что отнимется от ЗП не такой уж и большой процент. Да, премия отнимается на 100%. Но решение о покупке не принимается одним лицом. Если хозяин компании хочет купить что-то сам, не согласовывая с коллективом — пускай вкладывает свои деньги (он же получает прибыль от компании не как ЗП).
Итого. В сухом остатке используя предложенный подход, мы формально купили за деньги то, что нельзя купить за деньги. А именно производственные отношения и согласованность. Если работать по-старинке, то потери бизнеса от простоя и прочих эффектов от неправильного управления бывают и меньше (если начальству повезло и с принятием решений, и с ситуацией во внешнем мире), и сильно больше (ну если с чем-то не повезло).
Формально граница дохода есть, но она растет с прибылью компании (ну и падает тоже).
По моему опыту железо стоит дешевле чем ЗП сотрудников. Да, формально влияет. Но это тоже правильно. Это даст сигнал команде, что мы можем тратить деньги на оборудование, а можем переписать часть проекта, чтобы оно быстрее работало и нам не придется покупать новое оборудование.
N.B. Достаточное мерзкий момент в работе, когда начальник считает «это сотрудник не должен знать». При таком формате увеличивается вероятность того, что сотрудник будет делать не то, что надо, и будет делать не различая задания, которые нужно сделать быстро, и задания, которые нужно сделать качественно.
Я понимаю, что уборщица это самый прикольный пример. Я уже выше писалИ еще раз. Мой ответ да. Сотрудники должны понимать, что офисное пространство занимает часть бюджета. Обслуживание офисного пространства тоже занимает часть бюджета. На каком-то этапе сотрудники вполне имеют право собраться и сказать «нам этот офис слишком дорого обходится, давайте мы переедем в другой офис, который по-дешевле». В случае прямого управления этой возможности просто нету.
По моей оригинальной задумке сотрудник не должен задалбываться вопросами «а не хочешь ли ты перейти». Максимум напомнить раз в пол года. Но можно даже этого не делать.
А вообще есть комментарий raptor чуть ниже, где предлагают просто ввести систему оценки принудительно и для всех сразу, включая директоров. И у них это работает.
ИМХО метрики и коэффициенты должны направлять сотрудника на более приоритетные задания и приводить к тому, что команда сама была заинтересована в том, чтобы достичь конечного результата. Отсеивание неэффективных сотрудников — дополнительный положительный эффект для компании.
Но если по делу. Какой бы ни была работа, как бы она не была организована, она будет нелогичной и противоестественной. Поскольку у человека заложен механизм энергосбережения (лень, а следовательно работа противоестественна) и природное желание жить лучше (которое порождает конфликт с ленью, что и приводит к нелогичности).
https://habrahabr.ru/post/313174/#comment_9870068
и частично https://habrahabr.ru/post/313174/#comment_9870010
В классическом случае этот эффект достаточно сильно задерживается.
В предложенном варианте всё достаточно прозрачно и все сотрудники компании достаточно быстро могут ощутить, что что-то пошло не так. И это хорошо т.к. это может активизировать внутренние силы для решения проблем. Смысл бонусов сделать так, чтобы сотрудники работали лучше в целом.
Смысл бонусов «чтобы угодить всем» — это очень серьезное заблуждение.
Здесь немного о другом.
Сотрудник, который просто пришел, сделал свою работу, получил деньги — это хороший исполнитель. Его не обязательно нанимать в штат, можно просто договориться за конкретные деньги на конкретное задание. Ему вообще не обязательно платить регулярно.
Любой менеджер, который нанимает сотрудника на ЗП будет хотеть получить от сотрудника максимум. Другое дело какими методами. Методы в оригинальной статье достаточно бесчеловечны и сильнее подвержены игре в крысиные бега с полным увольнением адекватных сотрудников. В моем варианте сотрудник УЖЕ получает ту ЗП на которую договаривался.Не меньше.
Если сотрудник инициативный и хочет приносить компании больше пользы, то здесь открывается больше возможностей приносить реальную пользу вместо того, чтобы просто «сделать больше коммитов, тасков, прочего».
Здесь нет принудиловки в том, что твоя ЗП исключительно зависит от прибыли компании.
Да, и кстати, по поводу бонусов вообще. Как бы бонусы не начислялись всегда найдутся те, кто будет считать, что это несправедливо. (Даже вынес это в disclaimer)
то зачем компании вообще сотрудники и так всё хорошо, то у компании проблемы с управлением.BTW. Одна из интересных особенностей. Вообще-то сотрудник на каком-то этапе может сказать «а вот это задание я делать не буду, т.к. оно принесёт компании ущерб».
Ваша реализация есть. Это уже хорошо.
Хорошим показателем пригодности подхода являются результаты. Есть хотя бы один живой проект написанный при помощи этой системы? (За примерами далеко ходить не надо Facebook использует React, Google использует Tensor flow, т.е. продукт не создавался в вакууме, а потом ему находили применение, а сначала показали применение, а потом сказали «а знаете, а давайте теперь все будем это поддерживать, потому что мы задолбались» Прим. бывают и другие мотивы)
Первым проектом может быть замыкание на себя. Обычная практика если ты пишешь новый ЯП, переписать как можно быстрее его же транслятор/компилятор на нём же. См. coffeescript. См. http://hiasm.com/, сайт написан на своей же системе.
Это уже сделано?
Прим. Еще будет огромная проблема с созданием нормальной системы контроля версий под проекционные языки программирования (если вы храните всё в AST). Если вы не храните в AST будет другая проблема, загрузка большого проекта может занимать 15 минут т.к. все DSL и прочее требуют строгой очерёдности парсинга. Использование git'а для xml или json будет порождать необходимость делать merge за пределами няшной IDE, что добавляет трудности и очевидный вопрос «если мне merge'ить все-равно приходится в текстовом редакторе, то может я и код буду писать в текстовом редакторе?»
http://mathieuancelin.github.io/js-repaint-perfs/angular-track-by/