Ответ: PHP и с чем его едят....
А. С. Соловья на Вас нету, тов. GrAndSE. Откуда Вы знаете, что именно именно Вам понадобится завтра? Мне, допустим, приятно знать, что я смогу запрограммировать электрочайник на процессоре Z80 в случае необходимости
. Вы бы еще сказали, что знание того, что есть O(N), а что есть O(N^2) в алгоритмировании никому не надо, ибо появились уже кор2дуи и гигабайтозуи. Именно после таких "умных людей" и приходиться ломать голову, почему одна система выдерживает с успехом 10 тысяч посетителей в минуту, а другая, с такой же функциональностью, еле-еле выносит 300.
Грустно это все...
P.S.
Все знания нужны для того, чтобы писать
качественный код, а не качественный флуд.
Немного успел познакомиться с А. С. Соловьём. Хотял бы более длительного знакомства, но к сожалению так уже вышло.
Извените пожалуйста, я не говорю о знаниях алгоритмов и понимании того, как этот код выполняется вообще. Но если же говорить об оптимизации кода на том же php, то она весьма отличается от оптимизации кода для С++.
Последняя кстати гораздо ближе к устройствам. Оптимизация кода php требует больше знаний именно интерпретатора, ну и также во многих случаях умения писать sql. Если в С++ очень сильно может ускорить работу (в несколько раз) переход от вещественных чисел там где это не нужно к целым, а потом ещё заменить все операции умножения на 2 на операцию смещения и т.д. и т.п. Таких вот деталей, которые необходимо знать, умение выбирать оптимальный алгоритм - очень хорошо. А большинство из вышеперечисленного для C/C++ считается не просто "плюшкой", а скорее даже призаком хорошего тона.
А вот даст ли это тот же самый прирост производительности в php? Поскольку типов как таковых в php нет, то не думаю. Хотя например работа со строками: правильно выбраные кавычки многое меняют в лучшую сторону. (правда на core 2 duo в случае, когда делается один раз вывод и к этому файлу обращаются один раз в день, то нагрузку на сервер это особо не изменит, хотя если есть 1000 таких вот выводов, и к каждому из них обращаются каждую минуту... вот и часть потеряных 9700
)) посещений) Опять же строки но уже в Java: String и StringBuffer - скорость работы ну очень сильно отличается: первый вариант плетётся, а второй практически догоняет реализацию string из STL по тестам.
Касательно политики наращивания производительности устройств - интерестно, а почему я до сих пор сижу на машине, которая сейчас "современному человеку" кажется смешной и тормознутой? Отчего занимаюсь таким вот "мазохизмом", как написние всего в vim (мазохизм такой правда приятненький) или Far - если так подумать, то сейчас модно .NET и Visual Studio 2008 - чего я не побёг туда, несясь в припрыжку? Можете даже написать, какой я дибил.
Может это всё и флуд, и код я пишу некачественный, но как раз я где в общих чертах, а где довольно глубоко знаю многое из того, чтобы знать полезно... Но. Например, знание того, что память ограничена, не научит писать код, в котором бы не использовались лишние переменные - я вон могу по невнимательности лишнюю переменную создать, а потом думать зачем же она мне. Но это по невнимательности, а сколько такого по глупости бывает. И причем не только у меня - если бы только у меня, то никто бы не занимался "заплаточным" программированием, которое является стандартным способом залатывания дыр в продукции широко известной Microsoft. Я думаю, что и Вы Алфим, не на каждом шагу думаете только о производительности и тем более том, как это всё работает на апаратном и низко-программном уровнях. Всегда вступают в силу критерии: "нужно успеть", "нужно чтобы понятно было", "нужно, чтобы потом изменить что-то или добавить без проблем". А это всё уже проектирование. Которому ни то что в универах не учат, но и в большинстве авторитетных и очень известных книгможет не уделяться достаточно внимания.