Они сцеплены но их две, а не 200. Собственно я об этом и говорил. Все эти небольшие сцепленные цепочки будут в OoO выполняться практически "параллельно", скрывая latency.
Для OoO это практически эквивалентное "нет зависимостей", самое паршивое это когда инструкции сцеплены друг за другом, когда результат одной является аргументом другой и так по всей цепочки. (проблема критического пути в графе исполнения инструкций) А вот такие относительно независимые куски, должны колбаситься на ура.
Это "дополнительное пространство" имеет константный размер как функция от размера входного массива, то есть O(1). (а то что речь идет про O(1) понятно из контекста задачи)
inplace radix sort, по времени O(N) и памяти O(1), не накладывает никаких дополнительных ограничений. Как тебе такое Илон Маск? ) (как его реализовать я конечно на собеседовании вряд ли вспомнил, но так это наименее безумный вариант. который к тому же уже где то "в интернете" наверняка реализован)
Ссылку на гитхаб дадите? Или расскажите, что вам еще за это и деньги платили? )
Вы же сами подглядываете в то, что для вас Go компилирует, так почему сразу не сделать как хочется?
Потому что даже "просто сделать", сложнее. Не говоря о том, что это еще и поддерживать надо, а это сложнее еще на порядок. А компиляторы уже давно компилируют субоптимальный код, если им не мешать, или понять что мешает.
Сложно по сравнению с чем? С биндингами на Си(или как тут посоветовали ассемблере)? Или не оптимизированным кодом, дающем в три раза меньшую производительность? ("извините но у нас лапки")
Да и называть "портянкой" дополнительные 6 строк кода, в которых даже для меня, человека не знакомого с go, очевидно что происходит, довольно странно.
И я как бы исхожу из предположения, об адекватности автора статьи, и то что это не бессмысленный premature optimization, а реальный хотспот. И в обработке изображений и растеризации такое сплошь и рядом.
А вы пробовали на нем писать, что-то больше пары строчек? А потом еще и поддерживать? Странный совет, на вполне нормальное желание разобраться, как работает код и как его можно ускорить. Если писать что-то производительное на плюсах, то это вообще первым пунктом идет - посмотреть асм выхлоп и понять его.
Если код прошол автотесты, довольно странно если билд совсем не рабочий. А то что прошол должно быть частью паплайна разработки и CI/CD. Но если не работает, то надо дополнять новыми тестами, в этом и есть ответственность разработчика.
ARM не открытая, там надо занести значительные деньги чтобы делать свой дизайн под их ISA. И не все ARM это SoC. Никто не мешает взять процессорное ARM ядро навесить на него PCI-E шину и ставить, что-то распространенное с уже готовыми линукс драйверами.
Что такое простые хэши? Когда два фала побайтово одинаковы? Если речь про "визуальные хэши" из статьи, то я не уверен, что они сильно быстрее какой-то простой дистилированной нейронки типа Mobilenet.
Да, но только господин Маск, купил твиттер уже по очень завышенной оценке, и была произведена процедура делистинга. Соответственно, чтобы продать еще дороже, ему нужно кратное увеличение всех ключевых показателей и снова выводить компанию на биржу.
Ну 30-40 это при сценарии сравнимом по оптимистичности с безумством. Если считать те же относительно "честные" Capitalization/EBITDA получается 200 лет для твиттера, и 38 лет для Теслы, так что я бы тут поспорил. Но вообще, пойнт был в другом, и вы упускаете один момент. Я не в курсе в каком объеме покупал(или как они ему достались) господин Маск акции Теслы, но явно когда это было ценник был на порядок ниже. Так что все что есть на данный момент это прибыль господина Маска. А с твиттером в этом разрезе совсем неприятный казус вышел.
Да уж, похоже все таки, что господин Маск конкретно влетел на бабки. Твиттер в лучшие времена стоил 8 выручек, и имел выручку 5 ярдов и EBITDA 200M. Даже если всех уволить примерно 6000 и 300K зарплаты в среднем, и приплюсовать к EBITDA, наверное можно получить 1-1.5 ярда прибыли, то есть срок окупаемости 30-40 лет. При идеальных условиях, что мы будем эту корову только доить, а кормить нет, и при условии что посещение твиттера будет как в лучшие времена и рекламодатели тоже.
Зависит от начального уровня ) если совсем начальный стоит что-то почитать по кейвердам: "convolutional neural network/deep learning", "deep learning embedding" (по сути это те самые "хэши", только более универсальные и устойчивые к различным "трансформациям").
Дальше, вот здесь к примеру с кодом и доступно описан процесс(deep learning image deduplication/similarity search):
Они сцеплены но их две, а не 200. Собственно я об этом и говорил. Все эти небольшие сцепленные цепочки будут в OoO выполняться практически "параллельно", скрывая latency.
Для OoO это практически эквивалентное "нет зависимостей", самое паршивое это когда инструкции сцеплены друг за другом, когда результат одной является аргументом другой и так по всей цепочки. (проблема критического пути в графе исполнения инструкций) А вот такие относительно независимые куски, должны колбаситься на ура.
То что хуже совсем не очевидно, надо мерить. У этого load-store нет прямых зависимостей поэтому может не плохо лечь на типичное OoO.
Это "дополнительное пространство" имеет константный размер как функция от размера входного массива, то есть O(1). (а то что речь идет про O(1) понятно из контекста задачи)
inplace radix sort, по времени O(N) и памяти O(1), не накладывает никаких дополнительных ограничений. Как тебе такое Илон Маск? ) (как его реализовать я конечно на собеседовании вряд ли вспомнил, но так это наименее безумный вариант. который к тому же уже где то "в интернете" наверняка реализован)
Ссылку на гитхаб дадите? Или расскажите, что вам еще за это и деньги платили? )
Потому что даже "просто сделать", сложнее. Не говоря о том, что это еще и поддерживать надо, а это сложнее еще на порядок. А компиляторы уже давно компилируют субоптимальный код, если им не мешать, или понять что мешает.
Сложно по сравнению с чем? С биндингами на Си(или как тут посоветовали ассемблере)? Или не оптимизированным кодом, дающем в три раза меньшую производительность? ("извините но у нас лапки")
Да и называть "портянкой" дополнительные 6 строк кода, в которых даже для меня, человека не знакомого с go, очевидно что происходит, довольно странно.
И я как бы исхожу из предположения, об адекватности автора статьи, и то что это не бессмысленный premature optimization, а реальный хотспот. И в обработке изображений и растеризации такое сплошь и рядом.
А вы пробовали на нем писать, что-то больше пары строчек? А потом еще и поддерживать? Странный совет, на вполне нормальное желание разобраться, как работает код и как его можно ускорить. Если писать что-то производительное на плюсах, то это вообще первым пунктом идет - посмотреть асм выхлоп и понять его.
Так вроде уже давно, как есть RDP и VCN.
Мотивация практически всегда первична. Если это истинный интерес, и он не затухает, то горы можно свернуть.
Если код прошол автотесты, довольно странно если билд совсем не рабочий. А то что прошол должно быть частью паплайна разработки и CI/CD. Но если не работает, то надо дополнять новыми тестами, в этом и есть ответственность разработчика.
ARM не открытая, там надо занести значительные деньги чтобы делать свой дизайн под их ISA. И не все ARM это SoC. Никто не мешает взять процессорное ARM ядро навесить на него PCI-E шину и ставить, что-то распространенное с уже готовыми линукс драйверами.
Таким образом можно найти только практически одинаковые картинки, так как приведенные вами "хэши", не инвариантны даже к небольшим сдвигам.
Что такое простые хэши? Когда два фала побайтово одинаковы? Если речь про "визуальные хэши" из статьи, то я не уверен, что они сильно быстрее какой-то простой дистилированной нейронки типа Mobilenet.
Да, но только господин Маск, купил твиттер уже по очень завышенной оценке, и была произведена процедура делистинга. Соответственно, чтобы продать еще дороже, ему нужно кратное увеличение всех ключевых показателей и снова выводить компанию на биржу.
Каких проектов? Теслы и Стралинка?
Каким образом? Субсидировать им рекламу на платформе? Или посредством потока своих гениальных твитов, которые уже многим успели поднадоесть?
Ну 30-40 это при сценарии сравнимом по оптимистичности с безумством. Если считать те же относительно "честные" Capitalization/EBITDA получается 200 лет для твиттера, и 38 лет для Теслы, так что я бы тут поспорил. Но вообще, пойнт был в другом, и вы упускаете один момент. Я не в курсе в каком объеме покупал(или как они ему достались) господин Маск акции Теслы, но явно когда это было ценник был на порядок ниже. Так что все что есть на данный момент это прибыль господина Маска. А с твиттером в этом разрезе совсем неприятный казус вышел.
Да уж, похоже все таки, что господин Маск конкретно влетел на бабки. Твиттер в лучшие времена стоил 8 выручек, и имел выручку 5 ярдов и EBITDA 200M. Даже если всех уволить примерно 6000 и 300K зарплаты в среднем, и приплюсовать к EBITDA, наверное можно получить 1-1.5 ярда прибыли, то есть срок окупаемости 30-40 лет. При идеальных условиях, что мы будем эту корову только доить, а кормить нет, и при условии что посещение твиттера будет как в лучшие времена и рекламодатели тоже.
Зависит от начального уровня ) если совсем начальный стоит что-то почитать по кейвердам: "convolutional neural network/deep learning", "deep learning embedding" (по сути это те самые "хэши", только более универсальные и устойчивые к различным "трансформациям").
Дальше, вот здесь к примеру с кодом и доступно описан процесс(deep learning image deduplication/similarity search):
https://www.oreilly.com/library/view/practical-deep-learning/9781492034858/ch04.html
https://github.com/idealo/imagededup
Судя по всему как раз бизнес делает эппл, снимая все сливки. А делатели, вернее "технические реализаторы" как-то не очень.