Спасибо за статью, в основном за исторические ссылки — всё таки труд, хотя и воды хватает.
Пару замечаний и мыслей.
ответить же на вопрос: «Почему мы увидели полноценную рабочую станцию от Apple на ARM только сейчас?» — довольно сложно
Вроде несложно — не было на рынке достаточно производительного ARM-процессора, пришлось сделать самим.
станет ли новинка от Apple действительно эффективным решением, в отличии от своих ARM предшественников, это все еще уравнение с целым рядом неизвестных
Я думаю неизвестных тут почти нет, и будет более чем успешный успех.
все дальнейшее развитие собственной процессорной продукции у коллектива AMD всегда попадало в фарватер Intel
Кроме когда x64 первыми сделали AMD.
тот факт, что ни Intel ни AMD до их пор не представили сколько либо конкурентного решения на базе процессоров ARM, уже сейчас завоевавших абсолютное лидерство на рынке носимой электроники, вызывает откровенное недоумение
Intel пыталась, правда, не десктопный, а мобильный чип сделать — но потом забросила. Почему не делали десктопный очевидно — чтобы не рыть сук, да и нужды не было. А у AMD никогда не было ресурсов на сторонние разработки.
Почему все эти титанические усилия оказался провальными вопрос довольно спорный
Вполне понятный провал — опять же, процессор слабый был, но главное — ОС WinRT — какой-то непонятный огрызок, ни туда, ни сюда.
Если в 1994 году уход от процессоров IBM на новую перспективную архитектуру PowerPC
Наверно, всё-таки с Motorola они уходили на IBM Power.
Озвученный третий переход на новую ARM архитектуру в нынешнем 2020 году очевидно станет еще тем квестом, в чем уверен мы с вами еще не раз убедимся
Опять же — не вижу не единой причины, чтобы что-то пошло не так. Всё будет предсказуемо успешно.
Неужели на смену внутриклановой конкуренции наконец-то придет настоящая борьба за клиента?
Ага, придёт. Если Apple будет свой проц продавать. И если все сотни ОС и программ оптимизируют и перекомпилируют под MX. Сама по себе Apple со своей «экосистемой» вряд ли кардинально перетянет рынок даже ПК, не говоря о серверах, где ещё ничего непонятно.
Недавно закрыли мой вопрос. Дело было в том, что при заходе на страницу МосГорТранса браузер (Chrome, FF, Win, Lin) начинал есть всё ядро на 100%. Я посмотрел в отладчике, там всё время шла перерисовка, и я не мог понять кто её инициирует. Поискал аналогичные вопросы, не нашёл, задал свой. У кого-то повторилось, у кого-то нет. Но смысл был «как мне, столкнувшись с такой проблемой (на любом сайте), её решить, куда копать?». Шла вялая беседа, без ответа, а потом мой вопрос закрыли как спам. Я спросил в письме, за что? Говорят «вы пиарите сомнительный ресурс». Офигеть, думаю, модератор плохо видит что ли, что это сайт МосГорТранса. На что мне ответили, что я не написал, что это сайт МосГорТранса (а урл mosgortrans.ru не намекает, да). И что Тостер — это не сервис для решения проблем. Ну, замечательно, варитесь там в своём соку.
Смотрю на скриншот, вижу frog@enlight, сработал триггер: так, демосцена, интересно, интересно… Нашёл parajve, не нашёл meteoroids.asm. Странно, откуда у чувака исходник frog-а? Пришёл спрашивать, посмотрел на ник и тут-то до меня дошло! :)
Да тут всё — вкусовщина, я всего лишь высказываю своё мнение. В вопросах обучения людей не может быть без вкусовщины, мы же недетерминированы. Но я вам ещё раз пишу (вы, такое ощущение, пропускаете эти слова мимо ушей): Qt Creator быстрее запускается, быстрее работает и потребляет меньше памяти. Это совершенно объективно. Eclipse вообще, из большой тройки Java-based IDE, самый тормозной.
Про IDE спорить не буду, наспорился. Считаю что наоборот — IDE будет больше пугать, чем не-IDE. Ваше право считать как хотите.
Ну ОК. Признаю, что я, возможно, слишком высокого мнения о среднем ученике. Надо будет на кошках потренироваться, посмотреть — неужели это так сложно? При этом, чтобы делать какие-то выводы, нужна большая выборка и сложный тест. В общем, я останусь при своём, хотя допускаю, что, возможно, не прав. Посмотрим.
Программируя на языке уровня C\C++ невозможно не использовать командную строку. При этом, т.к. основная проблема с ней для «нулей» не понимание (как я написал, понимание можно дать максимум за час), а принятие, это надо сделать как можно раньше. Всё равно ведь придётся. А от того, что через n месяцев вы освоите какие-то конструкции C++, вам принятие легче не дастся. Так что как можно раньше. Никто ведь не говорит, что надо там писать то, что непонятно. Пиши то, что тебе говорят. И будет тебе правильная реакция.
Я вообще против «сахара» для новичков, как интерфейсного, так и языкового. Чем больше скрыто «за ширмой», тем больший будет шок, когда внезапно, из-за шага влево, всё развалится.
Если совсем невмоготу, и никак не идёт — возьми JS. Открываешь браузер, жмёшь F12 и программируешь до посинения. Никаких тебе ужасов с указателями, освобождением памяти и командной строкой.
Думаю, что новичку нет никакого дела до того, нативен UI-тулкит или нет. Тем более, что QT-виджеты копируют достаточно близко нативный UI. И вообще я не понял, при чём тут «образец UI»? QT Creator банально быстрее работает, потребляет меньше памяти и обеспечивает 146% потребностей новичка. К тому же вы пропустили главное — я против IDE для начинающих вообще.
Сравнивать по сложности концепцию командной строки и самостоятельное изучение С++ по Страуструпу — это или странное заблуждение, или неуместный троллинг.
Немножко замечаний. Не по фактическому содержанию курса (я его не смотрел пока), а по подходу.
Не могу согласиться с тем, что новичкам обучение изначально даётся через IDE. И, к слову, раз уж взяли IDE, то надо было брать написанный на C++ же QT Creator, о чём, прочем, выше написали. Так вот, совершенно странно считать, что обучающийся не справится с командной строкой.
C++ — это не Javascript и HTML. С++ предполагает ознакомление со сложной системой, напрямую связанной с ОС. Если предполагаемый ученик не справился с командной строкой — зачем ему вообще дальше продвигаться? Более того, на то, чтобы объяснить концепцию командной строки даже тому, кто её до этого видел только в фильмах про хакеров нужно, я думаю, максимум час. Объяснить, что им придётся всё равно с командной строкой работать, что запускается она вот так, туда можно что-то печатать, жать Enter и что-то появится в ответ. Показать, как из проводника ссылку на папку можно перетащить в окно с «терминалом». Всё.
Концептуально, для новичков, командная строка это маленький чёрный ящик, который «понятно» как работает. А IDE — это приборная панель межгалактического лайнера с тысячей переключателей, которые только отвлекают и создают неуверенность типа «что я нажал, куда всё делось, аа-а-а!». Более того, я считаю, что новичкам первое время полезно набивать весь код руками, без автодополнений, чтобы на уровне рефлекса запомнить базовые конструкции языка.
В общем — я против IDE, против Eclipse, за командную строку и олдскул.
Несущественное замечание: доставкой сообщений в сети IP занимается сетевой стек, инициируют передачу и приём пакетов специальные программы (в вашей аналогии — почтальоны). TCP (заказное письмо с уведомлением) и UDP («обычное» письмо) — это протоколы, т.е. формализованные способы передачи пакетов в сети, поддерживаемые сетевым оборудованием.
Ок, игра на JS в хроме. Тормозит. Было бы странно, если бы не тормозила :)
Читаем изначальный вопрос. Думаем. Догадываемся, что он не про скорость работы, а про скорость чернового компилятора.
Который ни разу много не ест и не тормозит. Тормозит всё потом уже, и память ест потом. Уже когда и основной компилятор отработает, когда кеши заполнятся, когда данные прогрузятся все.
Но при этом даже черновой компилятор V8 в несколько (предположительно) раз быстрее интерпретатора.
И это видно в тех тестах, когда из-за малого количества итераций ни у V8, ни у HotSpot основные компиляторы отработать не успевают: JVM с треском проигрывает.
А что тот тест падает — не удивительно, учитывая дату последнего коммита. И не именно в нём дело.
Про время старта JVM убедительно написано тут, просвещайтесь: http://benchmarksgame.alioth.debian.org/sometimes-people-just-make-up-stuff.html#jvm-startup-time
Простите, я не понимаю — какое отношение непонятно как написанная и неизвестная мне игра имеет к моему вопросу? Даже если не учитывать, что я не играю в игры.
Java ест столько, сколько дадут. Как и Chrome. С FF ситуация обстоит совершенно не так же.
Черновой компилятор V8 ест мало, работает быстро. Интерпретатор в Java ничего не выкидывает — это делает HotSpot.
Помимо V8 в Chrome есть кому память съесть. Нет никаких доказательств, что подход Chrome хоть чем-то хуже подхода JVM.
Зато есть немало доказательств, что непрогретый Java-код мягко говоря не оптимален — вот, например: https://github.com/floatdrop/v8-vs-java-bench.
Как и вечные жалобы на многочисленные бенчмарки: вы всё врёти! у вас ява не прогрета!
Есть множество реализаций ЯП, которые интерпретируют код построчно или поблочно, без какого-либо промежуточного представления. Собственно, все изначальные реализации JS именно так и работали.
Я понимаю, и частично разделяю ваш скепсис к скорости работы и потребляемым ресурсам приложений на Java. Но надо признать, что при условии предоставления достаточных объёмов памяти, чего никто не скрывает, оно зачастую работает вполне прилично и быстро.
Это могло быть правдой, если бы Google не доказал, что «черновая» компиляция — простая замена базовых логических блоков на соответствующий машинный код — почти ничего не стоит. И чтобы блок кода попал под C2, он должен выполниться далеко не 2 раза, а сильно больше.
У меня 3 вопроса.
1. Почему в из Hotspot до сих пор не выкинули вообще интерпретатор? Почему Google в V8 сделала это, а Oracle — нет?
2. Какая производительность чистого интерпретатора в Hotspot — кто-нибудь измерял, забавы ради?
3. Почему в явасрачах сразу же не фиксируется базовая установка: Java — для бэкенда, для «серверных» сценариев нагрузки, когда Hotspot выполняет большую часть времени небольшую, «горячую» часть программы, может власть всё заоптимизировать и закешировать? Иногда, когда такой тип нагрузки встречается в «настольных» приложениях, Java работает вполне сносно, если не считать относительно долгий запуск и повышенные требования к памяти. Но почему-то мало кому приходит в голову писать на Java браузеры, например, или медиа-кодировщики. Хотя, казалось бы, тут Java прямо напрашивается, т.к. сложность проектов зашкаливает. А причина проста — характер нагрузок просто не позволит Hotspot развернуться, ну и память тоже. Хотя, учитывая сколько памяти ест Хром — может даже Java эффективнее с ней работала.
Пару замечаний и мыслей.
Вроде несложно — не было на рынке достаточно производительного ARM-процессора, пришлось сделать самим.
Я думаю неизвестных тут почти нет, и будет более чем успешный успех.
Кроме когда x64 первыми сделали AMD.
Intel пыталась, правда, не десктопный, а мобильный чип сделать — но потом забросила. Почему не делали десктопный очевидно — чтобы не рыть сук, да и нужды не было. А у AMD никогда не было ресурсов на сторонние разработки.
Вполне понятный провал — опять же, процессор слабый был, но главное — ОС WinRT — какой-то непонятный огрызок, ни туда, ни сюда.
Наверно, всё-таки с Motorola они уходили на IBM Power.
Опять же — не вижу не единой причины, чтобы что-то пошло не так. Всё будет предсказуемо успешно.
Ага, придёт. Если Apple будет свой проц продавать. И если все сотни ОС и программ оптимизируют и перекомпилируют под MX. Сама по себе Apple со своей «экосистемой» вряд ли кардинально перетянет рынок даже ПК, не говоря о серверах, где ещё ничего непонятно.
Про IDE спорить не буду, наспорился. Считаю что наоборот — IDE будет больше пугать, чем не-IDE. Ваше право считать как хотите.
За Qt спасибо, всё время путаю.
Программируя на языке уровня C\C++ невозможно не использовать командную строку. При этом, т.к. основная проблема с ней для «нулей» не понимание (как я написал, понимание можно дать максимум за час), а принятие, это надо сделать как можно раньше. Всё равно ведь придётся. А от того, что через n месяцев вы освоите какие-то конструкции C++, вам принятие легче не дастся. Так что как можно раньше. Никто ведь не говорит, что надо там писать то, что непонятно. Пиши то, что тебе говорят. И будет тебе правильная реакция.
Я вообще против «сахара» для новичков, как интерфейсного, так и языкового. Чем больше скрыто «за ширмой», тем больший будет шок, когда внезапно, из-за шага влево, всё развалится.
Если совсем невмоготу, и никак не идёт — возьми JS. Открываешь браузер, жмёшь F12 и программируешь до посинения. Никаких тебе ужасов с указателями, освобождением памяти и командной строкой.
Сравнивать по сложности концепцию командной строки и самостоятельное изучение С++ по Страуструпу — это или странное заблуждение, или неуместный троллинг.
Не могу согласиться с тем, что новичкам обучение изначально даётся через IDE. И, к слову, раз уж взяли IDE, то надо было брать написанный на C++ же QT Creator, о чём, прочем, выше написали. Так вот, совершенно странно считать, что обучающийся не справится с командной строкой.
C++ — это не Javascript и HTML. С++ предполагает ознакомление со сложной системой, напрямую связанной с ОС. Если предполагаемый ученик не справился с командной строкой — зачем ему вообще дальше продвигаться? Более того, на то, чтобы объяснить концепцию командной строки даже тому, кто её до этого видел только в фильмах про хакеров нужно, я думаю, максимум час. Объяснить, что им придётся всё равно с командной строкой работать, что запускается она вот так, туда можно что-то печатать, жать Enter и что-то появится в ответ. Показать, как из проводника ссылку на папку можно перетащить в окно с «терминалом». Всё.
Концептуально, для новичков, командная строка это маленький чёрный ящик, который «понятно» как работает. А IDE — это приборная панель межгалактического лайнера с тысячей переключателей, которые только отвлекают и создают неуверенность типа «что я нажал, куда всё делось, аа-а-а!». Более того, я считаю, что новичкам первое время полезно набивать весь код руками, без автодополнений, чтобы на уровне рефлекса запомнить базовые конструкции языка.
В общем — я против IDE, против Eclipse, за командную строку и олдскул.
Читаем изначальный вопрос. Думаем. Догадываемся, что он не про скорость работы, а про скорость чернового компилятора.
Который ни разу много не ест и не тормозит. Тормозит всё потом уже, и память ест потом. Уже когда и основной компилятор отработает, когда кеши заполнятся, когда данные прогрузятся все.
Но при этом даже черновой компилятор V8 в несколько (предположительно) раз быстрее интерпретатора.
И это видно в тех тестах, когда из-за малого количества итераций ни у V8, ни у HotSpot основные компиляторы отработать не успевают: JVM с треском проигрывает.
А что тот тест падает — не удивительно, учитывая дату последнего коммита. И не именно в нём дело.
Про время старта JVM убедительно написано тут, просвещайтесь: http://benchmarksgame.alioth.debian.org/sometimes-people-just-make-up-stuff.html#jvm-startup-time
Java ест столько, сколько дадут. Как и Chrome. С FF ситуация обстоит совершенно не так же.
Черновой компилятор V8 ест мало, работает быстро. Интерпретатор в Java ничего не выкидывает — это делает HotSpot.
Помимо V8 в Chrome есть кому память съесть. Нет никаких доказательств, что подход Chrome хоть чем-то хуже подхода JVM.
Зато есть немало доказательств, что непрогретый Java-код мягко говоря не оптимален — вот, например: https://github.com/floatdrop/v8-vs-java-bench.
Как и вечные жалобы на многочисленные бенчмарки: вы всё врёти! у вас ява не прогрета!
Я понимаю, и частично разделяю ваш скепсис к скорости работы и потребляемым ресурсам приложений на Java. Но надо признать, что при условии предоставления достаточных объёмов памяти, чего никто не скрывает, оно зачастую работает вполне прилично и быстро.
1. Почему в из Hotspot до сих пор не выкинули вообще интерпретатор? Почему Google в V8 сделала это, а Oracle — нет?
2. Какая производительность чистого интерпретатора в Hotspot — кто-нибудь измерял, забавы ради?
3. Почему в явасрачах сразу же не фиксируется базовая установка: Java — для бэкенда, для «серверных» сценариев нагрузки, когда Hotspot выполняет большую часть времени небольшую, «горячую» часть программы, может власть всё заоптимизировать и закешировать? Иногда, когда такой тип нагрузки встречается в «настольных» приложениях, Java работает вполне сносно, если не считать относительно долгий запуск и повышенные требования к памяти. Но почему-то мало кому приходит в голову писать на Java браузеры, например, или медиа-кодировщики. Хотя, казалось бы, тут Java прямо напрашивается, т.к. сложность проектов зашкаливает. А причина проста — характер нагрузок просто не позволит Hotspot развернуться, ну и память тоже. Хотя, учитывая сколько памяти ест Хром — может даже Java эффективнее с ней работала.