Меня такие мысли посещают часто, оттого и занимаюсь подобной ерундой. В электронике разбираюсь слабо, впечатление такое, что специалисты в этой области просто чудеса творят. Отсюда уверенность в том, что практически любую абстрактную модель можно легко запечатлеть в железе. Если любую, то почему бы не выбрать наиболее простую и ненадуманную? Я полагал, что всё сводится к вопросу совместимости или там юридическим нюансам, но никак не технологическим. Возможно, мои представления несколько преувеличены.
Кластер подразумевает плотное взаимодействие между устройствами, неужели прям-таки «губительные»?
Возможно, я как дилетант недооцениваю сложностей. Приведённые ниже рассуждения тоже слабо обоснованы?
Рад, что Вы меня понимаете. Действительно, я испытываю некоторый дискомфорт, глядя на описанного Вами «монстра». Но дело здесь не в тщетном желании объять необъятное, а в информационной избыточности, вызванной в основном проблемами совместимости. Ничего до конца не продумывается, потом эти недоделки с прилегающими способами их устранения расширяются в геометрической прогрессии, отсюда — «франкенштейн».
Какой толк от такого прогресса, если интереснейшая работа превращается в рутину? Всё нужно делать быстро, пока не опередили конкуренты — сплошное толчение воды в ступе. Не у всех, конечно, так, но я думаю, что как правило, судя по результатам.
Поэтому осваивать новый функционал просто не хватает терпения — мысли сразу перескакивают на то, как бы я там всё переделал. Вот и занимаюсь изобретением «велосипедов».
Я понимаю причины, по которым предложенный мною подход может показаться неприемлемым. Обычно мы отталкиваемся от задачи (в общем виде обозначим её, как «задачи, стоящие перед современными ИТ»), и подбираем под неё адекватное решение (способов которого современные ИТ предлагают великое множество). А тут получается наоборот — в качестве исходной посылки предлагается ограничение, взятое исключительно из эстетических соображений, под которое вроде бы как должна подстроиться вся компьютерная индустрия. Надеюсь, что последний тезис вы не воспринимаете всерьёз и понимаете, что я не предлагаю здесь выходить за рамки мысленного эксперимента.
Результат которого по сути видится мне примерно таким. Берём буфер, выполняющий роль кэша, обеспечивающего быстрый обмен данными между процессором(-ами) и устройствами (из соображений соответствия 16-разрядной архитектуре принимаем его размер равным 65536 * 65536 * 16 бит = 8 Гбайт). Реализация возможности обновления памяти за 1 такт путём оптовой пересылки мегабита кода/данных, я полагаю, у современных ИТ не вызовет особых затруднений — скорости света, вроде бы хватает (кстати, довольно впритык, если полагать расстояние между процессором и кэш-памятью на превышающим 10 см при тактовой частоте 1 Ггц). Вот, собственно, и весь способ устранения ограничения на объём памяти. В остальном (касательно реализации самого интерфейса) имеем бесконечное и неопределимое множество способов, как это можно сделать.
Да, придётся вводить дополнительные параметры, как минимум 4 штуки: номер блока памяти в кэше [0...65535], начальный адрес [0...65535], длину [0...65535], и смещение [0...65535] — это чтобы пересылать данные из любого места кэша в любое место ОЗУ процессора и обратно. Но это можно делать один раз за «пробег» текущего фрагмента кода, а не по любому поводу. В конце концов, простота в устройстве может значительно облегчить реализацию параллельных вычислений путём организации многопроцессорных систем.
Вообще я не сторонник перекладывания функционала на «плечи» процессора, даже аппаратного умножения на признаю. Может, ностальгия по детству сказывается, но скорее меня здесь смущает расхождение с представлением о низкоуровневом программировании: выполнение любой команды я должен представлять себе визуально, иначе абстракции получаются оторванными от физики, а такие пробелы в представлениях на базовом уровне нежелательны. Конечно, это условность — всю программу в голове не прокрутишь, и тем не менее я думаю, что этим не стоит пренебрегать ради выжимания тактов.
Хорошо, давайте попытаемся подойти к этому вопросу с другой стороны. Допустим (гипотетически), что Вам предлагают решить эту задачу, предоставив соответствующий проект, призванный решить основные проблемы, вызванные столь радикальным сокращением объёма адресуемой памяти (полагаю, что ограничение по объёму командного пространства становится в таком случае несущественным). Во всём остальном Вы ничем не ограничены (кроме, естественно, законов физики и возможностей современных технологий). У Вас есть время, необходимое на разработку концептуальной информационной модели, по истечении которого Вы предоставляете свой проект, и если это решение окажется адекватным современным требованиям, то становитесь миллиардером. Ну и вопрос, соответственно, в том, насколько велика степени Вашей уверенности в том, что это дело безнадёжно и даже не стоит тратить на него своё время?
Да, я понимаю, что будущее, по всей видимости, за квантовыми технологиями. И кому-то будет интересно всё это создавать. У меня пока мозгов не хватает содержательно об этом думать. Поэтому думаю о том, на что хватает.
2 ^ 0 = 1
2 ^ 1 = 2
2 ^ 2 = 4 ( = n )
2 ^ 4 = 16 ( = R )
2 ^ 16 = 65536 ( = A = C )
Первые два случая приведены для проформы — типа начинаем с нуля и идём дальше. По третьему пункту я приводил пример, но вы сочли его неубедительным. Признаю, что вы оказались правы. Действительно, если пренебречь эстетическими соображениями (не остаётся неиспользуемых битов), то мне нечего сказать в обоснование необходимости соблюдения этого условия. Главное, на чём я делаю акцент, так это то, что 16 бит задают оптимальный объём командного пространства для реализации языка низкого уровня в его классическом представлении. И если бы удалось подогнать под них всё остальное (в том числе и объём адресуемой памяти), то программировать на таком асемблере было бы одно удовольствие.
О том, что 4 — это 2 в целой степени, а 5 и 6 таковыми не являются. А 2 — это система счисления, принятая в сфере ИТ. Если вы не видите в этом смысла, то очевидно, что вам не приходилось задумываться в предложенном мной направлении. Если бы вы потратили достаточное количество времени на подобные размышления, то уверяю вас — таких вопросов бы не возникло. Один из примеров, где это свойство может оказаться полезным, я привёл. Пример не самый убедительный, но там если копать дальше, то можно найти случаи и поинтереснее.
Откуда такие ассоциации? Слишком строго сужу лучшие достижения человечества? Да нет, в общем-то впечатляет — столько светлых голов думало над тем, как заставить это всё заработать. Просто жаба давит — столько ресурсов расходуется впустую. В то время как 16-ти бит вполне хватает. Проверить это в этой жизни у меня вряд ли будет возможность, так — субъективная уверенность, куда от неё денешься. Ну и логика немало ей способствует.
Да, в современные технологии я даже и не пытаюсь глубоко вникать (мне достаточно одной фразы — «64-разрядный процессор», чтобы потерять к ним интерес). Поэтому могу допускать неточности в суждениях.
Возможно, я как дилетант недооцениваю сложностей. Приведённые ниже рассуждения тоже слабо обоснованы?
Какой толк от такого прогресса, если интереснейшая работа превращается в рутину? Всё нужно делать быстро, пока не опередили конкуренты — сплошное толчение воды в ступе. Не у всех, конечно, так, но я думаю, что как правило, судя по результатам.
Поэтому осваивать новый функционал просто не хватает терпения — мысли сразу перескакивают на то, как бы я там всё переделал. Вот и занимаюсь изобретением «велосипедов».
Результат которого по сути видится мне примерно таким. Берём буфер, выполняющий роль кэша, обеспечивающего быстрый обмен данными между процессором(-ами) и устройствами (из соображений соответствия 16-разрядной архитектуре принимаем его размер равным 65536 * 65536 * 16 бит = 8 Гбайт). Реализация возможности обновления памяти за 1 такт путём оптовой пересылки мегабита кода/данных, я полагаю, у современных ИТ не вызовет особых затруднений — скорости света, вроде бы хватает (кстати, довольно впритык, если полагать расстояние между процессором и кэш-памятью на превышающим 10 см при тактовой частоте 1 Ггц). Вот, собственно, и весь способ устранения ограничения на объём памяти. В остальном (касательно реализации самого интерфейса) имеем бесконечное и неопределимое множество способов, как это можно сделать.
Да, придётся вводить дополнительные параметры, как минимум 4 штуки: номер блока памяти в кэше [0...65535], начальный адрес [0...65535], длину [0...65535], и смещение [0...65535] — это чтобы пересылать данные из любого места кэша в любое место ОЗУ процессора и обратно. Но это можно делать один раз за «пробег» текущего фрагмента кода, а не по любому поводу. В конце концов, простота в устройстве может значительно облегчить реализацию параллельных вычислений путём организации многопроцессорных систем.
Вообще я не сторонник перекладывания функционала на «плечи» процессора, даже аппаратного умножения на признаю. Может, ностальгия по детству сказывается, но скорее меня здесь смущает расхождение с представлением о низкоуровневом программировании: выполнение любой команды я должен представлять себе визуально, иначе абстракции получаются оторванными от физики, а такие пробелы в представлениях на базовом уровне нежелательны. Конечно, это условность — всю программу в голове не прокрутишь, и тем не менее я думаю, что этим не стоит пренебрегать ради выжимания тактов.
2 ^ 1 = 2
2 ^ 2 = 4 ( = n )
2 ^ 4 = 16 ( = R )
2 ^ 16 = 65536 ( = A = C )
Первые два случая приведены для проформы — типа начинаем с нуля и идём дальше. По третьему пункту я приводил пример, но вы сочли его неубедительным. Признаю, что вы оказались правы. Действительно, если пренебречь эстетическими соображениями (не остаётся неиспользуемых битов), то мне нечего сказать в обоснование необходимости соблюдения этого условия. Главное, на чём я делаю акцент, так это то, что 16 бит задают оптимальный объём командного пространства для реализации языка низкого уровня в его классическом представлении. И если бы удалось подогнать под них всё остальное (в том числе и объём адресуемой памяти), то программировать на таком асемблере было бы одно удовольствие.
/* что-то не получилось добавить ответ в вашу ветку */