Хорошо. Я просто добавлю несколько своих сомнений.
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 и не сношай детям мозги. А если детей надо натаскать на ассемблер - так пускай учат ассеблер. При чем тут С++ я не понимаю. Честное слово Старик Бьярне плачет крокодиловыми слезами если читает топик.
Adamos, все очень просто. На самом деле нет плохого и хорошего кода. Я говорю с позиции ентерпрайза. Я уже там более 15 лет. Я не просто так писал про количество.
Коллективный код - это просто джентльменское соглашение между группой разработчиков что дескыть "мы будем писать именно так". Ты поймешь это когда будешь изучать чужой код и чужого кода будет очнеь много. И там тебя будет раздражать каждый пробел и каждая запятая. Стиль кодирования - это не пустой звук. Он реально существует. И по этому стилю написаны сотни рекомендательных документов. И каждая проектная группа. Беря язык разработки - создает свои правила. 90% эти правила будут просто копи-пастой стандартных документов больших корпораций. Плюс какие-то мелкие свои соглашения. Типа мы переносим фигурную скобку всегда на новую строку или оставляем справа. С++ ники переносят. Java-исты сейчас кодят в Egyptian-Style.
Я думаю что настоящие TruЪ геймеры положат болт на стриминг. Дело в том что ping на другую сторону планеты (НьюЙорк к примеру) ходит 120 милисекунд. Это - зазор недопустимый для геймера. Ему играть будет уже некомфортно. Тоесть даже если будет решен вопрос с мегабитами или гигабитами - никто не решит вопрос с лагом. Это физика мать ее. Реальный мир.
Я охотно верю что в экспо-центрах и на презентациях стриминг красиво смотриться но в массовость его я не верю т.к. это игры богатых. Золотого миллиарда. Вообще в мире не хватает электроэнергии. Это кстати один инженер посчитал. Что мы никогда по планете Земля не построим 100Гб. Наша экономика просто не потянет столько электричества для конечного пользователя.
В мире последние лет 15 игровые технологии в браузер заходили рывками. Итеративно. Сначала Jscript, потом Macromedia Flash. Потом WebGL/Unity. И каждый следующий рывок - более мощний и тяжкий для комьютера юзера. Вспомните. Когда вы приходите в торговый центр покупать себе ноутбук - вы больше всего обращаете внимание как он открывает современные сайты.
Сегодня уже браузер - это самое жрущее ресурсы приложение. И хотя на него нет строго единого стандарта (по сути 4 большие корпорации пилят 4 браузера независимо друг от друга) но какой-то глобальный тренд на веб-игровую платформу есть. Эдакий себе противовес Steam-у с его инсталляциями и покупкой лицензий.
Догонит или нет - вопрос больше запоздалый. Скорее цена вопроса сегодня - КОГДА.
Когда пользователь зайдет на сайт. Наберет ссылку и просто будет играть. Как инженер - я не вижу никаких ограничений. Это возможно. Есть просто взгляды на безопаснсоть (майнинг крипты на вашем железе и вирусы). И я думаю что в будущем будет специальная игровая ОС наподобие XBox где не будет ничего кроме браузера. Рай для геймера.
Амазон вполне может лагать. Смотрите какой тип инстанции EC2 куплен. Они разные. У Амазона также есть свои регламенты техобслуживания. Смотрите Cloud Watch logs.
Виктор П., ты описал то как работает транслятор и как получается на выходе AST. Это все существовало еще в эпоху когда ООП не было. Было обычное функциональное и процедурное программирование.
1) Если твои тестовые измерительные потоки будут вести интеракцию с памятью через кеши L1/L2 (а они будут это делать если ты работаешь с памятью) то с ростом количества потоков производительность будет падать. Потоки будут конкурировать за кеши. Я не помню точно но есть уточненние к закону Амдала в части когерентности. И эта когерентность резко (иногда катастрофически) понижает перформанс при росте потоков. Тоесть очень малая часть приложений скейлятся от запуска дополнительных потоков.
2) Современные процессоры будут сопротивляться твоим измерительным атакам. Если это процессоры эконом-класса то они будут держать тактовую частоту на пониженном режиме. У них есть условие при котором эконом режим выключается и тактовая подскакивает до паспортных величин. Это тонкий маркетинг. Когда процессор продавали - указали максималку. Но в реальности ты можешь это не использовать. И этот эффект прыжка частоты надо учитывать. Особенно на ноутбуках. И такой-же тёмный мрак - это мобильные процессоры. Всякие Cortex и прочие. Они могут экономить батарею и там режим вообще другой.
3) Перед тем как эспериментировать посмотри на утилиту CPUZ. Просто понаблюдай какие сведенья она показывает. До того как начнёшь кодить.
4) Почитай базовые различия в Intel/AMD в разных статьях по сравнению. Есть мнение (уже не моё) что в понятие Kernel/Thread они вкладывают разный смысл.