Непонятно наличие null в списке слов. Если они читаются с текстового файла то там такого кейса никогда не будет. Вообще если масштабировать эту задачу в Spark/Hadoop то там совсем другие оптимизации будут. Кодовые страницы там. Если работаем с русским языком то возможно имеет смысл построить гистограмму стартовых букв и посмотреть на нее. В русском языке есть характерная форма распределения. И на ней тоже можно сыграть. Как в кодах Шеннона.
Light-crusader, движок комьютерной игры будет отрабатывать сенсорные области для мышко-клика на твоей статичной или динамичной картинке совершенно одинаковым образом.
Возможно у тебя другая техническая проблема которую ты сам для себя не смог сформулировать?
Поскольку множество простых чисел - бесконечно то и твоя задача как-бы не имеет логического финала. Сколько-бы ты не придумывал слагаемых, все равно я могу указать некое следующее число которое будет не укладываться в твой числовой ряд.
Поэтому задание тут еще сложнее чем непозиционная система.
Да. Еще более важно - классифицировать систему на OLTP/хранилище. И понять нужно ли для пользователя консистентность по событию либо ему достаточно eventual consistency.
Я как-то делал рендеринг трехмерной картинки с шарами в параллелизме на разных языках (С++/Java) и у меня выходил максимальнй перформанс на 5 вычислительных потоках хотя это был Intel Core i3 с 2 ядрами по 2 потока. Тоесть 4 штуки. И такой эффект был на разных языках разработки.
К чему это я. Очень сложно будет вам провести ОБОСНОВАНИЕ правоты вашего метода.
Хорошо. Я просто добавлю несколько своих сомнений.
1) Если твои тестовые измерительные потоки будут вести интеракцию с памятью через кеши L1/L2 (а они будут это делать если ты работаешь с памятью) то с ростом количества потоков производительность будет падать. Потоки будут конкурировать за кеши. Я не помню точно но есть уточненние к закону Амдала в части когерентности. И эта когерентность резко (иногда катастрофически) понижает перформанс при росте потоков. Тоесть очень малая часть приложений скейлятся от запуска дополнительных потоков.
2) Современные процессоры будут сопротивляться твоим измерительным атакам. Если это процессоры эконом-класса то они будут держать тактовую частоту на пониженном режиме. У них есть условие при котором эконом режим выключается и тактовая подскакивает до паспортных величин. Это тонкий маркетинг. Когда процессор продавали - указали максималку. Но в реальности ты можешь это не использовать. И этот эффект прыжка частоты надо учитывать. Особенно на ноутбуках. И такой-же тёмный мрак - это мобильные процессоры. Всякие Cortex и прочие. Они могут экономить батарею и там режим вообще другой.
3) Перед тем как эспериментировать посмотри на утилиту CPUZ. Просто понаблюдай какие сведенья она показывает. До того как начнёшь кодить.
4) Почитай базовые различия в Intel/AMD в разных статьях по сравнению. Есть мнение (уже не моё) что в понятие Kernel/Thread они вкладывают разный смысл.
Меня всегда интересовал vision of next step. После того как вы узнали что у вас на борту 8/16/32 threads,
что будет дальше? Какую вы будете делать логику? Или какие алгоритмы вы собираетесь реализовать на основе этой информации? Я думаю что я подкину вам несколько сюрпризов и вы пересмотрите первую идею.
Лубунту нацелена на легаси железо. Кому это надо - я не понимаю. Есть кейс когда у ваших дедушек-бабушек стоит на столе старый Pentium-II (32 бит) со старым типом памяти и его просто жалко выкинуть. Вот это наш вариант.
Смотри. Типичное бизнес-приложение всегда имеет лимит мастабирования. Эта тема корнями уходит в закон Амдала. Грубо говоря что-бы ты не проектировал - всегда будет какое-то бутылочное горло. Например 1 база данных которая не успевает отбивать транзакции или 1 сетевой канал который скушал 100 гигабит и дальше не растет потому что оптический канал по атлантике ты ухе забил выше крыши своим приложеним. Поэтому без NLB просто прикинь что у тебя вообще мастабируется. Может тебе вообще нет смысла маштабировать?
Скорее программирование - это перевод с языка бизнеса на язык посредник (который ближе к машине Java/C++/C#) который в свою очередь будет переведен в промежуточный код JVM/MSIL/LLVM который в свою очередь будет переведен в целевой ассемблер для x_86 и который - опционально в машинный и микрокод.
Тоесть программист в этой цепочке - какой то технический переводчик.
Нет конечно можно поговорить о творческих задачах и о создании архитектур. Но на 99% работа разработчика для бизнеса - это рутина. Перекладывание чисел из одного места в другое.
Иван, в работе любого админа есть рутинные действия. Если вы админ на предприятии. То вы заводите пользователей домена. Как вы будете это делать. Вручную или автоматизировать? Админ - сотрудничает с сектором разработки. Значит нужны какие-то типовые действия по сбору логов и анализу ошибок на серверах. Админ конфигурит и разворачивает новые виртуалки или докеры под приложения. Тоже типовое действие.
Админ - это не сферический конь в вакууме. И у него есть рабочий план действия на день. Хороший админ - настроит всё и автоматизирует и потом спокойно спит или "шпилится в контру". Имеет право - ибо у него все в порядке.
А плохой админ - стучит по клавишам круглые сутки.
Существуют задачи реверс-инжинеринга софта и де-обфускации. Это промышленный подход. И сейчас практикуется при копировании железа и софта. Но то что прозвучало в топике - не имеет отношения к этим задачам. Это чёрт-знает-что. Безсмысленная и безпощадная задача.
Если у тебя есть сорца - то замени private на protected/public и не сношай детям мозги. А если детей надо натаскать на ассемблер - так пускай учат ассеблер. При чем тут С++ я не понимаю. Честное слово Старик Бьярне плачет крокодиловыми слезами если читает топик.
