Нужно ли знать архитектуру машины для написания кода?

правильно для большинства обстоятельств

Среда выполнения / язык / компилятор будет абстрагировать эти данные, если вы не имеете дело с размерами слов или двоичными данными на низком уровне.

Даже байтеор абстрагируется сетевым стеком в ядре. Он переведен для вас. При программировании сокетов в C вам иногда приходится иметь дело с порядком байтов для сети при отправке данных … но это не касается 32 или 64-битных разностей.

При работе с блоками двоичных данных отображение их из одной архитектуры в другую (например, наложение на C-структуру) может вызвать проблемы, о которых говорили другие, но именно поэтому мы разрабатываем независимые от архитектуры протоколы на основе символов и т. Д.

Фактически такие вещи, как Java, запускаются на виртуальной машине, которая абстрагирует машину на другом шаге!

Знание немного о наборе команд архитектуры и том, как скомпилирован синтаксис, может помочь вам понять платформу и написать более чистый, более жесткий код. Я знаю, что я скривился в каком-то старом коде C после изучения компиляторов!

Зная, как все работает, будь то работа виртуальной машины, как она работает на вашей платформе или как некоторые конструкции C ++ преобразуются в сборку, вы всегда будете лучше программировать, потому что вы поймете, почему все должно быть сделано так, как они находятся.

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

Для пакетной работы вам необходимо понять, как данные хранятся на платформах и как отправка по сети на другую платформу может изменить способ чтения данных (endian-ness).

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

Короче говоря, нет. Вам не нужно знать материал низкого уровня, но он никогда не боится знать .

Вы иногда должны беспокоиться.

Вы можете быть удивлены, когда эти детали низкого уровня внезапно выпрыгнут и укусят вас. Например, Java стандартизован double 64 бит. Однако JVM для Linux использует режим «расширенной точности», когда double равен 80 бит, если он находится в регистре CPU. Это означает, что следующий код может выйти из строя:

 double x = fun1(); double y = x; System.out.println(fun2(x)); assert( y == x ); 

Просто потому, что y вытесняется из регистра в память и усекается от 80 до 64 бит.

В последний раз, когда я смотрел спецификацию языка Java, в нем содержалась нелепая ошибка в разделе о целочисленном боксе.

 Integer a = 100; Integer b = 100; System.out.println(a == b); 

Это гарантировано для печати.

 Integer a = 300; Integer b = 300; System.out.println(a == b); 

Это не гарантируется печать true . Это зависит от времени выполнения. Спектр оставил его полностью открытым. Это связано с тем, что бокс int между -128 и 127 возвращает «интернированные» объекты (аналогично тому, как строковые литералы интернированы), но разработчику среды выполнения языка рекомендуется повышать этот предел, если они того пожелают.

Я лично считаю это безумным решением, и я надеюсь, что они исправили его с тех пор (пишите один раз, бегите куда угодно?)

В Java и Python детали архитектуры абстрагируются, так что на самом деле более или менее невозможно писать код, зависящий от архитектуры.

С C ++ это совсем другое дело – вы можете писать код, который не зависит от деталей архитектуры, но вы должны быть осторожны, чтобы избежать ошибок, особенно в отношении основных типов данных, которые зависят от архитектуры, например int .

Пока вы делаете все правильно, вам почти не нужно знать большинство языков. Во многих случаях вам никогда не нужно знать, поскольку поведение на языке не меняется (например, Java указывает точное поведение во время выполнения).

В C ++ и C правильные действия включают в себя не допущение предположений о int. Не ставьте указатели в int, и когда вы делаете что-либо с размерами или адресами памяти, используйте size_t и ptrdiff_t. Не рассчитывайте на размер типов данных: int должен быть не менее 16 бит, почти всегда 32 и может быть 64 на некоторых архитектурах. Не предполагайте, что арифметика с плавающей запятой будет выполняться точно так же на разных машинах (стандарты IEEE имеют некоторую свободу действий в них).

Практически все операционные системы, поддерживающие сетевое взаимодействие, дадут вам возможность справиться с возможными проблемами с контентом. Используй их. Используйте языковые средства, такие как isalpha (), чтобы классифицировать символы, а не арифметические операции над символами (что может быть чем-то странным, как EBCDIC). (Конечно, теперь более привычно использовать wchar_t как тип символа и использовать Unicode внутри.)

Если вы программируете на Python или в Java, интерпретатор и виртуальная машина соответственно абстрагируют этот слой архитектуры. Тогда вам не нужно беспокоиться, работает ли она на 32 или 64-битной архитектуре.

То же самое нельзя сказать о C ++, в котором вам придется иногда спрашивать себя, если вы работаете на 32 или 64-битной машине

Вам нужно будет заботиться о «endian-ness», только если вы отправляете и получаете необработанные C-структуры по проводу, как

 ret = send (socket, & myStruct, sizeof (myStruct));

Однако это не рекомендуется.

Рекомендуется, чтобы вы определяли протокол между сторонами, так что это не имеет значения для архитектур машин сторон.

В C ++ вы должны быть очень осторожны, если хотите написать код, который работает равномерно на 32 или 64 бита. Многие ошибочно полагают, что int может хранить указатель, например.

С java и .net вам действительно не нужно беспокоиться об этом, если вы не делаете очень низкоуровневые вещи, например, биты. Если вы используете c, c ++, fortran, вы можете пройти, но я бы рекомендовал использовать такие вещи, как «stdint.h», где вы используете определенные объявления, такие как uint64_t и uint32_t, чтобы быть явным. Кроме того, вам нужно будет создавать с особенностями библиотеки в зависимости от того, как вы связываете, например, 64-битная система может использовать gcc в режиме компиляции по умолчанию 64 бит.

32-битная машина позволит вам иметь не более 4 ГБ адресной виртуальной памяти. (На практике это даже меньше, чем обычно, 2 ГБ или 3 ГБ в зависимости от ОС и различных вариантов компоновщика.) На 64-битной машине у вас может быть ОГРОМНОЕ виртуальное адресное пространство (в любом практическом смысле, ограниченное только диском ) и довольно проклятая большая оперативная память.

Итак, если вы ожидаете, что наборы данных на 6 Гбайт для некоторых вычислений (скажем, что-то, что требует некогерентного доступа и не может быть потоковым потоком), на 64-битной архитектуре вы можете просто прочитать ее в ОЗУ и сделать свой материал, тогда как на 32-битной архитектуре вам необходим принципиально другой подход к ней, поскольку у вас просто нет возможности сохранить весь резидентный набор данных.