Электроника БК 0010-01 vs ZX.

[NEO SPECTRUMAN]

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

а много мобильных устройств на арм в 94 году?
в 94-м в компах по 4 метра памяти
и засерать ее 32битными командами...

конечно за шину тоже правда
но не только же...

[NEO SPECTRUMAN]

по факту - медленней

он говорит про выборку сразу 16 бит
это как бы быстрей

- - - Добавлено - - -

Вы действительно думаете что кого-то всё еще волнует плотность кода? За какое время вы займёте своим кодом хотя бы мегабайт памяти?

ДЫК КАКОЙ ГОД НА ДВОРЕ?
мало того
попытайся понять что прочитать из памяти 16 бит
В 2 РАЗА БЫСТРЕЕ чем прочитать из памяти 32 бит
(при 16 бит шине конечно)
ну и то что в 16+ битных компах
обычно память хотят читать\писать не только один проц
но еще другие девайсы
которые будут стоять и ждать пока проц дочитает


...конечно потом придумали кеш и конвееры (ну или на худой конец префетч след инструкции) и...
и щас это давно не так актуально


но на форуме все застряли в развитии на 91(по мировым меркам на 85) году

[Lethargeek]

а много мобильных устройств на арм в 94 году?

после 1994 стало много, что намекает

в 94-м в компах по 4 метра памяти
и засерать ее 32битными командами...

б0льшая часть этих 4 мегабайт засиралась всё же данными, а не кодом + код можно было экономить вызовом процедур c небольшими накладными расходами
+ встречал анекдотические рассказы, что когда рантайм бибиси-бейсика умещался в кэш, бейсик-проги работали быстрее компилированного си

[blackmirror]

попытайся понять что прочитать из памяти 16 бит
В 2 РАЗА БЫСТРЕЕ чем прочитать из памяти 32 бит

Это даже при 16 битной шине быстрее только при условии что на шине нет пакетных передач, контроллеров когерентности и прочих гадостей. А у меня вот что читать 1 байт, что 2, 4,8,16,32 или 64, будет практически одинаково, если запросы идут по случайным адресам. Хотя шина 16 байт, но больше 16 запросов без ожидания ответа в неё не отправить и при задержке памяти более 64 тактов одно ядро шину загрузить не способно(случайным доступом). И хотя 64 байта идут пачкой в 4 такта, 16 таких запросов при задержке памяти в 64 такта в шину тоже укладывается, а потом мы дождёмся ответа и отправим 17й запрос, 18й и так далее.

[Lethargeek]

Это почему? За раз читается два байта вместо одного, как может быть по факту - медленней?

ну вот, значит, настолько медленно пишется/читается по два байта
здесь уже не раз сравнивали скорость работы графики zx и бк, когда выяснилось,
что у бк не только тяжелей экран, но и даже по абсолютной скорости на байт он сосёт

[NEO SPECTRUMAN]

И хотя 64 байта идут пачкой в 4 такта,

ну байты идут пачкой если есть кеш
ну или хотябы префетч инструкций

когда такого нет...

...хотя я не знаю какие были первые АРМ-ы
был ли у них префетч
и прочая гадость


может для них изначально ширина шины не так важна

и тогда тумба чисто для снижения плотности

б0льшая часть этих 4 мегабайт засиралась всё же данными, а не кодом + код можно было экономить вызовом процедур c небольшими накладными расходами

не забывай что у компа
есть ПЗУ
которое явно не 4 мегабайта (тогда)
но которое должно все вместить

ну и накопители по 1,4 мегабайта

...ну а раньше в биосы тулили еще и всякие бейсики
это щас у биоса(которого давно уже нет под таким названием) одна задача
загрузить быдловин15

[Lethargeek]

не забывай что у компа
есть ПЗУ

+ код можно было экономить вызовом процедур c небольшими накладными расходами

что как раз особенно пригодно для ПЗУ (+ хоть байткод для нетребовательных к скорости работы операций запиливай)

[blackmirror]

ну байты идут пачкой если есть кеш
ну или хотябы префетч инструкций

Кеш инструкций это самое первое что требуется, потому что без него половина всех обращений будет в память за кодом. А после того как он появляется, плотность кода уже не играет особой роли. Внутренняя разрядность кеша может быть хоть в 2, хоть в 4 раза больше шины. Большую часть времени программа всё равно проводит в небольших циклах и если они в кеш влезают, проблем с производительностью почти не будет. За исключением ситуации когда весь код это обёртка завернутая в обёртку, тогда кеш может не справиться. Вообще, если раньше было модно:

for(int i=0;i<N;++i) {
  double sum=0;
  for(int j=0;j<M;++j)
    sum+=A[i][j]*X[j];
  Y[i]+=sum;
}

Теперь матрицу транспонируют и делают:

for(int j=0;j<M;++j)
  double k=X[j];
  for(int i=0;i<N;++i)
    Y[i]+=A[j][i]*k;
}

Потому, лишнее последовательное обращение к памяти для векторного процессора фигня по сравнению с зависимостью по данным в первом варианте.

[NEO SPECTRUMAN]

фигня по сравнению с зависимостью по данным в первом варианте.

ну это щас
когда проц 300МГц как минимум

когда проц 3МГц без конвееров и прочей лабуды
быстрый код это развернутые циклы по 30К
которые не влезут в кеш

[blackmirror]

когда проц 3МГц без конвееров и прочей лабуды
быстрый код это развернутые циклы по 30К
которые не влезут в кеш

На этот случай есть DSP с отдельными шинами для кода, X-данных и Y-данных.