Може М1 е скутер за тебе, но скоро сите поголеми cloud компании (AWS, Azure), размислуваат за ARM серверски чип, а Микрософт и за десктоп варијанта.
Мислам дека на темава јас и ти и други имаме дискутирано и дека ќе се повторуваме, но нејсе. Во моментов и во блиска и средна иднина, без оглед колку феноменални ARM процесори ќе се измислат тие нема да бидат буквално никаква конкуренција на x86. Едноставно софтверот за x86 е толку обемен и распространет што никому не му се исплати екскурзија со ARM. Единствено Apple кои порано веќе беа на non-x86 архитектура се обидуваат да се вратат на стариот пат, не за друго туку за да бидат независни и компатибилни со своите мобилни телефони и таблети. Со многу труд и по многу време ќе бидат маргинална алтернатива и минимална замена на x86. Поточно ќе бидат замена само за офис компјутерчиња (таквите со M1) и за мал дел од компјутерите за продуктивност(музика, дизајн и монтажа). Оние кои до сега корситат x86 и понатаму ќе користат x86 за секоја сериозна намена, како и за аматерска.
happyware.com
ARM веќе е конкуренција на x86. Забораваш дека x86 загуби еден маркет од арм?
А зашто да имаш место еден мрсен, 100 мали сервери?
тоа е лесно во OpenSource пошто имаат 20 години искуство подршка за различни архитектури. Во proprietary (читај Windows) светот кај што шлапале кодови ко шо ќе им текне не е така лесно
Па само OSS делот да го лапнат не е мал залак.тоа е лесно во OpenSource пошто имаат 20 години искуство подршка за различни архитектури. Во proprietary (читај Windows) светот кај што шлапале кодови ко шо ќе им текне не е така лесно
AWS не размислуваат, веќе ги имаат нивните Graviton базирани инстанци. Причината за тоа не се перфоманси as-such - значи не е дека ARM RISC се инхерентно многу побрзи од x86 CISC. Причината е дека AWS веќе долго време (види Nitro архитектура) имплементираат свои специјализирани мрежни и storage контролери кои во себе преземаат дел од Cloud инфраструктурата, како per-tenant енкрипција, security-group-и (нешо ко firewall ама боље), VPC сепарација, failover итн итн.
Затоа што имаш workloads кои бараат single powerful core наместо повеќе а послаби.
А мислиш недоволно се моќни arm јадрата за да можат да се сносат со такви workloads? Ако гледаш серверски делови повеќе одат кон мулти-јадро перфроманси него ли на single.
Ама каде е предноста ако ти требаат 32 јадра да истераш едно? Не е се така црно-бело.
Не е тоа спорно, но сепак, има workloads.
не знам кој е контекстот на оваа реченица, но да, и ARM го има истото [Hyp mode (ARMv7 Virtualization Extensions, ARMv8 EL2) - ARM architecture - Wikipedia].
Епа не работат исто. Хипервижн не е ист како VT-x и VMCS.
www.javacodegeeks.com
Има толку многу примери на емулација, не само за конзолни игри, туку и од самиот Микрософт. Windows XP беше тотално различен оперативен систем од 95 и 98, но имаше компатибилен мод.
Правиш споредба со сервери на Интел и некоја мала компанија, која има многу мала подршка т.е ко да правиш споредба на локално продавниче, со веро/тинекс итн.АРМ сервери има многу одавна. Еве дома имам веб сервер комплет со PHP/SQL/Apache што работи на АРМ процесор. И не само тоа него комплет сервиси се одавна портирани на ARM платформата.
Сакам да кажам се користат унавелико.
Проблемот е до перформансите. ARM едноставно ги нема. Кога ќе ја преминеш линијата од домашен сервер на индустриски капацитет, најдобриот ARM нема шанси да се спореди со некој dual Xeon.
Ако имаш бази што треба да се баратаат брзо, ако ти треба 128GB рам, имаш 2х или 4х 10Gbit/s излези (или недајбоже QFSP/SFP), а во исто време имаш по 10к requests на порт тука ARM нема што да бара. Додај во миксот 10-20х Nvme ZFS pool од кој се влечат податоци и ARM ќе изгори. Тоа е муабетот за шлеперот со 800 коња.
За економични и практични мали сервери ги подржувам скроз, ама кога работата станува озбилна едноставно не. За десктоп апликации на Windows исто така едноставно не, освен ако не измислат начин за 1:1 емулација на х86, а неможат пошто се различни архитектури.
Еве ова мислам дека е еден од најдобрите ARM сервери.
H270-T71 | Gigabyte 4-Node Dual ARM ThunderX2 2U Rack Server
High density ARM server Per node: Mainboard: MT70-HD2 CPU: Dual socket (BGA 2601), ARM ThunderX 32 cores, 28nm technology RAM: 16 DIMM slots, up to 512GB...
8 x Marvell® ThunderX® ARM processors
Total 256 cores
2 x 40GbE QSFP+ LAN ports
1 x 10/100/1000 management LAN port
2 x 1600W redundant PSU
€9,210.00
Јас искрено не ја гледам заштедата.
Еве конкурентен High-end сервер од Dell (PE R840) разликата е минимална во цена, во перформанси не е..
Dell PowerEdge R840 Rack Server : Servers | Dell USA
Dell EMC PowerEdge R840 is a four-socket rack server in a dense 2U design that drives faster insights with up to 24 direct-attached NVMe drives.www.dell.com
И најважното не го спомнав, делл серверот што го линкнав е предвиден да работи со виртуелни машини, додека ARM незнам како котира со виртуелизација на сопствени машини, но сигурно не е на ниво на Vmware.
Ова звучи ко Amazon goes full IBM mode. IBM mainframe-овите се со слична, но сигурно далеку подобра имплементација заради декади на customer feedback
И без да го отворам линкот знаев дека е господинот Доктор Иан Катрес. Легенда од ревјуер.
Сите се за x86 архитектура. Мешаш работи.
Баш проблемот е во софтверот. Има премногу софтвер направен да работи за x86 кој не може едноставно да се портира да работи на ARM.
Многу глупости напишани во една реченица. Во секој случај нодот(ако се мисли на произвдствениот процес), со инстркуцискиот сет, со архитектурата, потрошувачката и со перформансите нема допирни точки.
Тоа што и кога имам учено нема никаква врска. Не знам дали добро сватиф што сакаш да кажеш со нивоата на апстракција, но софтверот кој веќе се користи, а го има во изобилие за x86 за да функционира на ARM треба комплетно да се преработи. Значи не се работи за едноставно прекомпајлирање туку за далеку посложен процес.
Карма-попара комапнија микс, немаат ништо заедничко меѓу себе, не гледам од кои причини некој од нив би сакал да прави притисок на Intel или AMD, a особено не Microsfot или Apple. Првите имаат тони софтвер за x86 кој е оптимизиран и фукнционира безпрекорно на веќе етаблирана мега-база на корисници. Вторите сакаат да тераат по свој пат и да не зависат никако до Intel/AMD.
Пак многу глупости напишани во една реченица. Прво постои елементарна разлика меѓу ARM и x86 и нивните перформанси не се мерливи бидјеќи се за различна намена. Второ, потрошувачката не е никаков фактор. Трето, ко што веќе кажав, ARM не е алтернатива на x86 за да некој воопшто се замра да иницинра миграција. Да не зборам за веќе постоечките софтвери кои работат на x86.
Пак мешаш работи. Од долги пантолони со ножица можеш да направиш куси, но не можеш од куси со ножица да направиш долги. Така можеш на моќен и комплексен x86 процесор да емулираш многу поедноставен процесор од PS1, PS2, PS3, Nintendo и слично, но обратно не можеш. И пак ќе повторам, примерот со Win XP ти нема никаква апликација на случајот, Win XP работи на x86 исто ко тие Win после него.
И потрошувачката е примарен фактор при изработка на процесори, за тебе може не, ама е за газдите на data-centrite.
Толку разбираш ти од инструкции и од процесори, а исто си слаб и математика. Си постои Church-Turing теорема со која може да се прават трансформациите ко на пример, if-then-else и go-to може да се трансформираат во for/while циклус т.е инструкциите од една архитетура може да се трансформираат во друга архитетура. Инструкција од x86 може да се трансформира во инструкција или повеќе инструкции од ARM.
Така е. Само првиот цели кон ефикасност, а вториот кон ефективност.
А знаеш колку софтвер не е накуцан во интерпретерски јазик како Јава (па да вози лесно со JVM)? Всушост се што е интерпретерски базирано ќе иде полесно, се што е компајлерски базирано малку потешко.
Сосема точно за специјализацијата. За денот останува да видиме. Некако многу време се трудат да навлезат во топ сегментите (2 децении најмалку), иако владеат на мобајл и IoT сегментите.
Хммм. Па не баш лесно се менува така архитектура. Посебно за софтвер каде екстензивно се користат предностите, и специфичностите на една архитектура, а нарочно каде брзината и продуктивноста е тесно врзана за специфични ISA сетови во самите компајлери (на пример математичко-статистички workload-и каде на Arm му недостигаат големи инструкции за множење на големи броеви, или паралелни собирања со пренос, едноставно архитектурата RISC нели, не го дозволува тоа). Ќе се повторам кај интерптретерите е малку полесно, но и таму има доста специфики.
Значи не е баш така како го претставувате симплифицирано. Не е само стисни compile ....... и готово.
Не. Важно им е најдобар сооднос потрошувачка/цена/перформанси. Не дека гледаат само на потрошувачка.
Да. НО, колку таа трансформација ќе биде перформанс ориентирана не кажува теоремата. Така да точно е дека голема специфична x86 инструкција може да ја трансформираш во 50 (карикирам) ARM Risc микро-инструкции, само колку се тоа ќе биде на крајот на денот ефективно/ефикасно е знак прашање. Важи и обратното, нормално.
Еве јас ќе се обидам, колку примери ти требаат?
What? Сите целат кон ефикасност и ефективност. Никој не цели кон едно или кон друго
Јава не е интерпретерски.
Ех сеа, глупости, сигурно не е ама за многу софтвер е! Еве набројав тон софтвер што има веќе искомпајлирани пакети и што опфаќа 60% од серверите на светот.
appleinsider.com
Абе едно е кон што целат, друго во реален живот како се понашаат.What? Сите целат кон ефикасност и ефективност. Никој не цели кон едно или кон друго
Ако ја тупиме Java е хибрид. Прво компајлира до бајткод, после на ниво на машина интерпретира со JVM. Е сега ти пошто спомна JVM таму погоре, на тоа ниво, т.е. на ниво на комуникација со процесорот (архитектурата) Jава Е ИНТЕРПРЕТЕРСКИ јазик. Ако се користи успат и JIT дел од тој бајт код може и да остане компајлиран за во иднина директно во машински, нели. Впрочем на таа шема работеа и голем дел од Андроид програмите кога главен беше Далвик ВМ пред да се шифтнат на АРТ. Нели имаше (и уште има) .class, па .dex ili .odex, па на крај преку JIT идеше у машински спрема чипот што се користи.
А ако не е напишано баш во GCC? Најголем дел од x86 софтверот (поготово за Windows) не е пишуван у плеин GCC.
Така е, и сега треба најголемиот дел да направат и код за секој посебен ARM специфичен процесор. Да напоменеме дека на пример Софтвер искомпајлиран за Qualcomm например, нема да работи на Ејпл М1. И сега требаат нови лајбрарис и hardware intrinsics специјално за М1. А за тоа ќе треба време и ресурси, и нормално дали ќе се исплати. Ќе видиме. Кај x86 е малку по стандардно. Дали било АМД или Интел, Дали било Core2Duo или незнам Zen3, истиот код (програмски или машински) ќе работи. Значи оверсимплифајт кај x86 компајлираш еднаш и работи на сите x86 kompatibilni procesori. Kaj Arm и не е баш така. Баш затоа на пример еве кај Андроид, не добиваш прекомпајлиран код пошто сиротиот Андроид појма нема на што микропроцесор од што призводител со свои специфични надградби на купената АРМ лиценца и специвични инструкции ќе работи. Ќе рече некој еј па ова супер. И да и не. Да бидејќи е платформски апстрахирано, Не бидејќи колку нешто напишано еднаш у рантајм прекомпајлирано специфично за даден чип ќе работи оптимално секој пат е дискутабилно и се гледа по разно разните телефони секојдневно.
А нив нели треба некој да ги среди за секој нов АРМ чип?
А само серверите и сервер стак е се на светов што се користи? Овие пакети се тука, пошто најдолго време има различни процесори за тие места. Корисничкиот енд јузер дел од програмите се на страна на x86. А што би рекол Linus, корисничкиот дел од базата е тоа што го движи најмногу еден или друг систем. Има напишано многу добар еден тред на оваа тема батката за зашто тешко или многу полека ARM би влегол дури и на сервер маркетот. TL/DR Првин се гради корисничка база, после се се рефлектира нагоре на посложено.
Ама нема сеуште, значи небило така просто само рекомпајл, и компајлерот/рантајмот за тоа нека се грижат.Parallels, VMWare confirm Apple M1 support amid silence from other virtualization companies | AppleInsider
Parallels is actively working on a new version of its virtualization software that will be compatible with Apple Silicon and M1 machines, the company said on Tuesday.
Ама нема сеуште, значи небило така просто само рекомпајл, и компајлерот/рантајмот за тоа нека се грижат. Башка баш кај нив се гледа според нив самите, дека ќе треба да поработат на досега развиените AI алатки и алгоритми, кои мноогу биле тесно врзани со хардвер платформата. Како ќе ги решат и колку ќе бидат оптимално решени, а во врска со ограничениот ARM инструкциски сет, дури и кај Apple M1, и сами незнаат. И додатно да се повторам, тоа што ќе го средат за М1, незначи воопшто дека истото ќе работи на било кој друг кастм АРМ процесор (какви што се повеќето нели). Секој од АРМ бејзд призводител на чипови, купува лиценца од АРМ ај да кажеме за основата и после го прави по свое понатака за специфични намени.
Не неможеш нејтив. Или знаеш повеќе од сите други. Пробуваат преку QEMU да го возат ама не е најсјајно. Ако знаеш ти оди по форумине кажи им да не се мучат луѓено. Од друга страна MySQL :: Supported Platforms: MySQL Workbench никаде не е спомнат ARM. Ама еве јас незнам.
Аха да.
