я прямо написал что то "так себе сравнение"… (безотносительно репутации таких *benchmark сайтов и что там где гуглится)
второй абзац вами проигнорирован полностью, повидимому?
Причем то тестировалось на реальных "боевых" задачах, от числодробилок до "биг-дата" (из памяти без IO), на билдах с -march=native -O3, SIMD и т.п.
Ну тут не только в нужном кратере ("озеро" на самом деле огромный кратер, см. под спойлером), а в нужную запланированую область кратера (размером 7,7 на 6,6 км).
Кратер Jezero с запланированой областью и реальным местом приземления Perseverance (картинка кликабельна), (c) sebres ...
Скорее всего "издержки" какого-либо перевода (необязательно автора статьи)…
Было возможно что-нибудь типа: Several hacktivist groups, Anonymous the most famous of them inter alia, have rushed to assert...
Но насколько помню, что то действительно мелькало в то время, про то что "безымянные" якобы открестились (в стиле "я — не я и э… попа не моя", типа — то же были Anonymous FreeAcuña — а совсем не тру анонимусы, мы и знать не знаем, просто название совпало).
Хотя вполне возможно, что или журнашлюхи напридумывали, или кто там на самом деле что сказал… да и доверие к тому — "безымянные", они на то и безымянные.
5800Х примерно на столько же быстрее 10700, насколько и дороже,
у 10700 (TDP) 65Вт
Откуда тут "i7-10700" (без K)?
Выше сравнивают R-7 5800X с i7-10700K, т.е. ни первое ни второе высказывания не верны — у него TDP 125W (TDP-down — 95W)
Про i7-10700 (без K) могу только сказать, что он совершенно точно будет "жрать" меньше того 5800Х под нагрузкой.
(я как бы тоже за AMD, но...) не вводите людей в заблуждение.
Не знаю чего там cpubenchmark показывает (у меня не открывается), но вот здесь например — https://cpu.userbenchmark.com/Compare/Intel-Core-i7-10700K-vs-AMD-Ryzen-7-5800X/4070vs4085 — они практически одинаковые.
Только то так себе сравнение (ну для примера поменяйте там Ryzen-7-5800X на TR 3970X, и там вам покажут что i7 даже быстрее стал, что будет нонсенс, сравнивая 8x vs. 32x и всё прочее, например 2x vs. 4x memory channel, 16 MB vs. 128 MB L3-cache и т.д.).
Точечные же замеры сделаные мной для обоих (не игры/FPS, а работа; и железки без overclocking) показывают что чем выше требования к кэш, т. е. например что-то скриптовое, "жрущее" или обновляющее кэш почем зря, или наличие паразитного вымывания (cache washout) и т.п., то тем лучше выезжает Ryzen-7-5800X (у него кэш как бы в 2 раза больше, т.е. при таком же количестве потоков, на том же throughput, он тупо реже лезет в память).
В остальном или никакой принципиальной разницы или i7-10700K местами даже чуть-чуть быстрее (хотя есть тесты где и Ryzen себя лучше показывет, хотя то возможно снова кэш).
Про потребление же ничего не могу сказать — не измерял.
Вы про SoC для A14? Не думаю что это настолько уж дорого в перерасчете на единицу процессора (тем более если оно затем отобьется на HVM), ну и во вторых в контексте данной статьи это не так уж и важно.
Очень правильный комментарий, всё так и есть.
Кроме одного незначительного пункта про цену на тот яблокофон.
Если проследить ценники на его комплектующие, если не про розницу, вы выйдете на $300 ну $350 максимум (а реальная стоимость их ещё ниже, но не суть), плюс затраты на разработку и т.д.
Остальное на рекламу и т.п. ну пусть чуть больше половины будет, т.е. чистая маржа там гигантская (так сказать за "имя" и новую модель).
Я что хочу сказать — в мировом масштабе, чтобы худо-бедно оценить упомянутую действительно "гигантскую всемирную цепочку" нужно сравнивать те $10 и возможно $200-$300, но простите никак не $1000.
Возможно iphone тут несколько неудачный пример, поскольку всё примерно то-же в техническом смысле, естественно без iOS, например на android, от Xiaomi и ко (я уж промолчу про noname какой-нибудь) где-то треть а то и ниже стоить будет.
Мой message про то что возможно "повторить голый EUV сканер" и не надо (будет), про то что EUVL не панацея, и про то что базовые принципы развития той же микроэлектроники не отличаются от других областей никак и это совершенно не зависит от того "состоялась" та область или нет. Тем более в близких к упомянутым периодах времени, исчисляющихся десятками лет.
Я Вас опять не понимаю. К чему вопрос относится?
Он относится к тому, что 2 параграфа в вашем предыдущем ответе мне (я начала цитатами выделил), посвящены разоблачению вещей, которые я не только не ставил под сомнение, более того даже намеком каким-либо не затронул.
но это не работает в настолько состоявшейся отрасли, как микроэлектроника
Я вам вообще не про это. И как раз НТП так не работает, от слова вовсе. Иначе мы бы с вами вместо современных смартфонов всё еще тяжелые коробки с лампами и памятью на магнитных сердечниках таскали, и ездили бы на машинах с паровыми двигателями. Все технологии имеют предел, в итоге — устаревают, принципиально модернизируются и замещаются.
И EUVL (и собственно метод литографии) здесь вообще как бы вторичен. Во первых нужно ещё решить кучу других проблем и задач (начиная от архитектурных и алгоритмических включая кэширование, конвейеры, спекулятивное исполнение и т.д. и заканчивая топологией, компоновкой, трёхмерным интегрированием, решений для processor-centric paradigm, near-/in-memory-computing, вот этим всем).
А во вторых миниатюризация (уменьшение размера транзисторов и затвора) как и собственно количественный рост их числа на чипе не есть самоцель. Вообще. Для достижения собственно настоящей цели можно "придумать" сотню других способов, начиная от замены количества на качество (замещение CISC/RISC на что-то принципиально новое), сверхпроводимости и т.п. и заканчивая теми же квантовыми чипами и иже с ними, какими бы фантастическими они сейчас не казались.
И даже если они еще в лучшем случае находятся в яслях лабораторий, а то и в головах ученых, 30 лет — это 30 лет. Ваш покорный слуга тридцать лет назад собирал свой новый 486sx с 512KB памяти и 20MB HDD, весело подмигивающий ему в консоли DOS (или NC), умолчим уже про первые версии винды или OS/2. А на производстве еще не забыли жесткие диски на несколько MB, размером с пивной ящик (и весом в цать кг), а местами и перфокарты.
Если кто-то думает, что EUV в ASML с неба упало, то очень напрасно.
И кстати, с EUV было и остаётся много проблем с прогрессом
И что это было? (я нигде про то даже намёком)… Сами придумали воздушные замки и сами с ними успешно поборолись?
Строго говоря вовсе не нужно его "повторять"… Есть куча альтернативных методов литографии работающих для <= 10нм, при этом не требующих такой же сложности масок, сканеров и дорогущей инфраструктуры как для EUVL. Для тех же NIL процессов, если не ошибаюсь, пределы разрешения составляют в настоящее время 5 нм (а в теории можно уже на "простом" электронном микроскопе худо-бедно работать). Там тоже хватает своих подводных камней и недостатков, но то всё в принципе решаемо, да и много где работает (например та же Toshiba так и не забросила NIL-технологию)…
Эти альтернативы не смогли утвердиться в массовом производстве до сих пор по большему счету из-за довольно неплохого прогресса в EUV-литографии. Но кто мешает их использовать и развивать в будущем, в том числе и в России, которая всегда была богата на Левшей выдающиеся ученые и инженерные умы. Ну а делать прогнозы насчёт "тридцать лет" и 50G$ в современном настолько динамично развивающемся мире — это вообще сродни "скоро акции условных Интелей/AMD/etc будут стоить 1К$" (и если в 2000-х еще до пузыря в это как-то можно было поверить, то сейчас… может да, может нет, может их вообще не будет, а может тот доллар тупо ничего не будет стоить...)
И даже какая она будет литография следующего поколения спрогнозировать с высокой долей вероятности вряд ли возможно.
Даже на х86, можно все драйвера скомпилировать в ядро и оно замечательно запустится на целевой машине.
Конечно можно, я не спорю… только это не так в той "убунте, с ядром 4.15 8мб", где оно всё лежит и в initrd в том числе.
Автор же собрал ядро без модулей (со статически слинковаными дровами)…
Поэтому я и написал как написал.
Вы уверены?.. Или initrd (initramfs) уже за kernel не считается? (ну попробуйте удалить… если никакие дрова или модули ядра на стадии бута не нужны, может и взлетит).
Не убунту, но тоже дебиан — (v.4.19) 48MB со всем барахлом (притом упакованным):
$ du -hc /boot/*-$(uname -r)
203K /boot/config-4.19.0-13-amd64
39M /boot/initrd.img-4.19.0-13-amd64
3.3M /boot/System.map-4.19.0-13-amd64
5.1M /boot/vmlinuz-4.19.0-13-amd64
48M total
$ file /boot/initrd.img-$(uname -r)
/boot/initrd.img-4.19.0-13-amd64: gzip compressed data, ..., original size 136074240
kt97679, я без понятия как оно для gentoo там (если всё собирается одним куском в ядро), но… strip случайно не забыли? :)
Ага… т.е. когда надо сделать такое как ниже, то нужно будет и далее кастить?
И если вот это вероятно будет работать и без cast(age as varchar) (из за нативного неявного преобразования между numeric и varchar):
select * from t1 where jf['age'] in (select cast(age as varchar) from t2)
то здесь нужно будет обязательно обернуть в кавычки?
select * from t1 where jf['name'] in (select '"' || name || '"' from t2)
Серьезно?..
Если так, то это несколько сомнительная реализация (как минимум какое-то половинчатое решение)…
Почему нельзя было сделать типизированный implicit cast (implicit conversion)? Ведь если это зарелизят в таком виде, то позже '25' на вход json "навсегда" останется numeric (для структур json), и "нормальный" inplace cast (где это varchar а не numeric) уже нельзя будет сделать позже из-за потери совместимости.
То есть любой конструктор, в том числе и например копи конструктор, будет веделять память.
Простите что?! Конструктор не вЫделяет память от слова совсем — он только инициализирует объект по переданному ему указателю. И например, если вы создаете объект на стеке (без new), то память под объект зарезервируется на стеке тоже.
И да "копи конструктор" тут тоже ничего не выделит (ибо оно уже выделено до него):
Test t1;
Test t2 = t1;
он будет лишь вызван и только.
Не путайте конструкторы и оператор new (new[] и иже с ними).
Соотвественно он будет опираться на кучу
Вовсе не обязан. Оператор new точно также можно переопределить — соотвеТственно он будет брать память хоть из стека (alloca и т.д.), хоть из пула (myownalloc), хоть из какого-либо ранее выделенного большего work-блока, который можно выделить одним куском для всей необходимой работы, например обработать request/response и освободить позже также одним куском (без какой-либо дефрагментации).
Параллельно с этим Google в значительной степени переориентировал свою стратегию IoT с предложения базовой операционной системы на использование Google Assistant на сторонних устройствах.
Ну да, ну да… Переориентировали они… Там такая "стратегия" что держись.
В google assistant даже не "на сторонних устройствах" простейшие вещи, типа создать собственную кастомную команду на дернуть какой-нибудь сторонний, например домашний, URL, (для к примеру "открыть/закрыть жалюзи"), выливаются в такой гиморрой, и в результате приходится делать или свои actions (Actions Builder & SDK, :nauseated_face:), или писать полноценный app/widget с пере-привязкой в GA, или юзать что-нибудь стороннее типа IFTTT.com
Для тех же Сирей, Алекс и т.п. это по слухам дело нескольких минут.
7 дюймов, 16:6?.. смотря для чего. Хотя сомнительный девайс так-то (только что ретро-стиль), с не очень понятной целевой аудиторией…
Если про модульность, или нужно что-то такое и не хватает таблетки/смартфона, то подобное можно получить собрав bundle типа:
Ras-PI 3/4 + touchscreen 7"-10" + powerbank какой-нибудь (+ mini-keyboard&(mouse|tb|tp), если очень уж надо) и немного синей изоленты (для ретровости). Ну или купить какой-нибудь готовый Ras-bundle aka "Ras-pad" в готовом корпусе (типа SmartiPi Touch и т.п).
Да и выйдет дешевле, кмк, и уж точно модульнее (по крайней мере всё юзабильное и без/вне устройства).
Если про ретро — то это дело вкуса (мне например не нравится).
Причем то тестировалось на реальных "боевых" задачах, от числодробилок до "биг-дата" (из памяти без IO), на билдах с
-march=native -O3, SIMD и т.п.Ну тут не только в нужном кратере ("озеро" на самом деле огромный кратер, см. под спойлером), а в нужную запланированую область кратера (размером 7,7 на 6,6 км).
Шедеврально, я бы сказал :P
Скорее всего "издержки" какого-либо перевода (необязательно автора статьи)…
Было возможно что-нибудь типа:
Several hacktivist groups, Anonymous the most famous of them inter alia, have rushed to assert...
Но насколько помню, что то действительно мелькало в то время, про то что "безымянные" якобы открестились (в стиле "я — не я и э… попа не моя", типа — то же были Anonymous FreeAcuña — а совсем не тру анонимусы, мы и знать не знаем, просто название совпало).
Хотя вполне возможно, что или журнашлюхи напридумывали, или кто там на самом деле что сказал… да и доверие к тому — "безымянные", они на то и безымянные.
Откуда тут "i7-10700" (без K)?
Выше сравнивают R-7 5800X с i7-10700K, т.е. ни первое ни второе высказывания не верны — у него TDP 125W (TDP-down — 95W)
Про i7-10700 (без K) могу только сказать, что он совершенно точно будет "жрать" меньше того 5800Х под нагрузкой.
(я как бы тоже за AMD, но...) не вводите людей в заблуждение.
Не знаю чего там cpubenchmark показывает (у меня не открывается), но вот здесь например — https://cpu.userbenchmark.com/Compare/Intel-Core-i7-10700K-vs-AMD-Ryzen-7-5800X/4070vs4085 — они практически одинаковые.
Только то так себе сравнение (ну для примера поменяйте там Ryzen-7-5800X на TR 3970X, и там вам покажут что i7 даже быстрее стал, что будет нонсенс, сравнивая 8x vs. 32x и всё прочее, например 2x vs. 4x memory channel, 16 MB vs. 128 MB L3-cache и т.д.).
Точечные же замеры сделаные мной для обоих (не игры/FPS, а работа; и железки без overclocking) показывают что чем выше требования к кэш, т. е. например что-то скриптовое, "жрущее" или обновляющее кэш почем зря, или наличие паразитного вымывания (cache washout) и т.п., то тем лучше выезжает Ryzen-7-5800X (у него кэш как бы в 2 раза больше, т.е. при таком же количестве потоков, на том же throughput, он тупо реже лезет в память).
В остальном или никакой принципиальной разницы или i7-10700K местами даже чуть-чуть быстрее (хотя есть тесты где и Ryzen себя лучше показывет, хотя то возможно снова кэш).
Про потребление же ничего не могу сказать — не измерял.
Вы про SoC для A14? Не думаю что это настолько уж дорого в перерасчете на единицу процессора (тем более если оно затем отобьется на HVM), ну и во вторых в контексте данной статьи это не так уж и важно.
Очень правильный комментарий, всё так и есть.
Кроме одного незначительного пункта про цену на тот яблокофон.
Если проследить ценники на его комплектующие, если не про розницу, вы выйдете на $300 ну $350 максимум (а реальная стоимость их ещё ниже, но не суть), плюс затраты на разработку и т.д.
Остальное на рекламу и т.п. ну пусть чуть больше половины будет, т.е. чистая маржа там гигантская (так сказать за "имя" и новую модель).
Я что хочу сказать — в мировом масштабе, чтобы худо-бедно оценить упомянутую действительно "гигантскую всемирную цепочку" нужно сравнивать те $10 и возможно $200-$300, но простите никак не $1000.
Возможно iphone тут несколько неудачный пример, поскольку всё примерно то-же в техническом смысле, естественно без iOS, например на android, от Xiaomi и ко (я уж промолчу про noname какой-нибудь) где-то треть а то и ниже стоить будет.
Мой message про то что возможно "повторить голый EUV сканер" и не надо (будет), про то что EUVL не панацея, и про то что базовые принципы развития той же микроэлектроники не отличаются от других областей никак и это совершенно не зависит от того "состоялась" та область или нет. Тем более в близких к упомянутым периодах времени, исчисляющихся десятками лет.
Он относится к тому, что 2 параграфа в вашем предыдущем ответе мне (я начала цитатами выделил), посвящены разоблачению вещей, которые я не только не ставил под сомнение, более того даже намеком каким-либо не затронул.
Я вам вообще не про это. И как раз НТП так не работает, от слова вовсе. Иначе мы бы с вами вместо современных смартфонов всё еще тяжелые коробки с лампами и памятью на магнитных сердечниках таскали, и ездили бы на машинах с паровыми двигателями. Все технологии имеют предел, в итоге — устаревают, принципиально модернизируются и замещаются.
И EUVL (и собственно метод литографии) здесь вообще как бы вторичен. Во первых нужно ещё решить кучу других проблем и задач (начиная от архитектурных и алгоритмических включая кэширование, конвейеры, спекулятивное исполнение и т.д. и заканчивая топологией, компоновкой, трёхмерным интегрированием, решений для processor-centric paradigm, near-/in-memory-computing, вот этим всем).
А во вторых миниатюризация (уменьшение размера транзисторов и затвора) как и собственно количественный рост их числа на чипе не есть самоцель. Вообще. Для достижения собственно настоящей цели можно "придумать" сотню других способов, начиная от замены количества на качество (замещение CISC/RISC на что-то принципиально новое), сверхпроводимости и т.п. и заканчивая теми же квантовыми чипами и иже с ними, какими бы фантастическими они сейчас не казались.
И даже если они еще в лучшем случае находятся в яслях лабораторий, а то и в головах ученых, 30 лет — это 30 лет. Ваш покорный слуга тридцать лет назад собирал свой новый 486sx с 512KB памяти и 20MB HDD, весело подмигивающий ему в консоли DOS (или NC), умолчим уже про первые версии винды или OS/2. А на производстве еще не забыли жесткие диски на несколько MB, размером с пивной ящик (и весом в цать кг), а местами и перфокарты.
И что это было? (я нигде про то даже намёком)… Сами придумали воздушные замки и сами с ними успешно поборолись?
Строго говоря вовсе не нужно его "повторять"… Есть куча альтернативных методов литографии работающих для <= 10нм, при этом не требующих такой же сложности масок, сканеров и дорогущей инфраструктуры как для EUVL. Для тех же NIL процессов, если не ошибаюсь, пределы разрешения составляют в настоящее время 5 нм (а в теории можно уже на "простом" электронном микроскопе худо-бедно работать). Там тоже хватает своих подводных камней и недостатков, но то всё в принципе решаемо, да и много где работает (например та же Toshiba так и не забросила NIL-технологию)…
Эти альтернативы не смогли утвердиться в массовом производстве до сих пор по большему счету из-за довольно неплохого прогресса в EUV-литографии. Но кто мешает их использовать и развивать в будущем, в том числе и в России, которая всегда была богата на
Левшейвыдающиеся ученые и инженерные умы. Ну а делать прогнозы насчёт "тридцать лет" и 50G$ в современном настолько динамично развивающемся мире — это вообще сродни "скоро акции условных Интелей/AMD/etc будут стоить 1К$" (и если в 2000-х еще до пузыря в это как-то можно было поверить, то сейчас… может да, может нет, может их вообще не будет, а может тот доллар тупо ничего не будет стоить...)И даже какая она будет литография следующего поколения спрогнозировать с высокой долей вероятности вряд ли возможно.
Конечно можно, я не спорю… только это не так в той "убунте, с ядром 4.15 8мб", где оно всё лежит и в initrd в том числе.
Автор же собрал ядро без модулей (со статически слинковаными дровами)…
Поэтому я и написал как написал.
Это можно было тупо сделать для скалярных элементов, а для того что бы вставить json, можно было просто указать это явно:
Ну то есть все индексы побоку? fullscan по выражению? :) Тогда уж что-нибудь типа такого:
Только, чем оно лучше того же
->>тогда? Сформулирую по другому, зачем еще один "странный" сахар для->>(неее, даже не для->>а для->)...Вы уверены?.. Или initrd (initramfs) уже за kernel не считается? (ну попробуйте удалить… если никакие дрова или модули ядра на стадии бута не нужны, может и взлетит).
Не убунту, но тоже дебиан — (v.4.19) 48MB со всем барахлом (притом упакованным):
kt97679, я без понятия как оно для gentoo там (если всё собирается одним куском в ядро), но… strip случайно не забыли? :)
Ага… т.е. когда надо сделать такое как ниже, то нужно будет и далее кастить?
И если вот это вероятно будет работать и без
cast(age as varchar)(из за нативного неявного преобразования между numeric и varchar):то здесь нужно будет обязательно обернуть в кавычки?
Серьезно?..
Если так, то это несколько сомнительная реализация (как минимум какое-то половинчатое решение)…
Почему нельзя было сделать типизированный implicit cast (implicit conversion)? Ведь если это зарелизят в таком виде, то позже
'25'на вход json "навсегда" останется numeric (для структур json), и "нормальный" inplace cast (где это varchar а не numeric) уже нельзя будет сделать позже из-за потери совместимости.Простите что?! Конструктор не вЫделяет память от слова совсем — он только инициализирует объект по переданному ему указателю. И например, если вы создаете объект на стеке (без new), то память под объект зарезервируется на стеке тоже.
И да "копи конструктор" тут тоже ничего не выделит (ибо оно уже выделено до него):
он будет лишь вызван и только.
Не путайте конструкторы и оператор new (new[] и иже с ними).
Вовсе не обязан. Оператор new точно также можно переопределить — соотвеТственно он будет брать память хоть из стека (alloca и т.д.), хоть из пула (myownalloc), хоть из какого-либо ранее выделенного большего work-блока, который можно выделить одним куском для всей необходимой работы, например обработать request/response и освободить позже также одним куском (без какой-либо дефрагментации).
Ну да, ну да… Переориентировали они… Там такая "стратегия" что держись.
В google assistant даже не "на сторонних устройствах" простейшие вещи, типа создать собственную кастомную команду на дернуть какой-нибудь сторонний, например домашний, URL, (для к примеру "открыть/закрыть жалюзи"), выливаются в такой гиморрой, и в результате приходится делать или свои actions (Actions Builder & SDK, :nauseated_face:), или писать полноценный app/widget с пере-привязкой в GA, или юзать что-нибудь стороннее типа IFTTT.com
Для тех же Сирей, Алекс и т.п. это по слухам дело нескольких минут.
Вариация на тему Гауссовых интегралов...
Может тут понятнее станет (см. на площадь функции f(x)):
https://www.integral-calculator.ru/#expr=e%5E%28-%20%CF%80x%C2%B2%29&lbound=minf&ubound=inf
7 дюймов, 16:6?.. смотря для чего. Хотя сомнительный девайс так-то (только что ретро-стиль), с не очень понятной целевой аудиторией…
Если про модульность, или нужно что-то такое и не хватает таблетки/смартфона, то подобное можно получить собрав bundle типа:
Ras-PI 3/4 + touchscreen 7"-10" + powerbank какой-нибудь (+ mini-keyboard&(mouse|tb|tp), если очень уж надо)
и немного синей изоленты (для ретровости). Ну или купить какой-нибудь готовый Ras-bundle aka "Ras-pad" в готовом корпусе (типа SmartiPi Touch и т.п).Да и выйдет дешевле, кмк, и уж точно модульнее (по крайней мере всё юзабильное и без/вне устройства).
Если про ретро — то это дело вкуса (мне например не нравится).
Недавняя видео-конференция от создателя (DRH) про sqlite, c 11:09 — The S&T 2020 Conference — D. Richard Hipp, презентация — SQLite Status Report 2020 — Slide 0