Частично — да, в ближайшей перспективе очевидным решением были бы теплицы. По сравнению, скажем, с Антарктидой у Марса (по крайней мере близ экватора) есть очевидное преимущество: отсутствие полярной ночи и ничтожные конвективные потери тепла. Поэтому нужные условия создать относительно просто, а удобрения можно делать на основе отходов жизнедеятельности, по-максимуму закрыв цикл оборота ненативных для Марса химических соединений.
В плане затрат топлива лететь обычным самолётом ещё дешевле. Меня смущает то, что это какая-то неочевидная ниша — не очень быстро и не очень дёшево. То есть где-то между «дорого и быстро» (BFR) и «дёшево и медленно» (обычный самолёт). Причём стоимость билета у них вряд ли будет заметно ниже (а то и выше), чем у BFR. Поэтому лично мне перспективы неясны. Ниша BFR, с другой стороны, хотя бы понятна.
Угу, он каждый год заявляет, что вот, мол, через полтора-два года уже всё будет. И каждый раз, если я ничего важного не пропустил, всё откладывается ещё на полтора-два года. Хотя конструктивно его планы гораздо проще BFR — можно использовать готовый самолёт-носитель, готовые аэродромы, целиком полагаться на земную атмосферу и аэродинамику.
Но тем не менее, в плане грузоподъёмности и скорости перелёта это даже не близко к BFR, потому что самолёт-носитель очень жестко ограничивает и то, и другое.
Для этого вайфай ещё нужен. А всё вместе это будет жрать батарейку так же быстро, как и в типичном смартфоне, что сведёт все преимущества маломощной платформы на нет. С Nokia E52 была та же история.
Не только эфир. Видеокарточные майнеры, оптимизируя производительность на ватт, обычно до предела разгоняют память, снижая при этом частоту графического процессора или power limit. Так выгоднее всего.
Когда при исполнении многопоточной задачи (или нескольких задач) ядро утилизируется не до конца, нужен гипертрединг. Соответственно, когда в однопоточной задаче не задействуются другие ядра (обычная ситуация), то нужен «обратный гипертрединг». Основная и критичная проблема с ним в том, что нужно как-то решить вопрос последовательности одногопоточного вычисления в пределах одного такта, или по крайней мере снизить требуемое число тактов хоть в какой-либо мере за счёт этого принципа. Возможно, для этого потребуются несколько раздельных тактовых генераторов. В общем, я не знаю, решаем ли этот вопрос технологически, до допускаю, что это теоретически возможно при условии подходящей архитектуры, и что тот, кто его решит, получит возможность, как Интел последние шесть лет, долго время сидеть на жопе ровно и считать барыш.
Оно и есть утопично, если по-чесноку. Если и возможно, то нужна какая-то очень хитрая архитектура, которой ещё не придумали.
Частоту можно задрать, если упростить набор инструкций (грубо говоря, перейти на ARM и ему подобное), но не факт, что в долгосрочной перспективе это выигрышнее, поскольку рост частоты увеличивает производительность более-менее линейно, а нежелательные побочные эффекты — экспоненциально. Хотя если софт будет параллелиться дальше, то, возможно, сложные инструкции будут не так актуальны. Но это так — размышления вслух.
Подъём частоты напрямую связан с тепловыделением (и при этом нелинейно, т. е. рост частоты на четверть может увеличить тепловыделение вдвое), а чем тоньше техпроцесс, тем меньше объём, в котором сконцентрировано тепло, т. к. становится больше активных элементов на единицу пространства. Там ещё куча нерешённых проблем, которые требуют кардинальных решений, и я почти уверен, что на нынешнем этапе развития прогресса большинство из них решать нерентабельно (если не невозможно). Не исключаю, что «обратный гипертрединг» (гипотрединг?) в итоге появится раньше и избавит от этой необходимости. Если такое произойдёт, то будет куда проще и дальше наращивать ядра вместо частоты. Вы же наверняка заметили, что это энергоэффективнее.
Но тем не менее, в плане грузоподъёмности и скорости перелёта это даже не близко к BFR, потому что самолёт-носитель очень жестко ограничивает и то, и другое.
Частоту можно задрать, если упростить набор инструкций (грубо говоря, перейти на ARM и ему подобное), но не факт, что в долгосрочной перспективе это выигрышнее, поскольку рост частоты увеличивает производительность более-менее линейно, а нежелательные побочные эффекты — экспоненциально. Хотя если софт будет параллелиться дальше, то, возможно, сложные инструкции будут не так актуальны. Но это так — размышления вслух.