All streams
Search
Write a publication
Pull to refresh
62
0
Николай Зубач @zuborg

Highload

Send message
Автору большой респект!

А можно ли, хотя бы в общих чертах, услышать соображения по работе аудио-кабеля? Особенно в разрезе «сделай сам из витой 7-й категории» или что-то подобное ;) А то инфы в инете вроде как и много, но компетентной — днем с огнем не сыскать ;(
Странно, что удерживание клавиш не срабатывает. Ну ладно F8, возможно там прерывание идет каждый раз на нажатие-отжатие, но shift то должен работать стабильно…
Идея хорошая, но есть один криптографический ньюанс ;) Суть в том что private-key на будущее сгенерированы и существуют уже сейчас. Т.е. получив доступ к серверам, хранящим части ключей (не ахти как сложно для соотв служб или людей с соотв квалификацией), данные можно будет расшифровать не дожидаясь срока публикации ключа. Не криптографично! ;)

Замечу, что существует и криптографическое решение поставленной задачи, которое, хотя и не позволяет полностью исключить возможность преждевременной расшифровки, но существенно ограничивает такую возможность. Условно говоря, на очень специальном оборудовании можно взломать ключ максимум всего лишь в пару раз быстрее чем ждать без взлома (используется ограниченная производительность системы памяти, где не помогает ни наращивание её обьема, ни использование многопроцессорности)
Просто у человека комп и в шахматы выигрывал ещё с бородатых времен (не у всех конечно). Чемпиона мира только 15 лет назад вот смог победить. А обладателю Го-титула комп пока сливает по полной без вариантов.
Вот интересно, если бы у самого Тесла были эти лазеры/фрезеры/транзисторы… — он стал бы властелином мира или улетел бы на Марс?
Подключаем телек к компу, открываем браузер и переходим на http://www.lagom.nl/lcd-test/
Пример с решетом Эратосфена удачно показывает, какую проблему надо в самом деле решать: не вычислять повторно то, что эффективнее закешировать. Вот один из основных корней тормознутости (есть ещё неэффективные алгортимы вычисления). Путей решений этой проблемы много, включая и использование исключительно статических html-ек, но не надо зацикливаться именно на таком режиме. Вполне адекватно даже использовать тормозное хранилище с тормозным шаблонизатором, если результат будет вычисляться один раз на несколько тысяч запросов, и кешироваться до тех пор пока будет оставаться валидным (т.е. например до добавления очередного коментария..).
Вообще-то проблема только в том что последний массив — это float[2]
Если бы там был float[100], то итоговый суммарный оверхед был бы не 350%, а доли процента.

Так что уточненная мораль сей истории состоит не в том, чтобы упорядочивать вложенные массивы по возрастанию, а в том, чтобы не создавать очень много очень мелких обьектов, когда есть возможность вместо этого создать обьектов не много, но крупных.
Что-то я туплю ) На самом деле для внутригалактических перемещений достаточно просто определить ориентацию вселенной по любым внегалактическим обьектам и измерить направление на центр галактики и расстояние от него. Даже параллакс не потребуется мерять, разве что к известным звездам для уточнения положения.
Среднее межгалактическое расстояние составляет всего 10-20 раз от их диаметра, поэтому для ориентации при значительных, но внутригалактических перемещениях хорошо подойдут объекты из соседних галактик, и даже они сами (их наклон будет другим, а значит и соотношение размеров эллипса). Так можно определить и перемещение в недалекую галактику. Для мелких перемещений соотв. подойдут ближайшие звезды, даже нескольких будет достаточно.
С пульсарами немного осложняет дело то что их характеристики зависят от того, под каким углом к оси вращения их наблюдать. Но принципиальной проблемы нет, изменения можно промоделировать и проверить результат на соответствие наблюдаемому.
Понятно что это средний трафик, в пике там и 10 наверняка.
Но все равно это очень! маленький показатель для сотни серверов.
Это средние 50Мбит на сервер, и если какой-то сервер тянет 400Мбит — значит какие-то другие 10 штук отдают по 10Мбит, т.е. сущий мизер, простаивают, по сути, вот о чем речь.
Странно, 105К серверов генерят 5ТБит, значит в среднем на 105 серверов всего 5Гбит.
Это нонсенс какой-то, для 5Гбит достаточно 10 серверов с запасом в 100%. Разного рода инсталляхи размером от 1М один древний 1U сервер с 4-мя винтами потянет до 1Гбит бендвича даже на 4Г RAM, чисто на винтах.
90% серверов, которые генерят 20-30% мирового трафика — просто греют планету ?!
Чертовски перспективный язык. Детские болезни пока есть, но эти проблемы с производительностью вполне решаемы. Отличная замена для С, когда требуется производительность, приближенная к максимальной — отставание в 2-5 раз вполне терпимо, всяко лучше чем 50-80 раз у PHP/Ruby/Python/Perl. Причем с возрастом отставание сведется до десятков процентов, а на некоторых задачах, решаемых на С/C++ через костыли — у Go ещё и выигрыш будет (я про SMP).

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

Расстраивает, что исключили из спецификаций ексепшны. Некоторые программисты жить без них не могут, да и по производительности не так уж сильно бьют. Исключили скорее всего из-за предполагаемой ориентированости языка на системное программирование, но все равно жаль, концепция то полезная.
Не линейная, разумеется. Что я пытаюсь сказать, так это то, что разные типы алгоритмов будут по разному реагировать на увеличение поля. Для брутфорсовых небольшое увеличение размера поля сильно увеличивает требуемую мощность при сохранении качества перебора (глубины, % покрытия и т.д.), т.е. на одном и том же оборудовании сильно деградирует в качестве по сравнении с игрой 19x19.
В то время как для интелектуальных алгоритмов, оперирующих обьектами и их связями, типа групп камней и их взаимного месторасположения, сложность вырастет пропорционально полиному небольшой степени от увеличения размера поля.
В этом плане человек пока ещё ведет в игре Го, за счет интеллектуального подхода игрок может победить брутфорс алгоритм при определенных условиях, в т.ч. выработать стратегию специально против него. В шахматах же такого шанса у него, похоже, уже нет.
Официального поля нет, разумеется, но Го такая особенная игра, что её можно играть и на 1000x1000.
Разница для брутфорса как раз будет существенная, площадь поля определяет кол-во возможных ходов, увеличения площади в 4 раза увеличит среднюю длительность игры (общее кол-во ходов за игру) приблизительно во столько же, плюс на каждый ход потребуется перебрать пропорционально большее кол-во вариантов, можете сами прикинуть вырастет сложность перебора, еквивалентного оному на поле 19x19…
Разумеется, для человека сложность тоже возрастет, но не на многие порядки, а всего лишь в разы.
Нашел, таки Монте-Карло ;(
У таких алгоритмов существенный недостаток — при увеличении размера поля сложность расчетов растет очень сильно. На поле 25x25 программа опять будет сливать человеку, если не научиться играть интеллектуально, без брутфорса.
Очень круто. Особенно круто то, что использовался сравнительно небольшой кластер, что косвенно указывает на то, что программа не основана на Монте-Карло (детальной инфы по программе пока не нашел, может кто-то в курсе как она работает?). А это большой прорыв, монте-карло алгоритмы все-таки тупой брутфорс, а тут (возможно) действительно по настоящему интеллектуальный алгоритм…

Занятно, что автор на самом деле ещё и является тем самым знаменитым игроком со своим крайне специфическим «космическим» стилем игры ;)

А ещё было было бы очень интересно посмотреть на игру без форы. Даже если программа играет действительно сильно и вначале будет выигрывать, то профи игрок после несколько игр наверняка сможет подстроиться под её стиль игры и найти контрмеры. И вот тут вопрос — сумеет ли программа забороть эти контрмеры… Если да — поздравляю всех с сингулярностью ;)
Что-то не верится мне в эту ваповарь. В самой презентации нет никаких технических подробностей, одни обещания чуда. Упоминается время декогеренции в 10мс — действительно неплохо, но с ростом кол-ва кубитов оно будет уменьшаться так же по експоненте, а значит что реально полезной сцепленности сотни кубитов мы не увидим ещё долго. А на отдельных кубитах каши не сваришь — ускорение даже на 20-ти кубитах спокойно обходится по эффективности на обычных компах. Для взлома 1024-х битного ключа надо два 1024-х кубитных регистров, а это пока что область далекой-далекой фантастики

Если бы у IBM или Йельского универа действительно были реализованы прорывные идеи, об этом давно было бы известно из научных публикаций, а не презентаций для инвесторов, а я что-то революционных публикаций пока не встречал.

Information

Rating
Does not participate
Location
Киев, Киевская обл., Украина
Date of birth
Registered
Activity