Любой хэш, который «упирается» в какой-то ресурс — заведомо временное решение, потому что цена ресурса со временим падает с непредсказуемой скоростью. Для нормальных денег так быть не должно. Это существенно сдерживает развитие криптовалют.
Мне кажется, в итоге кто-то переработает алгоритм так, что вообще от перебора хэшей откажутся, или покрайней мере откажутся от адаптивного алгоритма, и переделают механизм работы так, чтобы большая мощность ноды означала большую пользу для всей сети, а не для конкретно этой ноды.
Например, количество вознаграждения могло бы зависеть от того, сколько транзакций ты хранишь и на какую сумму, с защитой от мусорных.
Кроме того, само подтверждение транзакций, как таковое — это абстракция уровня работы сети. В идеале надо стремится к тому, чтобы от подтверждений отказаться, ведь по сути в проведении транзакции заинтересованы только отправитель и получатель, а в доказательстве, что транзакция была — только получатель. Но считается оно всеми нодами. Это плохой момент, просто ничего лучше пока не придумали.
Он выдал эксперимент в вертикальной плоскости за окончательный результат, в то время как это только промежуточный тест. Окончательный результат — это сложение по И всех тестов, сделанных корректно. Не по ИЛИ.
Получил результат в вертикальной — ну здорово, теперь иди разбираться чего оно не работало в горизонтальной, и что там было некорректно. Кроме того, был получен не просто результат, а конкретное число. Это гораздо лучше, потому что теперь можно оценить силу, которую якобы этот двиг развивает. А зная эту силу, можно оценить ожидаемое отклонение маятника.
И если отклонение мало — надо было замерить частоту собственных колебаний маятника и запускать/глушить с той же частотой движок, чтобы был резонанс. Тогда его система раскачивалась бы — и это было бы видно наглядно. Но вообще сдвинуть маятник с нижней точки- большой силы не надо, и должно было быть видно и так.
Тест в горизонтальной плоскости имеет приоритет и потому выглядит убедительней.
В вертикальной — можно просто электромагнит подвесить. Если пол железобетонный, то будет какая-то сила магнитного притяжения. (тут я подразумеваю, что автор умышленно не мухлюет)
И даже если не железобетонный — некоторое кол-во железа в нем может быть.
насчет «Кстати, в ArrayList мы тоже смещаем только половину массива.»
С ArrayList весь массив будет смещаться, если вставляем по индексу 0. С LinkedList мы пробегаем не более половины массива.
Есть следующий вопрос. Правильно ли я понимаю следующее. Сложности, которыми вы оперируете, находятся в разных координатных системах. Т.е., если у ArrayList и LinkedList параметр O(1) равен разному физическому времени, поэтому одинаковые сложности O(n) — не означают, что время вставки будет одинаково. Оно может ощутимо различаться.
А если мы пробегаем не весь linkedList, а как максимум его половину — сложность точно будет O(n)? Может, O(n/2) или O(n)/2? Мы же пробегаем половину.
Вообще, вопрос был с подвохом. ИМХО, если он звучал именно так, как вы написали — вы вообще не по той ветке пошли. Надо было сказать, что вставка по индексу и вставка по итератору отличаются. Поэтому, для практического применения имеет смысл сравнивать не одинаковые подходы в использовании этих сущностей, а разные. Потому, что если будешь писать программу и встанет вопрос ArrayList или LinedList — то очевидно, что для LinedList будет предполагаться использование итераторов. А если использование итераторов невозможно изза специфики алгоритма — то и вопрос такой (у правильного программиста) не возникнет. Поэтому с практической точки зрения, логичней было бы сравнивать скорость вставки в ArrayList по индексу со скоростью вставки в LinkedList по итератору. Плюс рассказать про накладные расходы, в том плане что создаются LinkedList.Node
Значит это зависит не от редактора а от движка.
у меня в gedit оно вывелось как 2 символа рядом, но курсор за черточку от буквы й поставить не давало — т.е. сам gedit видел это как 1 символ.
Я довольно давно не писал на php, но с тех времен, когда писал, смутно помню, что там не было пула коннекшенов к базе. Возможно, сейчас это не так. Но если это так, то навскидку мне кажется, что эти установки соединений с базой будут сьедать ощутимое время проца.
Рубашка меняется в момент, когда меняется ракурс съемки.
Может он 300 раз фокусник, но все перечеркивает то, как смонтировано видео. Обычно такой подход — это свидетельство видеомонтажа. Внимание телезрителя увели, просто вырезав наиболее неугодные кадры.
У такого датчика может быть плохо с ресурсом.Коррозия и все такое.
У меня как-то был самодельный датчик уровня воды в баке рукомойника на базе геркона и поплавка с магнитом. Геркон был вне воды. Но влага вокруг понятно, что была постоянно. Проработало оно лет 5-8, потом геркон залип. Когда я его разобрал, то обнаружил, что внутрь попала вода, а стекло, из которого гекрон сделан, превратилось в труху — пальцами сдавливаешь оно превращается в песок.
Очевидно, в этом случае придется проверять монаду на пустоту. Хотя да, согласен. В монаде из либы не хватает нормального механизма узнать на каком именно этапе у нас возникло бы npe.
Традиционный способ: insert работает с памятью, память в другом потоке пишется на диск.
Ваш способ: insert работает с памятью, но пишет бинлог на другой диск.
И там и тут insert работает с памятью. В первом случае это кэш, во втором это шаред. Все операции с диском в обеих случаях выполняются в другом потоке/процессе и не должны мешать друг другу. Т.е., я просто не вижу откуда может взяться такая производительность. Может быть небольшая разница, за счет разной имеплементации этих механизмов памяти. Если разница получилась значительной — это скорей всего значит, что там где вышло медленно — там скорей всего вы просто что-то недонастроили.
Вероятно, если хочется использовать такое решение, то следует озадачиться еще и такими вопросами:
Что будет, если шаред память уйдет в своп?
Что будет, если размер базы вырастет и станет больше размера шаред памяти?
Запись на диск кэшируется. Т.е., запись на диск — это тоже работа с памятью. За счет чего так выходит, что работа с шаред памятью оказалась быстрее? В принципе, этот вопрос должен был быть рассмотрен в такой статье т.к. подходит по тематике.
плюс озвученные выше.
Если база помещается в памяти, то возможно, стоит посмотреть не в сторону mysql, а в сторону каких-нибудь других баз. В частности, существуют неплохие решения, которые хранят и оперируют с данными on-memory, а для записи на диск делают fork и в отдельном процессе пишут — желательно попеременно в два файла. Тут надо отметить, что в современных архитектурах/нормальных_ОС fork не копирует данные, а использует copy-on-write идиому, поэтому реально копироваться будет мало данных. Я не большой спец по базам, и конкретную бд посоветовать не могу, но по идее такие решения есть — надо поискать.
Хорошо.
На самом деле этот пример — психологический. Он показывает, что если здравый смысл не применяется в более общем деле (в данном примере случайно так вышло что это Крым. Картинку вы даже не задумались другую поставить — т.е. это как бы норма), то в менее общих (в данном примере — электронная торговля) все тоже будет плохо. Потому, что сознание чиновника трансформируется определенным образом, и он уже перестает мыслить такими категориями, как право, здравый смысл и тд.
Может быть даже через год-два то чем вы недевольны сейчас — станет нормой для общества. И тут реально будут хвастаться, например, скриптами по отлову нарушителей в сфере электронной торговли.
Мне кажется, в итоге кто-то переработает алгоритм так, что вообще от перебора хэшей откажутся, или покрайней мере откажутся от адаптивного алгоритма, и переделают механизм работы так, чтобы большая мощность ноды означала большую пользу для всей сети, а не для конкретно этой ноды.
Например, количество вознаграждения могло бы зависеть от того, сколько транзакций ты хранишь и на какую сумму, с защитой от мусорных.
Кроме того, само подтверждение транзакций, как таковое — это абстракция уровня работы сети. В идеале надо стремится к тому, чтобы от подтверждений отказаться, ведь по сути в проведении транзакции заинтересованы только отправитель и получатель, а в доказательстве, что транзакция была — только получатель. Но считается оно всеми нодами. Это плохой момент, просто ничего лучше пока не придумали.
Получил результат в вертикальной — ну здорово, теперь иди разбираться чего оно не работало в горизонтальной, и что там было некорректно. Кроме того, был получен не просто результат, а конкретное число. Это гораздо лучше, потому что теперь можно оценить силу, которую якобы этот двиг развивает. А зная эту силу, можно оценить ожидаемое отклонение маятника.
И если отклонение мало — надо было замерить частоту собственных колебаний маятника и запускать/глушить с той же частотой движок, чтобы был резонанс. Тогда его система раскачивалась бы — и это было бы видно наглядно. Но вообще сдвинуть маятник с нижней точки- большой силы не надо, и должно было быть видно и так.
В вертикальной — можно просто электромагнит подвесить. Если пол железобетонный, то будет какая-то сила магнитного притяжения. (тут я подразумеваю, что автор умышленно не мухлюет)
И даже если не железобетонный — некоторое кол-во железа в нем может быть.
С ArrayList весь массив будет смещаться, если вставляем по индексу 0. С LinkedList мы пробегаем не более половины массива.
А если мы пробегаем не весь linkedList, а как максимум его половину — сложность точно будет O(n)? Может, O(n/2) или O(n)/2? Мы же пробегаем половину.
Вообще, вопрос был с подвохом. ИМХО, если он звучал именно так, как вы написали — вы вообще не по той ветке пошли. Надо было сказать, что вставка по индексу и вставка по итератору отличаются. Поэтому, для практического применения имеет смысл сравнивать не одинаковые подходы в использовании этих сущностей, а разные. Потому, что если будешь писать программу и встанет вопрос ArrayList или LinedList — то очевидно, что для LinedList будет предполагаться использование итераторов. А если использование итераторов невозможно изза специфики алгоритма — то и вопрос такой (у правильного программиста) не возникнет. Поэтому с практической точки зрения, логичней было бы сравнивать скорость вставки в ArrayList по индексу со скоростью вставки в LinkedList по итератору. Плюс рассказать про накладные расходы, в том плане что создаются LinkedList.Node
у меня в gedit оно вывелось как 2 символа рядом, но курсор за черточку от буквы й поставить не давало — т.е. сам gedit видел это как 1 символ.
Может он 300 раз фокусник, но все перечеркивает то, как смонтировано видео. Обычно такой подход — это свидетельство видеомонтажа. Внимание телезрителя увели, просто вырезав наиболее неугодные кадры.
У меня как-то был самодельный датчик уровня воды в баке рукомойника на базе геркона и поплавка с магнитом. Геркон был вне воды. Но влага вокруг понятно, что была постоянно. Проработало оно лет 5-8, потом геркон залип. Когда я его разобрал, то обнаружил, что внутрь попала вода, а стекло, из которого гекрон сделан, превратилось в труху — пальцами сдавливаешь оно превращается в песок.
Ну что сказать… внушаить :) Хотя, для тошибы это может быть даже прогресс.
Традиционный способ: insert работает с памятью, память в другом потоке пишется на диск.
Ваш способ: insert работает с памятью, но пишет бинлог на другой диск.
И там и тут insert работает с памятью. В первом случае это кэш, во втором это шаред. Все операции с диском в обеих случаях выполняются в другом потоке/процессе и не должны мешать друг другу. Т.е., я просто не вижу откуда может взяться такая производительность. Может быть небольшая разница, за счет разной имеплементации этих механизмов памяти. Если разница получилась значительной — это скорей всего значит, что там где вышло медленно — там скорей всего вы просто что-то недонастроили.
Что будет, если шаред память уйдет в своп?
Что будет, если размер базы вырастет и станет больше размера шаред памяти?
Запись на диск кэшируется. Т.е., запись на диск — это тоже работа с памятью. За счет чего так выходит, что работа с шаред памятью оказалась быстрее? В принципе, этот вопрос должен был быть рассмотрен в такой статье т.к. подходит по тематике.
плюс озвученные выше.
Если база помещается в памяти, то возможно, стоит посмотреть не в сторону mysql, а в сторону каких-нибудь других баз. В частности, существуют неплохие решения, которые хранят и оперируют с данными on-memory, а для записи на диск делают fork и в отдельном процессе пишут — желательно попеременно в два файла. Тут надо отметить, что в современных архитектурах/нормальных_ОС fork не копирует данные, а использует copy-on-write идиому, поэтому реально копироваться будет мало данных. Я не большой спец по базам, и конкретную бд посоветовать не могу, но по идее такие решения есть — надо поискать.
На самом деле этот пример — психологический. Он показывает, что если здравый смысл не применяется в более общем деле (в данном примере случайно так вышло что это Крым. Картинку вы даже не задумались другую поставить — т.е. это как бы норма), то в менее общих (в данном примере — электронная торговля) все тоже будет плохо. Потому, что сознание чиновника трансформируется определенным образом, и он уже перестает мыслить такими категориями, как право, здравый смысл и тд.
Может быть даже через год-два то чем вы недевольны сейчас — станет нормой для общества. И тут реально будут хвастаться, например, скриптами по отлову нарушителей в сфере электронной торговли.