Когда видят человека, который научился зарабатывать на рынке
Думаю, дело в том, что пока что никто не видит "человека, который научился зарабатывать на рынке". Все видят кучу воды, которую можно сократить до двух предложений: "зарабатывать трейдингом можно, но это сакральное знание, доступное только избранным. И даже если ты избранный — истина тебе откроется только если идти к ней 10 лет". Было бы в ваших словах хоть немного конкретики и меньше чсв-шных выпадов а-ля "вы все — глупая молодежь, а я — д’Артаньян разносторонняя личность" — никто бы вас не минусил.
У меня вот сразу напрашиваются вопросы:
По вашим словам, вы вышли в стабильный плюс. Можете ли вы описать свою стратегию в виде набора конкретных (более-менее) правил? Без абстрактных "интуиции", "опыта", "чуйки" и прочих вещей, которые чудесным образом сами появляются через 10 лет и никак не могут быть формализованы и описаны.
Если да, то что мешает оформить эту стратегию в виде статьи? Её чтение, понимание и осознание, я уверен, заняло бы намного меньше 10 лет. Особенно у человека с экономическим бекграундом.
Хотелось бы также больше конкретики в описании итогового заработка. Сумма вложений, средний доход в месяц, его стандартное отклонение, вот это вот все. А то все люди ведь разные, и под требования "стабильный плюс" и "большая часть доходов" для кого-то подпадает доход порядка 5К ± 1К баксов в месяц, а для кого-то и 300 ± 250 баксов в месяц — уже достаточно стабильно и доходно.
И? Игра с нулевой суммой подразумевает, как не странно, нулевую сумму выигрышей участников. То есть, условно, если Вася проиграл 100 монет, а Петя и Сережа выиграли по 50 — то да, это игра с нулевой суммой (50 + 50 + (-100) = 0). В случае же с опционами и прочими казино итоговая сумма будет меньше нуля за счет комиссий. И в ситуации выше "брокер" возьмет (опять таки, условно) 2% комиссии за "сделку" и выигрыш Пети с Сережей будет уже не по 50 монет, а по 49, а проигрыш Васи — не 100 монет, а 102 и итоговая сумма будет уже 49 + 49 + (-102) = -4. Это не нулевая сумма.
Классно придумано! Отличное решение проблемы. Если об этом не говорить, то это перестанет существовать. Ведь "молодые хуцкеры" нигде не смогут узнать о фишинге помимо хабра. И уж тем более никак не смогут догадаться до такой сверх-сложной схемы самостоятельно.
Да, код конечно не самый актуальный, но тем не менее, он есть. При наличии достаточного уровня паранойи можно для себя собирать клиент самому. Хотя, с учетом закрытого сервера, для параноика затея все равно спорная)
Закрыты только исходники серверной части. Все официальные клиенты открыты. И для десктопа и для мобилок. Только Telegram X был без исходников, но его вроде из сторов убрали (во всяком случае, в App Store я его не находил пару недель назад).
Во-первых, "на рассматриваемом отрезке" асимптотическая оценка алгоритма не имеет смысла. Если входные данные ограничены, то любой алгоритм формально работает за О(1).
Во-вторых, на любом отрезке поведение O(N) ни разу не близко к поведению O(Log N). В первом случае увеличение инпута в 10 раз в те-же 10 раз увеличит и время выполнения, какой бы маленькой не была константа. Во втором же случае время исполнения увеличится всего лишь на некоторую константу.
Ну и в третьих, Integer.MAX_VALUE — это довольно много. Даже для самого векторизированного линейного алгоритма время обработки такого объема входных данных на современных CPU будет измеряться сотнями миллисекунд, а то и секундами. В то время как самый дохлый и не оптимизированный логарифм отработает мгновенно.
Векторизация в лучшем случае поделит время выполнения на константу. На асимпотику это никак не повлияет (если, конечно, не рассматривать какие-то гипотетические вычислительные устройства с неограниченным количеством SIMD потоков).
действительно опытные разработчики в таких средствах не нуждаются вовсе.
Спорно. Даже самый опытный гуру может отвлечься/задуматься не о том/опечататься и т.д. и в результате получить в коде какую-то дичь. И далеко не всегда эта дичь вылезет сразу. Может оставаться в коде месяцами и годами.
Так в том-то и дело, что не проверили. Невозможно сведенным графиком загрузки CPU и замером времени с секундомером проверить влияние GPU на некий процесс.
почему нельзя, например, считать хэши ассетов?
Теоретически — можно. На практике — во-первых, юнити так не делает, в чем несложно было бы убедиться, если бы вы хоть одним глазом взглянули на уровень загрузки GPU. А во-вторых — подсчет хешей для майнинга очень отличается от подсчета хешей для импорта проекта в юнити. И перенос его на GPU вряд ли сильно скажется на производительности. А если и скажется, то далеко не факт, что положительным образом. Майнеру не нужно гонять кучу информации с диска через основную память на видеочип и обратно. И у майнера блоки, для которых нужно считать хеш — одного размера. И еще много менее значительных нюансов, которые в сумме делают перенос импорта проекта на GPU спорной, мягко говоря, затеей.
Не говоря уже о том, что непосредственно подсчет хешей занимает очень небольшую часть времени при импорте. Намного дольше происходит конвертация ассетов в удобоваримый для юнити формат. В проекте, над которым я сейчас работаю, подсчет хешей — это порядка 7-8% от общего времени импорта.
Для комфортной разработки нужна и высокая тактовая частота процессора, и большое количество потоков.
Вот неожиданность-то. Кто бы мог подумать?! Казалось бы, с низкой частотой и меньшим количеством потоков будет лучше, но нет!
[/sarcasm]
1) Это никак не следует из проведенных измерений. Какую вообще информацию можно извлечь из сведенных графиков загрузки всех ядер? Их можно проинтерпретировать сотней способов. Может i5 действительно не хватает ядер, а E5 — частоты. А может количество ядер ни на что особо не влияет, т.к. большую часть времени график выглядит как 100% загрузка одного ядра. А может это все таки равномерно низкая загрузка всех ядер и боттлнек совсем не в процессоре, а например, в диске (стоило использовать ram диск, или как минимум — нормальный быстрый NVME накопитель, но уж точно не "Самый дешевый китайский SSD")
2) Не указан объем памяти и уровень ее использования при сборке. Может ее не достаточно и на самом деле вместо производительности процессора измерялась производительность системы swaping-а ОС и все того-же "самого дешевого SSD"?
Вам не обязательно нужна самая крутая видеокарта. Особенно, если вы делаете мобильные игры.
Еще одна неожиданность! Время выполнения процесса, не использующего видеокарту от слова совсем, с хорошей дорогой видеокартой — такое-же, как и с плохой дешевой. Чудеса, да и только. Стоило еще измерить время сборки для разных мониторов, клавиатур и кресел.
1) Каким боком вообще видеокарта к процессам сборки и импорта?
2) Зачем нам графики загрузки процессора, если мы тестируем видеокарту?
3) Почему нет графиков загрузки видеоядра и видеопамяти?
4) Почему нет измерений для процессов, где видеокарта действительно используется, как, например, работа со сценой в редакторе, ну или там сравнение загруженности и производительности видеочипа при игре в редакторе и в standalone сборке?
Кроме того, рекомендую использовать SSD, поскольку Unity активно работает с файлами. Если вы ограничены в бюджете, можно взять даже самый дешевый SSD на 8 или 16 Gb, чтобы хранить на нем сам проект, а также установить туда Unity и все необходимые SDK.
1) Это, опять таки, никак не следует из измерений, произведенных в статье. Нет ни измерения скорости передачи данных с диска, ни измерения IOPS, ни хотя-бы топорного сравнения времени сборки/импорта c SSD и c HDD.
2) Этот пункт стоило написать первым. Стоимость SSD уже давно не кусается. Можно спокойно взять нормальный SSD гиг на 120, а то и 240 даже за счет удешевления других компонентов. Производительность и комфорт с системой со средненьким процессором и нормальным SSD будет на порядок лучше, чем с системой с убер-топовым процем и дешманским HDD или "самым дешевым китайским SSD на 8 Gb".
Я бы мог понять смысл всех этих измерений и манипуляций, если бы вы просто выбирали себе новое железо "из того, что есть" под ваши старые комплектующие. Но ценность описания этого процесса в виде статьи — околонулевая.
"При должном знании и умении" можно было наделать всякого задолго до появления deepfakes и более качественно, чем это делает deepfakes.
Тут особенность именно в том, что теперь это можно делать без особых знаний и умений.
Интерфейс не является чем-то неприкасаемым. В одной из веток из интерфейса точно так-же могут удалить или переименовать метод и сломать тем самым код после бесконфликтного мерджа с другой веткой, использующей этот удаленный метод.
В математике единице равен предел x^x при x стремящемся к нулю справа. А именно 0^0 — это неопределенность, как не крути. И то, что ее принимают за единицу — это именно особенность языка. И факториал нуля тут совершенно не к месту. Он равен единице как «empty product» (хз, есть ли устоявшийся перевод на русский) https://en.m.wikipedia.org/wiki/Empty_product.
На Python 3 «-10» воспринимается не как отдельная константа, а как операция унарного минуса, применённая к константе 10. Замените «-10» на 500 и поведение в третьем питоне станет аналогичным поведению во втором.
Ну так-то, 0^0 — это неопределенность, а не единица. Так что в любом случае сложно назвать это очевидным.
Хотя если знать, что с интами питон ловко возвращает 1 для 0**0, вместо выбрасывания ошибки, то действительно все встает на свои места)
Думаю, дело в том, что пока что никто не видит "человека, который научился зарабатывать на рынке". Все видят кучу воды, которую можно сократить до двух предложений: "зарабатывать трейдингом можно, но это сакральное знание, доступное только избранным. И даже если ты избранный — истина тебе откроется только если идти к ней 10 лет". Было бы в ваших словах хоть немного конкретики и меньше чсв-шных выпадов а-ля "вы все — глупая молодежь, а я —
д’Артаньянразносторонняя личность" — никто бы вас не минусил.У меня вот сразу напрашиваются вопросы:
И? Игра с нулевой суммой подразумевает, как не странно, нулевую сумму выигрышей участников. То есть, условно, если Вася проиграл 100 монет, а Петя и Сережа выиграли по 50 — то да, это игра с нулевой суммой (50 + 50 + (-100) = 0). В случае же с опционами и прочими казино итоговая сумма будет меньше нуля за счет комиссий. И в ситуации выше "брокер" возьмет (опять таки, условно) 2% комиссии за "сделку" и выигрыш Пети с Сережей будет уже не по 50 монет, а по 49, а проигрыш Васи — не 100 монет, а 102 и итоговая сумма будет уже 49 + 49 + (-102) = -4. Это не нулевая сумма.
Классно придумано! Отличное решение проблемы. Если об этом не говорить, то это перестанет существовать. Ведь "молодые хуцкеры" нигде не смогут узнать о фишинге помимо хабра. И уж тем более никак не смогут догадаться до такой сверх-сложной схемы самостоятельно.
Да, код конечно не самый актуальный, но тем не менее, он есть. При наличии достаточного уровня паранойи можно для себя собирать клиент самому. Хотя, с учетом закрытого сервера, для параноика затея все равно спорная)
https://telegram.org/apps#source-code
https://github.com/peter-iakovlev/Telegram
https://github.com/DrKLO/Telegram
http://telegram.org/resources/telegram_wp.src.zip
Закрыты только исходники серверной части. Все официальные клиенты открыты. И для десктопа и для мобилок. Только Telegram X был без исходников, но его вроде из сторов убрали (во всяком случае, в App Store я его не находил пару недель назад).
Во-первых, "на рассматриваемом отрезке" асимптотическая оценка алгоритма не имеет смысла. Если входные данные ограничены, то любой алгоритм формально работает за О(1).
Во-вторых, на любом отрезке поведение O(N) ни разу не близко к поведению O(Log N). В первом случае увеличение инпута в 10 раз в те-же 10 раз увеличит и время выполнения, какой бы маленькой не была константа. Во втором же случае время исполнения увеличится всего лишь на некоторую константу.
Ну и в третьих, Integer.MAX_VALUE — это довольно много. Даже для самого векторизированного линейного алгоритма время обработки такого объема входных данных на современных CPU будет измеряться сотнями миллисекунд, а то и секундами. В то время как самый дохлый и не оптимизированный логарифм отработает мгновенно.
Векторизация в лучшем случае поделит время выполнения на константу. На асимпотику это никак не повлияет (если, конечно, не рассматривать какие-то гипотетические вычислительные устройства с неограниченным количеством SIMD потоков).
Эм… Ну да, это виста.
Только в статье картинка другая.
Потому что на скрине XP с темой "под висту"
Спорно. Даже самый опытный гуру может отвлечься/задуматься не о том/опечататься и т.д. и в результате получить в коде какую-то дичь. И далеко не всегда эта дичь вылезет сразу. Может оставаться в коде месяцами и годами.
Так в том-то и дело, что не проверили. Невозможно сведенным графиком загрузки CPU и замером времени с секундомером проверить влияние GPU на некий процесс.
Теоретически — можно. На практике — во-первых, юнити так не делает, в чем несложно было бы убедиться, если бы вы хоть одним глазом взглянули на уровень загрузки GPU. А во-вторых — подсчет хешей для майнинга очень отличается от подсчета хешей для импорта проекта в юнити. И перенос его на GPU вряд ли сильно скажется на производительности. А если и скажется, то далеко не факт, что положительным образом. Майнеру не нужно гонять кучу информации с диска через основную память на видеочип и обратно. И у майнера блоки, для которых нужно считать хеш — одного размера. И еще много менее значительных нюансов, которые в сумме делают перенос импорта проекта на GPU спорной, мягко говоря, затеей.
Не говоря уже о том, что непосредственно подсчет хешей занимает очень небольшую часть времени при импорте. Намного дольше происходит конвертация ассетов в удобоваримый для юнити формат. В проекте, над которым я сейчас работаю, подсчет хешей — это порядка 7-8% от общего времени импорта.
del
Не увидел в статье ответа на вопрос из заголовка.
Вот неожиданность-то. Кто бы мог подумать?! Казалось бы, с низкой частотой и меньшим количеством потоков будет лучше, но нет!
[/sarcasm]
1) Это никак не следует из проведенных измерений. Какую вообще информацию можно извлечь из сведенных графиков загрузки всех ядер? Их можно проинтерпретировать сотней способов. Может i5 действительно не хватает ядер, а E5 — частоты. А может количество ядер ни на что особо не влияет, т.к. большую часть времени график выглядит как 100% загрузка одного ядра. А может это все таки равномерно низкая загрузка всех ядер и боттлнек совсем не в процессоре, а например, в диске (стоило использовать ram диск, или как минимум — нормальный быстрый NVME накопитель, но уж точно не "Самый дешевый китайский SSD")
2) Не указан объем памяти и уровень ее использования при сборке. Может ее не достаточно и на самом деле вместо производительности процессора измерялась производительность системы swaping-а ОС и все того-же "самого дешевого SSD"?
Еще одна неожиданность! Время выполнения процесса, не использующего видеокарту от слова совсем, с хорошей дорогой видеокартой — такое-же, как и с плохой дешевой. Чудеса, да и только. Стоило еще измерить время сборки для разных мониторов, клавиатур и кресел.
1) Каким боком вообще видеокарта к процессам сборки и импорта?
2) Зачем нам графики загрузки процессора, если мы тестируем видеокарту?
3) Почему нет графиков загрузки видеоядра и видеопамяти?
4) Почему нет измерений для процессов, где видеокарта действительно используется, как, например, работа со сценой в редакторе, ну или там сравнение загруженности и производительности видеочипа при игре в редакторе и в standalone сборке?
1) Это, опять таки, никак не следует из измерений, произведенных в статье. Нет ни измерения скорости передачи данных с диска, ни измерения IOPS, ни хотя-бы топорного сравнения времени сборки/импорта c SSD и c HDD.
2) Этот пункт стоило написать первым. Стоимость SSD уже давно не кусается. Можно спокойно взять нормальный SSD гиг на 120, а то и 240 даже за счет удешевления других компонентов. Производительность и комфорт с системой со средненьким процессором и нормальным SSD будет на порядок лучше, чем с системой с убер-топовым процем и дешманским HDD или "самым дешевым китайским SSD на 8 Gb".
Я бы мог понять смысл всех этих измерений и манипуляций, если бы вы просто выбирали себе новое железо "из того, что есть" под ваши старые комплектующие. Но ценность описания этого процесса в виде статьи — околонулевая.
"При должном знании и умении" можно было наделать всякого задолго до появления deepfakes и более качественно, чем это делает deepfakes.
Тут особенность именно в том, что теперь это можно делать без особых знаний и умений.
В табличке список процессоров, поддерживаемых игрой "Meltdown". openkazan, наверное, так пошутить хотел.
Интерфейс не является чем-то неприкасаемым. В одной из веток из интерфейса точно так-же могут удалить или переименовать метод и сломать тем самым код после бесконфликтного мерджа с другой веткой, использующей этот удаленный метод.
В математике единице равен предел x^x при x стремящемся к нулю справа. А именно 0^0 — это неопределенность, как не крути. И то, что ее принимают за единицу — это именно особенность языка. И факториал нуля тут совершенно не к месту. Он равен единице как «empty product» (хз, есть ли устоявшийся перевод на русский) https://en.m.wikipedia.org/wiki/Empty_product.
На Python 3 «-10» воспринимается не как отдельная константа, а как операция унарного минуса, применённая к константе 10. Замените «-10» на 500 и поведение в третьем питоне станет аналогичным поведению во втором.
Ну так-то, 0^0 — это неопределенность, а не единица. Так что в любом случае сложно назвать это очевидным.
Хотя если знать, что с интами питон ловко возвращает 1 для 0**0, вместо выбрасывания ошибки, то действительно все встает на свои места)