По какому принципу книги первой половины 20 века не попадают в список (просто слишком долго перечислять)?
Я бы, например для начала: 1. Определился с годом отсечки. 2. Взял распарсил (или даже рошёлся вручную) 2-3 сайта с фантастикой в вытащил оттуда все доступные книги. Например:
А - проверять остатки от деления на произведения первых n простых множителей. Но кроме х2 - она ведёт к неприятной иррегулярности, которая выливается во вложенный цикл и усложнение кода. К тому же эти остатки надо ещё сформировать. Либо руками (и тогда считать их не ошибаясь) либо автоматически (и тогда это фактически удваивает размер кода)
Это уже учтено в решении автора. Это уже в предлагаемом решении, о чём я прямо написал вот тут: > Учитывая, что список простых чисел у вас уже есть, причём в отсортированном виде (*).
Так что я не очень понимаю, что вы хотели сказать? *) исходя из этого вся разница сведётся к диффу:
< for divisor in range( 2, check_upper_bound + 1):
---
> for divisor in primes:
> if divisor > check_upper_bound:
> break
При проверке на простоту достаточно проверить не делимость только на простые числа. Учитывая, что список простых чисел у вас уже есть, причём в отсортированном виде - можно и нужно идти по нему.
1. Вам можно забить на согласованность (*) - просто кладёте эти данные в отдельный кэшик и забываете 2. Вам нельзя забивать на согласованность - данные иногда будут инвалидироваться => подолгу будут недоступны. Лучшее что вы можете сделать это повысить приоритет данных при вытеснении (такая возможность наверняка должна быть).
Честно говоря супер пространное описание. Смутно похоже на 1 из 3 вещей: - Tight Coupled Memory (программно управляемый кэш) - LL SC синхронизацию - watch points В целом неясно в чём смысл: оставить надолго некоторые данные в кэше или же "разбудить" ожидающий процесс? Если цель "разбудеть" - то обычно так не делают скрыто в аппаратуре, а посылают уснувшему процессу явный сигнал на уровне программной модели.
В общем случае в микроэлектронике - сложность сделать доступ к памяти быстрой. А в программном кэше сложность - вовремя инвалидировать устаревшие данные (т.к. данные мимо кэша идут в виде "запросов" по которым надо угадать что может инвалидироваться).
Вот вокруг этого: сложности инвалидации (а ещё и "когерентности", если она есть) - построена основная архитектура программных кэшей.
hardware растёт суб-линейно от техпроцесса (просто больше транзисторов => больше ядер на ту же площадь). архитектурно карточки почти не растут или уже не растут.
Если я правильно поинмаю - сейчас прунинг на аттеншне (но это всё-таки софт-часть) самая перспективная тема с т.з. "ускорить архитектуру".
А в чем же подвох на этот раз? А вот в чем: Деньги, которые ПА платит Израилю за воду, от Израиля же и получает!
Смотрите факты таковы (*): 1. Израиль экспроприирует воду у ЗБ (запрещает собирать дождевую воду). 2. Потом экспроприированную воду продаёт ПА (ЗБ и Газе). 3. По вашем утверждениям часть пункта (2) Израиль возвращает Палеслине в качестве "помощи".
Дайте ссылку, чтобы понятЬ: а) что Израиль вообще платит Палестине за воду. б) о какой части помощи с водой идёт речь - насколько мне известно платить за воду Палестине помогают как раз "персидские монархии".
-вот факты почему арабские фермеры в худшем положении чем еврейские вплоть до "не могут вести бизнес"
-Ваш ответ выглядит как пропаганда, (т.к. вы не привели историческую справку почему Израиль их дискриминирует).
========================================= Лично от меня вопрос: когда вы требуете "историческую справку". Факты неудобные для Израиля (см ниже) должны в неё попадать?
> Согласно Human Rights Watch Конфискация Израилем воды нарушает Гаагские правила 1907 года, которые запрещают оккупирующей державе экспроприировать ресурсы оккупированной территории в своих интересах.
Я думал что такого мифа на самом деле нет. Но вы меня переубедили - первый комментарий подтверждает, что миф есть.
латентность разведённой памяти не сильно ниже DDR (и гораздо больше зависит от стратегии в контроллере памяти, чем от физической схемы). Пропускная способность может быть выше, но приведённые примеры намного больше упираются в латентность (и prefetch / eviction кэшей).
1. Ваше решение - 155к (в 12 раз хуже) 2. То же с mmap - 79к (в 6 раз хуже) 3. Mmap + массив счётчиков + full unroll внутреннего цикла - 58к (в 4.5 раза хуже) // решение с многопоточностью - предсказуемо ничего не даёт (1CPU в условии).
Надо заметить, что на моём 7800x3d (c AVX2) - последнее решение почти догнало asm-код.
Я подозреваю, что там какие-то артефакты измерений и лучшие решения это абузят (например(не обязательно это) меряют system-time + user-time -- тогда абузом будет: и prefetrch + nanosleep, т.к. nanosleep не попадёт в user/system time и по-сути подкачку данных из памяти в кэш мы не подсчитаем)
Но мой опыт объяснений "что" - говорит, что без разъяснения аритектуры компиляторов хотя бы совсем-совсем по-верхам (плюс поверхностного объяснения некоторых моментов - типа неразрешимости задачи алиасов указателей в общем случае) не приносит пользы. Т.е. не даёт метода понять "что же произойдёт"
Рад буду, если ошибаюсь в данном случае. Работа большая и явно потребовавшая много времени.
По какому принципу книги первой половины 20 века не попадают в список (просто слишком долго перечислять)?
Я бы, например для начала:
1. Определился с годом отсечки.
2. Взял распарсил (или даже рошёлся вручную) 2-3 сайта с фантастикой в вытащил оттуда все доступные книги.
Например:
А - проверять остатки от деления на произведения первых n простых множителей.
Но кроме х2 - она ведёт к неприятной иррегулярности, которая выливается во вложенный цикл и усложнение кода.
К тому же эти остатки надо ещё сформировать. Либо руками (и тогда считать их не ошибаясь) либо автоматически (и тогда это фактически удваивает размер кода)
2k => 2k +1
6k => 6k + {1, 5}
30k => 30k + {1, 7, 11, 13, 17, 19, 23, 29}
Мы заведомо проверяем только делимость на заведомо простые, причём меньшеие, чем sqrt(candidate))
Какую ещё оптимизацию вы предлагаете?
Это уже учтено в решении автора.
Это уже в предлагаемом решении, о чём я прямо написал вот тут:
> Учитывая, что список простых чисел у вас уже есть, причём в отсортированном виде (*).
Так что я не очень понимаю, что вы хотели сказать?
*) исходя из этого вся разница сведётся к диффу:
Да согласен.
решение в целом же неверное (ну вы же даблы не всерьёз используете, да?).
primes_count(x) = log(x) - это формула примерная и на неё полагаться нельзя.
Правильным будет то, что ниже.
*) Ну и примитивное "решето Эратосфена" же всё равно быстрее, если можете позволить себе память.
При проверке на простоту достаточно проверить не делимость только на простые числа.
Учитывая, что список простых чисел у вас уже есть, причём в отсортированном виде - можно и нужно идти по нему.
Понял. Ну из общих соображений:
1. Вам можно забить на согласованность (*) - просто кладёте эти данные в отдельный кэшик и забываете
2. Вам нельзя забивать на согласованность - данные иногда будут инвалидироваться => подолгу будут недоступны. Лучшее что вы можете сделать это повысить приоритет данных при вытеснении (такая возможность наверняка должна быть).
*) В терминах CAP-теоремы
Честно говоря супер пространное описание.
Смутно похоже на 1 из 3 вещей:
- Tight Coupled Memory (программно управляемый кэш)
- LL SC синхронизацию
- watch points
В целом неясно в чём смысл: оставить надолго некоторые данные в кэше или же "разбудить" ожидающий процесс? Если цель "разбудеть" - то обычно так не делают скрыто в аппаратуре, а посылают уснувшему процессу явный сигнал на уровне программной модели.
В общем случае в микроэлектронике - сложность сделать доступ к памяти быстрой. А в программном кэше сложность - вовремя инвалидировать устаревшие данные (т.к. данные мимо кэша идут в виде "запросов" по которым надо угадать что может инвалидироваться).
Вот вокруг этого: сложности инвалидации (а ещё и "когерентности", если она есть) - построена основная архитектура программных кэшей.
Поскольку кэш работает на уровне кэшлайнов, а не страниц, то "фриз кэш страниицы" - звучит как какая-то ерунда.
Вам наверное на уровне идеи лучше объяснить какое поведение вы подразумеваете.
О какой "заморозке" в процессорных кэшах идёт речь?
И да программный кэш очень сильно отличается от процессорного по внутренней архитектуре и основным сложностям.
Спасибо.
А Metta у меня стоит. Меня вполне устраивает. Сейчас ищу супруге поменять.
Она из соображений дизайна хочет metta, а из соображений "убирать под стол" с откидными ручками.
Если мне нужно кресло, с убирающимися под стол ручками (стол низкий, т.к. с выдвижной полкой под столешницей) - что мне смотреть?
На вашем сайте совершенно непонятно.
hardware растёт суб-линейно от техпроцесса (просто больше транзисторов => больше ядер на ту же площадь).
архитектурно карточки почти не растут или уже не растут.
Если я правильно поинмаю - сейчас прунинг на аттеншне (но это всё-таки софт-часть) самая перспективная тема с т.з. "ускорить архитектуру".
https://www.europarl.europa.eu/meetdocs/2009_2014/documents/dplc/dv/dplc20091110amnesty_/dplc20091110amnesty_en.pdf
Ну вот - Израильская армия уничтожает нифраструктуру для сбора воды (причём таких отчётов и англоязычном интернете навалом).
Вообще наш диалог для меня всё более странно выглядит.
Смотрите факты таковы (*):
1. Израиль экспроприирует воду у ЗБ (запрещает собирать дождевую воду).
2. Потом экспроприированную воду продаёт ПА (ЗБ и Газе).
3. По вашем утверждениям часть пункта (2) Израиль возвращает Палеслине в качестве "помощи".
Дайте ссылку, чтобы понятЬ:
а) что Израиль вообще платит Палестине за воду.
б) о какой части помощи с водой идёт речь - насколько мне известно платить за воду Палестине помогают как раз "персидские монархии".
*) https://en.wikipedia.org/wiki/Water_supply_and_sanitation_in_the_State_of_Palestine
"Согласно Human Rights Watch Конфискация Израилем воды нарушает Гаагские правила 1907 года, которые запрещают оккупирующей державе экспроприировать ресурсы оккупированной территории в своих интересах."
-вот факты почему арабские фермеры в худшем положении чем еврейские вплоть до "не могут вести бизнес"
-Ваш ответ выглядит как пропаганда, (т.к. вы не привели историческую справку почему Израиль их дискриминирует).
=========================================
Лично от меня вопрос: когда вы требуете "историческую справку". Факты неудобные для Израиля (см ниже) должны в неё попадать?
> Согласно Human Rights Watch Конфискация Израилем воды нарушает Гаагские правила 1907 года, которые запрещают оккупирующей державе экспроприировать ресурсы оккупированной территории в своих интересах.
Я думал что такого мифа на самом деле нет.
Но вы меня переубедили - первый комментарий подтверждает, что миф есть.
латентность разведённой памяти не сильно ниже DDR (и гораздо больше зависит от стратегии в контроллере памяти, чем от физической схемы).
Пропускная способность может быть выше, но приведённые примеры намного больше упираются в латентность (и prefetch / eviction кэшей).
Там с подсчётом довольно странная ситуация.
Лучшее решение - 13к "попугаев".
1. Ваше решение - 155к (в 12 раз хуже)
2. То же с mmap - 79к (в 6 раз хуже)
3. Mmap + массив счётчиков + full unroll внутреннего цикла - 58к (в 4.5 раза хуже)
// решение с многопоточностью - предсказуемо ничего не даёт (1CPU в условии).
Надо заметить, что на моём 7800x3d (c AVX2) - последнее решение почти догнало asm-код.
Я подозреваю, что там какие-то артефакты измерений и лучшие решения это абузят (например(не обязательно это) меряют system-time + user-time -- тогда абузом будет: и prefetrch + nanosleep, т.к. nanosleep не попадёт в user/system time и по-сути подкачку данных из памяти в кэш мы не подсчитаем)
> (1) что, (2) почему, (3) как.
Но мой опыт объяснений "что" - говорит, что без разъяснения аритектуры компиляторов хотя бы совсем-совсем по-верхам (плюс поверхностного объяснения некоторых моментов - типа неразрешимости задачи алиасов указателей в общем случае) не приносит пользы.
Т.е. не даёт метода понять "что же произойдёт"
Рад буду, если ошибаюсь в данном случае.
Работа большая и явно потребовавшая много времени.