Фото дня! Материнская плата с процессором Эльбрус-8С

Поздравление с Новым Годом от директора компании МЦСТ Александра Кима.

Дорогие друзья, коллеги, соратники! Уходящий 2015-й год был трудным, он прошёл под знаком новых угроз и вызовов. Подтверждается правильность курса импортозамещения, выбранного руководством страны, с опорой на отечественные технологии.

Компания АО «МЦСТ» в кооперации с ПАО «ИНЭУМ им. И.С.Брука» в течение года вела активную работу по созданию отечественной вычислительной техники различных классов.

[читать статью полностью...]

Кстати, а вы знали, что на «Сделано у нас» статьи публикуют посетители, такие же как и вы? И никакой премодерации, согласований и разрешений! Любой может добавить новость. А лучшие попадут в наш Телеграм @sdelanounas_ru. Подробнее о том как работает наш сайт здесь👈

Источник: mcst.ru

Другие публикации по теме

Поделись позитивом в своих соцсетях

Комментарии 0

Для комментирования необходимо войти на сайт

все комментарии

2

guest02.01.16 11:49:13

Java и C# не являются интерпретируемыми языками. Я не знаю, где вы эту глупость вычитали. Они компилируются в промежуточный машинный код, облегчающий разного рода безопасность и т. д. Этот код затем преобразуется в машинный код целевого процессора, и уже после этого исполняется. Причем целевой код обычно кэшируется и используется повторно. В последних версиях .NET даже можно скомпилировать полностью «нативную» программу. Так что там всё совсем не так плохо, как вы пишете. Хотя там и есть другие накладные расходы, например, там нельзя обратиться к произвольному адресу памяти и нельзя выйти за границы массива — все эти проверки, конечно, отъедают часть ресурсов (хотя и их иногда можно отключать).

#730694 ↑
- 0
  
  Neptus02.01.16 15:17:53
  
  Java и C# работают только в пределах своей изолированной виртуальной машины (программы). Это, именно, интерпретация промежуточного кода, а не прямое выполнение инструкций процессора. Поэтому, вы не видите адресное пространство процессора и обратно, этим обеспечивается безопасность.
  
  #730808 ↑
  - 0
    
    guest02.01.16 15:56:09
    
    «Книга драконов» 2-е изд. стр. 30: «Интерпретатор представляет собой еще один распространенный вид языкового процессора. Вместо получения целевой программы, как в случае транслятора, интерпретатор непосредственно выполняет операции, указанные в исходной программе, над входными данными, предоставляемыми пользователем».
    Так вот, скажите мне пожалуйста, где это вы видели, чтобы Java или C# выполнялись в виде непосредственного исходного кода? Нет такого. Вместо этого после компиляции мы получаем промежуточный бинарный код. И, как я говорила выше, для последних версий .NET возможно создание не только промежуточного, но и окончательного целевого машинного кода, который исполняется непосредственно (он так и называется «.NET Native», можете погуглить).
    Так что в лучшем случае это можно назвать гибридным способом исполнения — с одной стороны, делается трансляция в двоичный код виртуальной машины (виртуального CPU), с другой — код виртуального процессора преобразуется в код физического процессора. В любом случае, никакой интерпретации исходного кода там нет. Есть ограниченная интерпретация промежуточного кода, если можно так выразиться, но этот код — уже и так двоичный и очень похож на целевой двоичный код. Здесь нужно придерживаться какой-то общепринятой терминологии, иначе можно до чего угодно договориться.
    
    #730824 ↑
    - -1
      
      Neptus02.01.16 16:57:05
      
      Ваш промежуточный (почему то бинарный) код НЕ выполняется непосредственно процессором, а разбирается виртуальной машиной, что есть интерпритация!
      Процессором выполняются только то, что примитивно называется EXE и COM файлами (и библиотеками на их базе), остальное интерпретируется в программной виртуальной машине. И нечего размазывать…
      
      #730843 ↑
      - -1
        
        guest02.01.16 17:04:45
        
        Да что вы говорите, профессор. А вы знаете, что даже то, что вы «примитивно назвали» EXE и COM, тоже не исполняется процессором напрямую. Вместо этого тот же интеловский процессор сначала разваливает громоздкие CISC-инструкции на более мелкий микрокод, и только после этого его исполняет.
        Так где же мы границу проведем? Я еще раз повторю, давайте терминологией манипулировать произвольно не будем, а будем придерживаться общепринятых терминов и определений. Под интерпретацией понимают непосредственное исполнение текста исходного кода и точка. Иначе приведите авторитетные источники, опровергающие это.
        
        #730845 ↑
        
        -1
        
        Neptus02.01.16 17:23:48
        
        Цитирую вас: «EXE и COM, тоже не исполняется процессором напрямую. Вместо этого тот же интеловский процессор сначала разваливает громоздкие CISC-инструкции на более мелкий микрокод, и только после этого его исполняет."
        Вы после Нового Года?
        Вы не заметили, где у вас используется слово «процессор». Именно эта «железка» непосредственно выполняет программу и каким образом этот кусочек песка там её (программу) перекручивает, уже значения не имеет. Пользователь это никогда не увидит. А вот Java, Python, .NET, Basic,… всё работает через программную виртуальную машину(интерпретируются) и могут, с незначительными изменениями, быть перенесены не только с одной ОС на другую, но и на другой тип процессора.
        
        Отредактировано: Neptus~18:28 02.01.16
        
        #730850 ↑
        
        -1
        
        guest02.01.16 17:50:45
        
        Всё равно у вас слишком вольная трактовка термина «интерпретация». Я легко себе представлю аппаратный процессор Java безо всяких программных подпорок (да и вроде бы, такие существуют). Тем более не составит большого труда приблизить это всё к аппаратности учитывая, что Intel взяла курс на встраивание ПЛИС в свои серверные процессоры.
        Это же как с виртуализацией операционных систем — когда-то она была чисто программной, и вот теперь большинство современных процессоров поддерживают аппаратные функции виртуализации.
        Граница между «аппаратным» и «программных» в таких случаях достаточно условна, она зависит от спроса.
        В общем ладно, терминологический спор — он обычно бессмысленный и беспощадный. Одно я могу сказать точно, когда я перешла с «нативного» Дельфи на, как вы выражаетесь, «интерпретируемый» C#, скорость самых требовательных алгоритмов вообще никуда не уменьшилась. Например, у меня был алгоритм, читавший из БД несколько десятков тысяч «плоских» записей и выстраивающий из них огромную древовидную структуру, что на Дельфи это построение выполнялось около секунды, что на C# я перенесла — одна и та же секунда осталась.
        
        Отредактировано: Настя Вилкова~18:52 02.01.16
        
        #730860 ↑
        
        0
        
        Neptus02.01.16 19:16:28
        
        Вас постоянно заносит.
        Опять ляп с ПЛИС. Программируемая логическая интегральная схема ???
        Запомните! FPGA у Интела — floating point grid array — набор вычислителей с плавающей точкой. И к никакому языку они не относятся.
        Насчёт наитивной поддержки языковых виртуальных машин. Возможно в будущем, ведь есть в ОС GNU компилятор LLVM (low level virtual mashine) который компилирует разные языки в коды придуманной RISC машины. У процессора ARM есть Jazelle, акселератор (или помощник) для виртуальных машин Java.
        Насчёт аппаратной поддержки виртуализации ОС в процессорах. Там виртуализация работала и без аппаратной поддержки. Поддержка решает проблемы трансляции адресного пространства и нумерации портов во многократном вложении виртульных ОС.
        Насчёт скорости работы программы с БД. Там 99% времени работы — это сервер (встроенный или удалённый) этой базы. В своей программе вы делаете только запросы. Увеличьте или уменьшите базу в 2 раза и скорость вашей программы изменится соответственно.
        
        #730880 ↑
        
        0
        
        guest02.01.16 19:28:45
        
        Ладно, я уже поняла, что вы любите выдумывать свою собственную терминологию, раз даже FPGA умудряетесь расшифровывать уникальным альтернативным способом, а вовсе не так, как это делают сами интелы. Знакомьтесь, хотя бы тут: ece[dot]cmu[dot]edu[slash]~calcm[slash]carl[slash]lib[slash]exe[slash]fetch[dot]php?media=carl15-gupta[dot]pdf
        Processor: Intel® Xeon® E5-26xx v2 Processor
        FPGA Module: Altera Stratix V
        Надеюсь, я не должна вам рассказывать, что Stratix V — это ПЛИС, а не то, что вы придумали? Знала бы я, что вы любитель выдуманных терминов, сэкономила бы себе кучу времени…
        
        Отредактировано: Настя Вилкова~20:31 02.01.16
        
        #730882 ↑
        
        0
        
        Neptus02.01.16 19:49:33
        
        А вам не приходило в голову, что FPGA модули могут встраиваться куда угодно?
        Посмотрите, где наибольшая популярность FPGA была в последнее время. Это майнинг всяких крипто-валют, хотя изначально они сделаны для ускорения OpenCL.
        Не путайте ёлки с палками…
        
        #730891 ↑
        
        0
        
        guest02.01.16 19:58:26
        
        FPGA, OpenCL… ппц…
        
        #730901 ↑
        
        0
        
        Neptus02.01.16 20:36:14
        
        Прочитал вашу ссылку. Спасибо. Там термин FPGA совпадает с вашим ПЛИС.
        Но дальше там вы не читали… и про OpenCL.
        Я не думал, что Интел настолько слаб, что может скатиться до интеграции непрофильного оборудования. Теперь благодаря вам я это осознал. Какая-то Альтера сделала вычислитель в 30 раз производительнее чем у Интела. Интел — дерьмо!
        
        Отредактировано: Neptus~21:48 02.01.16
        
        #730911 ↑
        
        0
        
        guest02.01.16 22:04:09
        
        Вы чет зарапортовались.
        Intel купил Alerra.
        Это именно что плис.
        Такая хрень для которой на HDL программы пишутся. Если Вам нужна молотилка которая параллельно выполняет хренову гору одних и тех операций — лучше ПЛИС ничего нет. Она за один такт клока насчитает столько, на сколько процессору нужно потратить несколько микросекунд.
        И дело не в том что Intel якобы дерьмо.
        А в том что сравнивать ПЛИС и процессор — это как сравнивать теплое с мягким. Это совершенно разные устройства. ПЛИС — это более производительный вычислитель — в сотни раз, но не универсальный. Вот что Вы ей в прошивке положили — то она и считает — нельзя ей на ходу менять программы.
        На ПЛИС можно сделать процессор, да — пример тому Xilinx MicroBlaze например. Но это будет очень чахлый процессор, так как степень интеграции в ПЛИС ниже на порядок. Например чтоб положить в ПЛИС RTL современного MIPS (в Байкале-Т1 который в частности) — нужно с десяток 7х Виртексов с быстрым интерконнектом.
        А вот если Вам например надо наложить друг на друга две картинки и получить значение корреляции (и больше ничего не надо) — то Вам нужна ПЛИС.
        
        Отредактировано: Антон Смоленский~23:29 02.01.16
        
        #730939 ↑
        
        1
        
        shigorin02.01.16 22:58:55
        
        Я не думал
        В таком состоянии точно не стоит писать. Лучше спать. Затем умываться. Затем читать. И думать.
        Подозреваю, что вопрос CPU vs GPGPU vs FPGA разжёван в интернетах к нынешнему времени вдоль и поперёк на слишком много слоёв, чтоб ещё что-то добавлять. Очень вкратце для поиска -- specialist vs generalist.
        Ну и ни при чём тут OpenCL, как вот уже барышня и ухахатывались с ляпнутого.
        Стыдно же мужику корчить хорошую мину при настолько худшем, чем у девчонки, знании матчасти.
        
        #730967 ↑
        
        0
        
        shigorin02.01.16 22:55:30
        
        ведь есть в ОС GNU компилятор LLVM
        Нет такой ОС. Есть GNU Hurd, есть GNU/Linux (с такого и пишу). LLVM вообще чаще можно встретить на бзде или маке, как мне кажется.
        И будьте столь добры -- помечайте маркерами вроде «мне кажется» или «слышал» то, в чём не уверены. Повторюсь, введение в заблуждение доверчивой молодёжи -- страшно неприятная вещь, подчас ещё и заразная.
        
        #730964 ↑
        
        0
        
        shigorin02.01.16 22:53:15
        
        Кстати, с дотнетов дружески предлагаю потихоньку валить.
        Как вариант, почитать для разнообразия и развития (Вам же двадцать с небольшим, как понимаю?) что-нить из тех же лиспов, которые бывают и компилируемыми, но в любом случае «сильно иные». Может показаться интересной книжка SICP.
        
        #730963 ↑
        
        0
        
        guest11.01.16 04:31:53
        
        КоммонЛисп последнее время пошёл путём трупа страуса, а Ракетка окончательно впала в детство, увы.     Практически до уровня Алана Кея с его Скрэтчем, АКА «Смоллток для первоклассников».
        
        #733558 ↑
        
        0
        
        shigorin02.01.16 22:49:04
        
        Уважаемый, разберитесь с матчастью, желательно не по педивикии, а по чему-нибудь профильному. Вы написали уже достаточно много глупостей, которые могут пойти только на вред ещё менее понимающему в предмете организму.
        Постарайтесь начать с сущностей и слоёв.
        Как вариант, загляните в Инкиб -- надеюсь, там жизнь ещё теплится.
        
        #730962 ↑
        
        0
        
        shigorin02.01.16 22:46:33
        
        Настенька, не путайте разные слои этого пирога сами и других тоже не запутвайте ещё больше.
        То, что CISC-инструкции на x86 уже который десяток лет транслируются в потоки команд для RISC-ядра -- не отменяет того, что байткод какого-нибудь до диез требует СВЕРХ того трансляции в машинный код (тот самый CISC).
        При этом с предложением не крутить-вертеть терминологию полностью согласен. Равно как и удивлённо ищу .com/.exe на своём линуксе.
        
        #730959 ↑
        
        0
        
        guest11.01.16 04:35:55
        
        С точки зрения программиста это не так. Деталей работы декодера и перестановщика команд, блока переименования регистров и предсказателя ветвлений программист не знает даже он пишет на ассемблере: в микрокод его Интел не пускает, а если и кого по блату допускает, то требует подписывать жесточайшие NDA. Поэтому с точки зрения любого программиста на х86, это именно CISC процессор, непосредственно выполняющий его машинный код.
        
        #733560 ↑
  - 0
    
    vladtsvs09.01.16 14:47:37
    
    Там используется JIT компиляция
    
    #733084 ↑

Обсуждаемые

UMG разработала самый тяжелый автогрейдер в России

7 1341

Досрочный пуск блока Калининской АЭС даст дополнительно 148 млн кВтч

На Калининской атомной станции успешно завершился плановый средний ремонт третьего энергоблока. Пусковые операции проведены с опережением графика, чт...

3 171

В России налажено производство поплавковых конденсатоотводчиков

Конструкторский департамент НПО АСТАКонструкторским бюро и технологами подмосковного завода НПО АСТА была проведена разработка и налажен выпуск попла...

2 554