Сейчас пишу программу. И столкнулся с этим:
Это весьма забавно, если ещё учесть тот факт, что все работает так как надо!
То есть программа работает, но ей что-то в этой жизни не нравится, вот только что, она сама пока еще не знает... Машины потихоньку превращаются в людей!
P.S. С ошибкой разобрался, но ситуация прикольная!
Собственно, сабж. Ищу советов и дельных комментариев к ситуации.
Итак.
Некоторое время назад решил сменить сферу деятельности и перейти в IT, благо, небольшой багаж был. В процессе просмотра вакансий и разъездов по интервью выяснил, кто непосредственно позиций для джунов нигде нет. Под джуновским уровнем я понимаю учебник Прата + Программирование Под Win95 + Программирование на С++ для профессионалов + всякие базы вроде алгоритмов и с.д. Везде требуется дополнительный стек, и часто уникальный (от подразделов буста, до всячески рестов и т.д.)
Что в таком случае делать? Есть ли стратегия прокачки?
И вообще - актуально ли сейчас искать по c++? Или лучше уж переходить на java?
Спасибо.
Внимание: Видео на английском языке, но изъяснения вполне понятны и ясны.
Начинаем с простых правил и заканчиваем более сложными моментами.
Представьте, что вы делаете ручную работу, сидя за просторным деревянным столом. Инструменты и материалы разложены по полкам в шкафу в 3-х метрах от вас. Если всякий раз выкладывать ту или иную вещь из рук на полку и брать с полки, большая часть времени уйдет на хождение от стула к шкафу и обратно. Умный человек довольно скоро додумается разместить активно используемые инструменты прямо на столе, чтоб они были под рукой.
Вернемся к компьютеру. В компьютере, по грубой аналогии, роль стола играет процессор, роль шкафа - оперативная память, а жесткий диск, который нас, впрочем, не интересует, представляет большой склад в отдаленном помещении. Нас интересуют регистры - это такая штука в процессоре, которая в нашем случае играет роль места "под рукой" для размещения активно используемых вещей, в т.ч. и тех, что обрабатываются в текущий момент. Не буду вдаваться в подробности, какое особое назначение у RAX, RBX, RCX, RDX, RSI, RDI.. Скажу лишь, что они всегда используются, в худшем случае (тупой компилятор) только для счетчика комманд, указателя стека и прочих технически важных вещей, а также для передачи некоторых аргументов функции, возвращаемого значения функции и для переменных, над которыми идет операция в текущий момент, после чего каждый раз производится перезапись в память. На языке высокого уровня этого не видно, видны лишь имена переменных, а реальный (машинный) код создается компилятором. Assembly же, где соотношение того, что вы пишете, и того, что получится - один к одному, отпускает полный контроль под ваши руки.
Перейдем к делу. Возьмем простенький итерационный алгоритм нахождения n-го числа Фибоначчи.
Если запустить цикл while на несколько миллирадов итераций, такое количество обращений к памяти (f,f1,f2) займет немало времени. Можно написать функцию fibo(n) на ASM.
Но подобная экзотика не всем по вкусу. К счастью, такая прекрасная вещь, как C/++, позволяет во многих случаях обходиться и без Assembly. Можно "попросить" компилятор держать, по возможности, те или иные переменные по возможности держал в регистрах. Делается это очень просто: перед объявлением переменной пишется ключевое слово register.
Но надо еще все протестировать. Запустим это дело на 4 миллиарда. С такими входными данными, разумеется, ни о каком корректном результате речи не идет, но главное, чтоб не вылетало (благо не Java, под 64 бита срежет и промолчит) и чтоб обе memslow и regfast дали одинаковый результат, этого более чем достаточно для честной проверки быстродействия.
Скриншот говорит сам за себя. 5-кратная разница в результате. А вот разница в причине такого результата.
Выделена та часть, где вводятся f, f1, f2.
Первое - медленный вариант, последнее - быстрый. Обратите внимание, что в последнем случае за весь цикл (все что между jmp и jne) - ни разу не обращаемся к памяти.
Ассемблерную часть изложенной инфы не обязательно всем понимать, достаточно было узнать про register-фичу языка C. Не вижу смысла расписывать ASM, кто шарит тот шарит, а кто не шарит, но хочет, тому могу посоветовать хорошую книжку PC Assembly Language чувака по имени Paul A. Carter (ссылку оставлю в комментах).
Сомневаюсь, что будут плюсы, поскольку не занимаюсь регулярно постами на какую-либо тематику, и вообще сам учусь, но чувствую необходимость где-то это зафиксировать, чтоб хоть сокурснику в удобном виде (ссылка Pikabu) кинуть. Грубо говоря, воспользовался сайтом в качестве удобного средства оформления информации с такими ништяками, как картинки и хранение в сети. Да простят меня за это.
Гавнокод мой - тег моё.
интересуюсь плюсами довольно давно... вообщем преамбулу отбросим,
нашёл баг еще в начале года в VS2017 (15.6.х) компилере (пофиксили буквально неделю назад в обнове 15.7.1)
баг в том что если есть например родительский класс с парой мемберов(неважно сколько и каких) и конструктором принимающим допустим 2 аргумента, то если с дочернего класса из constructor member initializer попытаться вызвать этот конструктор юниформно и не с 2мя аргументами а например с тремя, то есть derived() : base{1,2,3}{} то студийный компилер это спокойно хавал (в отличии от gcc и clang, и даже родного IntelliSense,который это место считал ошибочным), и на выходе получалось что базовый класс не проинициализирован а в дочернем всё ок. но это ладно, пофиксили и хорошо, просто
тут еще одна фантазия возникла:
#pragma pack(1)
struct _jGate
{
// due to initializers, added implicit ctor and called on creation
const unsigned char j_code = 0xEE;
unsigned int j_address;
const unsigned short int j_segment = 0x0033;
};
#pragma pack()
...
jGate stub{ 1}; // sets j_code member to 1, which is initially const.! Clang & gcc does same
// stub.j_code = 0xee; // error C3892: 'stub': you cannot assign to a variable that is const
тут вот вопрос, а вообще логично ли инициализировать константный мембер если у него уже в определении структуры есть инициализатор? (это я вообще юниформной инициализаций заморочился)
(пс код и комменты писать по русски не могу - глаза режет)
Всем привет. Я хочу поделиться с вами библиотекой структур данных для языка C. Интерфейс библиотеки напоминает интерфейс стандартной библиотеки C++. Буду рад любому фитбэку.
Ссылка на публичный репозиторий: https://github.com/maksimandrianov/cdcontainers
Ниже на картинке представлен аналог vector из C++.
Писать отдельный пост не вижу смысла так как на хабре инфу хорошо разжевали, считаю информацию достаточно важной чтобы иметь возможность "набрать материал и переучиться, а сделать это придется каким бы профи вы не были" [это заявление одного из членов собрания по стандартизации языка в Джексонвиле]
Source: https://m.habrahabr.ru/post/352570/
return 0;
}
Мы постарались сделать каждый город, с которого начинается еженедельный заед в нашей новой игре, по-настоящему уникальным. Оценить можно на странице совместной игры Torero и Пикабу.
Реклама АО «Кордиант», ИНН 7601001509
1) Вместо использования цикла for() быстрее использовать цикл while(). По той простой причине, что while() был придуман раньше, чем for(), то следовательно while() более низкоуровневый, а следовательно за абстрагирование мы расплачиваемся меньше, что ускоряет наш код.
2) если честно, то данной код можно ускорить ещё больше. поскольку оператор ++ является неоптимальным, лучше использовать его аналог =.
Так делали ещё наши деды на Паскале и Фортране, получая код, который просто летал. Я вам больше скажу, при программировании процессоров, работавших на советских космических станциях использовали именно этот оператор. И ведь где, а там нужно высокая эффективность кода.
3) Если вам нужно сделать вечный цикл, например как при поиски в ширину, лучше писать while(!false) вместо обычного while(true). поскольку процессор быстрее воспринимает команды с нулями, то и отрицание нуля он будет обрабатывать быстрее, нежели просто единицу. Это сильно ускоряет ваш проход по циклу.
4) Описание типа данных для каждой отдельной переменной отдельно также уменьшает затраты процессорного времени. Поскольку вы перекладываете часть работы процессора на себя. Как бы расписывая всё для каждой переменной в отдельности, тем самым "разжёвывая" код, процессору приходиться декодировать значительно меньше данных.
5) Ну и последний совет по оптимизации заключается в том, чтобы сократить потребление оперативной памяти при исполнении программы. ОБЯЗАТЕЛЬНО удаляйте все лишние пробелы, табуляции, переходы на новые строки и комментарии. Именно они зачастую являются причиной потребления большей части оперативки и кеша процессора. Вы сами можете увидеть, как код стал более компактным и более читабельным. Если ваш код будет читать другой программист, то на его экранном пространстве также он будет занимать меньше места, соответственно полезного кода будет помещаться больше.
