Всё-таки гипотеза Таниямы-Симуры не была построена вокруг теоремы Ферма. Лишь лет через 15 Герхард Фрай доказал, что теорема Ферма следует из этой гипотезы. А Уайлс уже доказывал эту гипотезу.
Я читал тот топик про 3-SAT, но не исследовал. Однако уверен, что алгоритм верный. Ошибку надо искать в области представления данных. Я уверен, что все 3-SAT задачи, которые можно закодировать представленным образом, решаются как положено. Однако должен быть целый пласт непредставимых входных данных.
Меня всегда удивляла экономия на офисном железе. Для программиста стоимость системного блока и мониторов обычно не превышает месячной зарплаты. А служит это железо года 3.
И да, я не считаю топовый компьютер 2009 года устаревшим.
Ну 150 проедет по городу, а то и 200. А маленькая машинка на баке по городу — ну 300…
На работу и обратно — обычно менее 100 км. А ночью заряжать.
Вот что с холодом не знаю.
А цена — это беда, но временная. Если мы экономим 1.5 рубля на километр, то за пятилетний цикл при средних 20000 в год — 150000 руб экономии… Но 5 лет — срок службы аккумуляторов, потом замена (предположительно, дорогая). Значит при продаже мы теряем.
Как коммерческий автомобиль тоже не очень выйдет, пробег маловат, зарядка долгая…
А вывод получается следующий: использование distcc примерно в два раза уменьшает время сборки, а в паре с ccache скорость увеличивается примерно в четыре раза
Какой кошмарный вывод из сумбурного текста.
Сразу надо выкинуть время линковки из ваших замеров, distcc/ccache влияют только на компиляцию препроцессированных исходников. Дальше я говорю только про компиляцию, забудьте про линковку.
tmpfs бесполезен, выигрыша не даст, обычный дисковый кеш работает отлично, сразу забудьте tmpfs.
ccache кеширует препроцессированные исходники с учётом пути. Он очень полезен при компиляции одного продукта несколько раз с разными опциями.
При работе нескольких разработчиков на одной машине (но кеш должен быть всем доступен, что слегка небезопасно) полезен только при таком написании makefile, в котором используются только относительные пути.
Очень полезен в большом проекте с плохо прописанными зависимостями, можно сделать make clean && make objs. Ещё хорошо, когда вы выгружаете 5-6 слабо отличающихся веток в разных директории и всё собираете. Разница легко может быть в сотни раз.
С distcc тоже всё просто: если проект способен собираться в десятки потоков — ускорение будет в десятки раз. Я использовал ccache/distcc на ферме из 100 ядер, ускорение было в 500 раз, по сравнению с одной двухъядерной машиной.
В 500 раз — это за счёт того, что двухъядерная машина была другой архитектуры, а на ферме использовались обычные быстрые intel + cross compiler. Подготовить gcc только для кросс-компиляции без препроцессирования и линковки намного проще.
Там меньше 20 км, за 25 минут на подобной машинке доедет любой нормальный водитель. Я недавно по дороге худшего качества забирался к обсерватории недавно, ничего особенного.
Да, разумеется, 10 (рекорды), 17 минут, 20 минут и 25 — это гигантская разница.
30 часов на тестовое задание — это запредельно. Я даю мелкую задачку и хочу получить ответ через 2-3 часа. Это всяко быстрее, чем собеседование + дорога, да и при беседе есть о чём поговорить.
Все её фотографии (сделанные китом, полтинником, чем угодно) оказались лучше моих.
Видимо, придётся купить ещё пару Lек, уж тогда-то я точно победю.
Я читал тот топик про 3-SAT, но не исследовал. Однако уверен, что алгоритм верный. Ошибку надо искать в области представления данных. Я уверен, что все 3-SAT задачи, которые можно закодировать представленным образом, решаются как положено. Однако должен быть целый пласт непредставимых входных данных.
И да, я не считаю топовый компьютер 2009 года устаревшим.
На работу и обратно — обычно менее 100 км. А ночью заряжать.
Вот что с холодом не знаю.
А цена — это беда, но временная. Если мы экономим 1.5 рубля на километр, то за пятилетний цикл при средних 20000 в год — 150000 руб экономии… Но 5 лет — срок службы аккумуляторов, потом замена (предположительно, дорогая). Значит при продаже мы теряем.
Как коммерческий автомобиль тоже не очень выйдет, пробег маловат, зарядка долгая…
Но всё будет хорошо :)
Какой кошмарный вывод из сумбурного текста.
Сразу надо выкинуть время линковки из ваших замеров, distcc/ccache влияют только на компиляцию препроцессированных исходников. Дальше я говорю только про компиляцию, забудьте про линковку.
tmpfs бесполезен, выигрыша не даст, обычный дисковый кеш работает отлично, сразу забудьте tmpfs.
ccache кеширует препроцессированные исходники с учётом пути. Он очень полезен при компиляции одного продукта несколько раз с разными опциями.
При работе нескольких разработчиков на одной машине (но кеш должен быть всем доступен, что слегка небезопасно) полезен только при таком написании makefile, в котором используются только относительные пути.
Очень полезен в большом проекте с плохо прописанными зависимостями, можно сделать make clean && make objs. Ещё хорошо, когда вы выгружаете 5-6 слабо отличающихся веток в разных директории и всё собираете. Разница легко может быть в сотни раз.
С distcc тоже всё просто: если проект способен собираться в десятки потоков — ускорение будет в десятки раз. Я использовал ccache/distcc на ферме из 100 ядер, ускорение было в 500 раз, по сравнению с одной двухъядерной машиной.
В 500 раз — это за счёт того, что двухъядерная машина была другой архитектуры, а на ферме использовались обычные быстрые intel + cross compiler. Подготовить gcc только для кросс-компиляции без препроцессирования и линковки намного проще.
А вот финиш той «страшной» трассы: goo.gl/ejP7s
Да, разумеется, 10 (рекорды), 17 минут, 20 минут и 25 — это гигантская разница.
Хотя мне всё равно понравилось :)