Котик Антон

У вас намешан php код и html.

<?php while ($row = mysql_fetch_assoc($result)): ?>
    <h1><?= $row['title'] ?></h1>
    <p><?= $row['text'] ?><p>
    <p>Дата публикации: <?= $row['date'] ?></p><p><?= $row['time'] ?></p>
    <p>Автор: <?= $row['author'] ?>
<?php endwhile ?>

я сам знаю то что ошибка в чем

В золотой фонд.

Нужно просто меньше есть.
Хорошо помогает безуглеводная диета - поначалу из-за недостатка углеводов начинаешь плохо соображать, но потом организм к этому адаптируется, получая необходимую энергию от расщепления жиров

Я извиняюсь, но вчера один персонаж 3 раза задавал разные вопросы по рекурсии с правками кода функции nums_from. 1) Отправлю жалобу на задание, не обижайтесь. 2) Передайте вашему преподавателю что он дебил. Рекурсия - инструмент специфический. Если задача коротко и прозрачно решается итеративно - решать ее рекурсией будет только имбецил. Задачи решают рекурсией, если итеративно код выглядит как ночной кошмар (обход деревьев, xml, ханойская башня).

BOM придуман для явного указания того, что в данном файле содержится текст в кодировке UTF-8. BOM - это простой байтовый маркер в начале любого файла. При его скачивании браузер принимает этот маркер и понимает, что нужно использовать выбранную кодировку. Кроме этого, сам веб-сервер на этапе интерпретации файла может распознать BOM и отправить заголовок с соответствующим charset (кодировкой).
Если BOM не указан, то все зависит от конфигурации веб-сервера и браузера. Если на сервере не настроен DefaultCharset, то данные отдаются без указания charset и распознавание кодировки полностью ложится на плечи браузера. Поэтому он пытается сканировать документ на наличие мета-тега с кодировкой и, если его нет, использует кодировку по умолчанию. Кодировка по умолчанию зависит от браузера, его настроек и операционной системы. Это ответ на вопрос - почему в разных браузерах файл может выглядеть по-разному.

Чтобы избежать подобных проблем нужно на первоначальном этапе создания проекта определиться с кодировкой по умолчанию и использовать ее повсюду. На настоящий момент стандартом де-факто является UTF-8. Используйте ее. Далее следует настроить ваш веб-сервер, чтобы он по умолчанию отдавал utf-8.
Если такая возможность отсутствует, всегда есть возможность указать мета-тег
<meta charset="UTF-8">
В идеале ваше php приложение должно отдавать корректный тип контента и кодировку в виде заголовка.
И напоследок - использовать IDE, которая может правильно работать с файлами в различных кодировках. Например PHPStorm.

я начинал вот с этого

у php одна из лучших документаций. переведенный на русский язык мануал.

https://www.atlassian.com/agile - RTFM ;)

Отвечать на этот вопрос без какой-либо дополнительной информации - это как гадать на кофейной гуще. Какой CPU - если это древний Pentium D с допотопным конвейером и глупыми регистрами - одно дело, а если это новейший Core i7 на Haswell - другое. Что до настроек - вот честно, "стандартные" вообще ни о чём не говорит. Я уже не говорю, что было бы не плохо указать количество опытов с максимальным и минимальным - вполне возможно глупые ОС с планировщиком как-то неудачно распределяют время. Любой ответ, который можно тут указать может быть техническим грамотным, но совершенно не соответствующий истине.

Рискну предположить такой расклад - об оптимизациях мы почти ничего не знаем и делаем "стандартную" дебаговую сборку. В этих случаях транслятор вставляет в код специальные метки, по которым можно будет сопоставить инструкции с файлом и номером строки. Понятное дело, что в объектные файлы попадут и холостые циклы и бесполезные разыменования. Ни о каких кэшированиях или перестановках не может быть и речи - что попросили, то получили.

Теперь давайте вместе подумаем о том, какие различия между x86-64 и x86. На самом деле, вопрос поставлен не очень корректно - x86-64 почти полностью включает в себя x86. Из изменённого - размер указателя (адреса), да немного переделана логика регистров (хотя все они на месте, просто добавилось ещё лишние несколько десятков) - теперь часть аргументов в функцию передаётся через дополнительные регистры, тогда как в x86 все идут через стек. Однако получить здесь преимущество не так уж и просто - процессор тоже не дурак, в случае линейной обработки информации (или любая длительная работа с небольшими участками памяти) он прекрасно всё кэширует и работа со стеком в общем случае не сильно медленнее работы с регистрами.

Теперь смотрим на код. Что там? Куча адресной арифметики, немного функций, да и аргументов почти нет. 8 миллионов слов? Не думаю что рекурсия вынудит вылезти стеку за пределы кэша, так что есть подозрение о паритете архитектур в данном случае. Однако большое количество адресной арифметики и увеличенный размер адреса в битах... во сколько раз? В два раза?

Ну да ладно, ясное дело, сложение реализовано за 1 такт. Скорее всего. Конечно, здесь вопрос процессора, но даже узнав модель будет сложно узнать наверняка, разве только синтетическим тестом (много раз обращаться по адресу - сумме двух случайных чисел). Да и Windows 8.1 никогда не был стандартом производительности (скорее с точностью наоборот), и VC++ никогда не был лучшим компилятором.

Попробуйте gcc (меня разве только интересует откуда на Windows взялся gcc) с флагом -O3. И посмотрите машинный код для 64 бита и 32 бита (можно пользоваться objdump из binutils или посмотреть машинный код в IDE Visual Studio - точно расположение кнопки не помню, но можно поискать в менюшках). Скорее всего причина не одна, их множество. Так, вызов функции сопровождается сохранением контекста, тогда как в x64 регистров больше, больше и контекст. Собираем такие моменты по крупицам... Вот и получаем.

P.S. Давным давно, разговаривал с преподавателем. Простая перекомпиляция под 64 бита ускорила код на 30%. Это был колхозный кодек, немного похожий на libx264 (от туда была сдёрнута часть кода). Естественно, проект собирался со всеми оптимизациями, со всем расширениями инструкций - со всем, чем можно. И сборка под платформу x86-64 (с SSE, MMX, FMA и прочие). Жутко наукоёмкий разношёрстный код (писали все - от зелёных аспирантов, до ровесников Страуструпа и профессоров университета) - туева хуча функций, структур, объединений и очень, очень много параметров, многие из которых передают в аргументы функций. Ну и целевая платформа - жутко порезанный и переделанный Windows Embedded - там просто не чего было планировать.

Начало конструирования. Разбитие приложения на пакеты.Пакеты на классы.Классы на методы.

Методы еще на строки забыли разбить.

если не ошибаюсь каждый col-lg-, col-md- — "float: left", а row как раз чистит.

Под капотом Битрикс.
Шаблон сверстан, придерживаясь правил BEM.

Я уточню на всякий случай: а вы знаете что такое PHP и HTML?
Может быть, вам стоит передать этот вопрос на решение тем, кто разбирается в этих буковках?

<?=$displayType;?>

сперва были вопросы "как стать программистом"
затем вопросы "что читать"
теперь уже "как читать"
может скоро будет "как учить алфавит, а то за меня родители пишут на тостере".

Для книг - читайте простейшие туториалы и сразу практика. Сложные книги - потом, когда в голове уже будет база.

Добавлю еще момент:
Почитайте статью megamozg.ru/post/10126
Там очень понятно указано, что профессиональный навык и боль программиста - гиперконцентрация, которая необходима, чтобы освоить понятия и вещи для профессиональной работы. 40 минут это как-то несерьезно.

Верстал с JPG, ворда, экселя, акшура, корела, с разрешения 300dpi, и даже со слов. Просто нужно сесть, открыть редактор и начать верстать!

не в тему, но насторожитесь ─ есть вероятность что дизайнера кинули.