blacklion79

Проблема (для меня) в том, что f/2.8 FF я точно не потяну. Но на Sony есть f/4 (как и на зеркальный кэнон, про никон не помню), а на Пентакс — нет.

Spomatic? :) Или я чего-то не понял.

Ну вот разве что люди с полной коллекцией лимов. Неширокая ниша, прямо скажем.

ХУже любительской фотографии только любительское видео, а профи таких вопросов обычо не задают, они и так рынок знают.
И, да, вот интересно, кто все эти люди, кому так важно видео в фотоаппарате и что они делали 10-15 лет назад, ходили таки с двумя девайсами?
Я понимаю, что это энекдтоал эфиденс, но у меня трое друзей-фотографов (от кого я и нахватался по верхам, хотя уровня ни одного из них даже близко не достиг) — им видео не нужно. Более того, все мои родственники и знакомые показывают фотографии из отпусков теперь бОльшей частью на телефон, конечно, но суть-то не в этом) — никто не снимает и не монтирует любительское видео.
Я понимаю — герои ютьюба, свадебщики, корпоративщики, начинающие кинематографисты — но сколько и, 0.01% от всех тех, кто фотографирует хоть как-то?
Зачем это видео вообще нужно в каждом девайсе?

Сам давний пользователь Pentax (K10D-K7-K5), но смотрю на фуллфрейм и не понимаю. Оптики чуть, стоит дорого… Если я таки захочу фуллфрейм — это будет скорее сонька беззеркальная. Лучше бы замену K-3 II выпустили уже, K-5 разваливается, а купить на замену нечего :(
Это — не замена, половину оптики менять…

Интересно, почему под обзорами ВИДЕОкамер нет вопросов какое разрешение у фото и снимает ли фото в RAW — а под каждым обзором ФОТОкамер начинается разговор про видео?
Отстаньте от фотокамер уже

А что вы делаете, что вам нужен антивирус? У меня Win'10 с момента выхода, Defender включён, но не срабатывал ни разу вообще.
Вроде даже на порносайты я иногда хожу, но нет, ни разу не было что бы антивирус возбудился (простите за каламбур).
Где нынче вирусы-то берут?

L4 вообще-то в каждом модеме Квалком. Если это не широкий круг — то я не знаю, что такое широкий.

1. Ну вот зачем вы сравниваете нишевые ускорители с процессорами для персоналок и рабочих станций? Вас опять заносит в крайности. Если бы мы обсуждали машины и я бы сказал, что BMW M3 делается от скорости и динамики а Audi A6 от комфорта — вы бы в ответ сказали, что перформанс это Ferrari FXX, а комфорт — это Mercedes S600 и никак иначе. Ну давайте сюда ещё Теслу притащим (ту, что nVidia, а не ту, что машины) за уши. В любом случае когда начинается проектирование есть список приоритетов. У Intel в их Core-линейке до последнего времени СУДЯ ПО РЕЗУЛЬТАТУ на первом месте была полная совместимость со всеми предыдущими поколениями (на чём оно и выезжает), а на втором — performance. У ARM на первом, понятно, совместимость, а на втором — энергоэффективность. Повторюсь, это по внешним наблюдениям.
Итаниум был и оставался жутким тормозом с ужасной энергоэффективностью. Потому что говнокод так и остался говнокодом и потенциал VLIW не смогли реализовать в софте. О чём я пишу в самом последнем пункте.
2. По сути возражения будут?
3. Про говнокод — смотри про VLIW. В вакууме вы правы, а на деле — оказалось что не умеем мы скрывать latency памяти в сотни циклов вручную, на каждом обращении к памяти. Матрицы так умножать ещё можно, а как только у вас ветвления — приплыли, не выходит. Очень ограниченное подмножество задач можно решать, делая конвеер вручную.
Вам нужно уйма простых ядер in order? Возьмите. Например Tile64. Если у вас такие специфические задачи и такой специфический код — вот для вас решение. Я его щупал, в рамках своих ограничений и выбранных авторами компромиссов, оно прекрасно работает. Молотит тщательно вылизанный код аж завидно.

1. Ну потому что Intel до последнего времени первично оптимизировал на high performance а вторично — на эффективность. ARM идёт прямо противоположно, навстречу, от low power к high performance. И я подозреваю, что встретятся они в одной точке плюс-минус проценты. Потому что физику обмануть сложно.
2. Есть такое правило эмперическое — 80/20. 80% пользователей используют 20% всех возможностей техники (софта, etc). Одна засада — эти 20% у каждого пользователя свои. У вас несколько строк текста и у меня несколько строк текста и у свадебного фотографа несколько строк текста, только у всех эти строки не совпадают полностью. Собираем такие строки текста с миллиона специалистов и получаем несколько страниц уникального текста. Времена, когда отдельно был специализированный word processor а отдельно была станция нелинейного монтажа — прошли, все работают на одном и том же универсальном железе.
3. Нет, никакой иронии. Любой компромисс — в чём-то костыль. Любой супер-специализированный инструмент эффективнее мультитула. Но иногда мультитул удобнее по сумме свойств, хотя он и хуже спец-отвёртки и спец-плоскогубцев и хорошего ножа. Персональные компьютеры пошли именно этим путём, это по сути продолжение предыдущего пункта.
4. Я назвал CPU общего назначения CPU предназначенные для персональных компьютеров и подобной им техники, что бы отделить от DSP, микроконтроллеров, чипов для рассчёта биткоина и сотен других специализированных устройств, которые тоже можно считать микропроцессорами. На мой взгляд, признаки таких устройств — развитая защита памяти со страничной организацией, 64-х битный размер основных регистров (несколько лет назад я бы ещё написал «32 или 64»), возможность адресации относительно больших объёмов (сотня гигабайт — терабайт) физической памяти, развитая система команд с полной поддержкой арифметики и эффективной компиляции из C-подобных языков, возможность работать в многоядерном режиме (соответствующие протоколы когерентности кешей, атомарные команды или CAS или Load Linked/Store Conditional), высокая производительность на смешанном коде (хорошее представление о типичном современном коде дают бенчмарки SPECint и SPECfp) допустимо расслабленное отношение к реалтайму — это вот такой минимум. Это сейчас x86/64, ARMV8-A, Power, MIPS64, в перспективе — RISC-V с расширениями (в базовой версии он микроконтроллерное ядро всё же).
Все эти процессоры что бы достичь высокой производительности должны скрывать безумную стоимость обращения к памяти — что достигается, во-первых, кешированием а, во-вторых, спекулятивным исполнением и развитой системой предикторов. Мы (человечество в целом) не умеем делать по-другоу пока. В академии есть всякие идеи, но в виде железа пока никто ничего удивительного не показал.
Заметим, что тут всё тот же лейт-мотив — универсальность ценой неоптимальности. DSP, молотящий строго 1 отсчёт звука за такт, программой где процент ветвлений составляет 0.1%, можно сделать гораздо эффективнее процессора общего назначения. Но такой DSP встрянет если ветвлений будет как в типичной прикладной задаче — 20% (данные SPECint) — он встанет колом. Можно сделать процессор для реалтайма, который будет гарантированно отвечать на прерывание за 5-10-15 тактов. Но это прямо конфликтует со сложной организацией защити и пейджинга памяти. И так далее.
Именно в этом смысле я писал «CPU общего назначения».
5. Увы, не фундаментальных. Книга Computer Architecture: A Quantitative Approach была выпущена первым изданием в 1990 году и до сих пор является THE BOOK и главным учебником (уровня доктората, ну, по нашему, аспирантуры) по разработке микропроцессоров. Да, конечно, всеми фирмами, разрабатывающими микропроцессоры, были получены сотни патентов на мелекие хитрости и улучшалки, но глобально никаких новых подходов мы не видим. VLIW был попыткой, но провалился по большому счёту. За эти годы было несколько мощных прорывов в алгоритмах построения компиляторов, что может дать вторую жизнь VLIW. Но пока что-то не видно.

1. Да, конечно, зависит и от частоты и напряжения, которые связаны, причём при данном техпроцессе — не линейно. Именно по этому если дана фиксированная РАБОТА, то будет sweet spot для техпроцесса. Если частота меньше такой, оптимальной — то мы сэкономим чуть-чуть энергии на секунду но будем работать сильно больше секунд и в результате потратим больше, а если частота больше такой оптимальной — то мы потратим меньше времени, но сильно больше энергии на секунду, и опять проиграем относительно оптимальной для данного чипа частоты. Но точно так же потребление при фиксированной частоте зависит от числа переключающихся транзисторов.
Да, сейчас процессоры агрессивно отключают ненужные блоки и даже уже учатся адаптивно менять частоты разных блоков (что делает процессор ещё сложнее — если вы работали с FPGA, вы должны знать, что как только у вас больше одного частотного домена, то всё становится куда сложнее), но сути это не меняет — если у двух процессоров на одной частоте с одним числом команд на такт надо потратить в 10 раз разное количество транзисторов на декодер, то этот блок сожрёт на одну и ту же (логическую) работу в 10 раз по-разному энергии. И именно это ставят в вину x86 адепты энергоэффективности ARM. И отчасти это правда, но эта очень хитрая правда — во первых, даже если там 10 раз, то это разница между 0.1% и 0.01% потраченной общей энергии (оценивая по площади, т.е. числу транзисторов). А, во-вторых, у всех современных высокопроизводительных процессоров L1$ инструкций — после декодера, что в целом уравнивает их на многих (не всех!) профилях нагрузки.
2. У меня список задач, решаемых на ЭВМ, очень широк, и редактирование текстов — это неплохо, но не более 10%.
3. SIMD-вычисления на x86 — неплохой компромисс между спец-железом, которое надо зачастую стыковать с привычным пользователю UI, и скалаярным FPU. Я не говорю, что там оптимальная производительность на джоуль, это было бы глупостью такое утверждать. Но масса задач выигрывает от SIMD «задёшево» но вот уже перенос на GPU куда проблематичнее.
4. big.LITTLE — это вообще не про ядро и микроархетиктуру, это организация SoC. Ничто не мешает сделать решения, аналогичные big.LITTLE, на ядрах Intel и, более того, Intel уже показала такие решения. К тому же мы тут говорим про достаточно мощные решения, для ноутбуков, не для смартфонов. Выигрыш от таких подходов там пока не очевиден.
5. Все современные CPU общего назначения очень одинаковые, пока нам компания Mill Computing, Inc не показала реального железа. Ну может быть кроме VLIW, из которых (общего назначения) остался жив один — Эльбрус 2000. Это всё суперскаляры, основанные на Tomasulo’s algorithm, со страничным MMU нужной степени иерархичности дерева страниц, обвешанные кэшами и предикторами переходов. В чём x86 гораздо сложнее ARM — в наслоении legacy, все эти SMM, real mode, возможность работать в 16-ти битном режиме, и прочее, что отъедает полезную площадь кристалла. Хотя, по оценкам специалистов, всё это отъедает не так много, как и пресловутый декодер. А у ARM8-A тем временем появилась команда специально для JavaScript :-)

И, да, есть примеры, где серверные оченьмногоядерные ARM'ы выигрывают у Core в request/joule, но это задачи, опять же, где надо очень много спать пока выполняется I/O, а не лупить full-on данные. Тоже прекрасная ниша (тут никакой иронии).

Вы поймите — я очень люблю ARM. И считаю, что x86 должен уйти, как динозавр.
Но как-то так получается, что ARM пока по ощущениям от реальных железок скорее похож на Atom чем на Core/Zen2. Это тоже нужная и важная ниша, но на столе мне нужен скорее Core/Zen2, Увы.
Да, мы ещё не видели N1, я возлагаю на него большие надежды.
Но с другой стороны физику не обманешь — и сумматоры с предсказателями переходов у всех плюс-минус одинаковые, и, боюсь, ARM, раскачанный до реальной производительности Core на тяжёлых задачах, и жрать будет примерно столько же, потому что ему для этого надо будет быть таким же сложным внутри, что бы выжимать последнии капли меж-командного паралеллизма из кода. Не очень понятно, где, кроме декодера, современный ARM может выиграть всерьёз у современного x86, в терминах перемноженных байт и взятых/невзятых переходов на джоуль…

1. На основании анализов микроахитектур таких людей как Агнер Фог и изданий таких как Анадатеч. Где публикуются анализы и бенчмарки такого уровня, какого мы не видели на этом сайте со вреёмн легендарной серии про архитектуру NetBurst. Плюс чуть-чуть здравого смысла — если говорить про именно потребление энергии (а не bottlenecks в производительности), то оно (потребление энергии) практически прямо пропорционально площади, занимаемой блоком на кристалле (если блок работает постоянно, конечно). Покажите мне декодер в floor plan хотя бы древнего Sandy Bridge. Его там и не увидешь толком. А значит и энергии он сожрёт немного, даже если отбросить кэш микроопераций (который тоже не бесплатен в джоулях, разумеется).
2. Текстовый редактор — один из немногих примеров нересурноёмкой по процессору и пропускной способности паямти задачи, которая (задача) здорово выигрывает от форм-фактора ноутбука (большой экран, хорошая клавиатура). Ну может ещё пауэрпойнт. Реальные задачи разнообразны. Если работа с текстами — основная задача, то да, нетбука хватит, и не важно там x86 или ARM, глупо с этим спорить. Фотографии? Видео? Звук? Программирование с локальной компиляцией и умной IDE, а не текстовым редактором? Мы делаем универсальный инструмент или пишмашинку? Нет ничего плохого в пишмашинках, они тоже нужны, но тогда их и надо так позиционировать. И там ARM будет блистать, спору нет.
3. Одно слово: latency. Батчи здорово считать на GPU. Обрабатывать поток — уже может быть не очень. Много проектов SDR на GPU вы можете назвать (я могу несколько, но на CPU я могу назвать несколько десятков)? А от SIMD оно здорово выигрывает. Как один из примеров. Да, было бы мило иметь DSP или FPGA, но пока что-то не видно их, да ещё и с открытой архитектурой, на наших материнских платах и задёшево.

Я вообще уже не понимаю, какие задачи запускают на слабых и даже средних ноутах. Разве нам не льют в уши постоянно, что всё клиентское ушло в мобильники?
Разве что тексты набирать как на пишмашинке и в терминалах (ssh) сидеть — там клавиатура нужна, а мощность не очень.

Нет, не троттлить, а просто работать как атом :) Не нагреваясь особо.
Троттлить будет мощный процессор с неадекватным охлаждением.
Делать процы с гетерогенными ядрами Intel обещает, кстати. Пару коровых ядер и пару атомных в одной сборке они уже показали. Но когда это пойдёт в серию — неизвестно.

Потому что OS — это печальная техническая подробность. Людям нужна не OS а приложения, пусть даже и только браузер. Но, как показывает практика, даже сейчас, когда всё вроде бы в облаках, браузера мало многим, нужен всякий корпоративный софт. Он есть под Windows а вод под альтернативную OS — не очень. И если с Windows/x86_64 на Windoiws/ARM8-A портировать не очень сложно (и то можно встрять в интересные засады), а вот с другими OS Всё будет ещё интереснее.

Процессоры на ARM намного энергоэффективней, нежели процессоры Intel и AMD

Нет никаких чудес. Два числа они перемножают примерно за одно количество джоулей, как и переход предсказывают. Сложность декодера x86 нивелируется кэшом микроопераций.
Огромный вклад в площадь и энергопотребление у x86 вносят огромные кэши. Поэтому на микробенчмарках ARM может казаться выгоднее (там работает ядро и кэши средних размеров, у x86 — ядро и огромные кэши), а на реальных задачах, где кэши важны, x86 выиграет (сожрав больше энергии, факт, но и сделав больше работы в то же время). Если же ещё вспомнить про SIMD, тот тут (пока нет реальных железок с SVE, а их что-то всё нет и нет и даже анонсов нет) x86 вообще вне конкуренции.
Другое дело, что arm'овой мощности хватит на интернте-клиента вполне. Ну, концепция нетбука не нова.

Из NAS в Workstation, без каких-либо отдельных устройств. Т.е. и в NAS и в WS по две сетевухи — гигабит для всех и 10 гигабит для прямой связи NAS-WS, точка-точка.
Остальные компы в доме ходят до NAS по гигабиту.

Я просто отдельную нитку оптики бросил :-)