36
-
sanyicks #36 de futhat, de más os-en nem ami nem vinfos. -
Komolytalan #35 Hogy ne egy bonyolult dolgot említsek, nézd meg mondjuk a Thread.sleepet, hogy milyen pontosságú különböző windows verziókon, meg mondjuk linuxon. És azért egy időzítő az nem az a hűde egzotikus cucc - timernek minden oprendszerben lennie kell. -
krajcsovszkig #34 Nekem win7-en szokott, tényleg inkább C++-os, de ez nem telepít, csak a meglévő telepítést állítgatja vagy mi, szóval szerintem ilyet a C#-os is csinálhat, de nem vagyok benne biztos.
Mindenesetre manapság csak winre szánt progit nem érdemes natívban írni, hacsak nem csinál valami komoly számításokat. -
#33
C++ szokott az lenni (bár Vista óta .NET az OS része, így lehet, hogy nálam ez nem jelenik meg (bár amilyen idióták a telepítők, úgyis megpróbálná felrakni, kb tucatszor volt mindegyik C++ runtime verzió is telepítve, DX frissítésekkel karöltve)), C# kiírását erősen kétlem, mivel assembly-k szempontjából indifferens, milyen nyelven íródott, mindegyik .NET program MSIL-re fordul. -
krajcsovszkig #32 Én azért elég sokszor látom, hogy telepítéskor ott homokórázik valami "Configuring Visual C++/C# 20** redistributable", játékoknál, ofiszoknál, meg egyéb, csak windowsra szánt programoknál. -
#31
Akkor tévedtem, mégiscsak hasznos lehet!:) (Bár nem tudom, Application folder-nél miben nyújt többet (Liont még nem próbáltam))
passatgt:
Mert mondjuk semmi kedvem kibogarászni, hogy mi is kell, spotlight-ba "ter", kidobja a terminált, kész. Gyorsabb, sokkal.
Sir Ny (#24): Elvileg csak ennyi, amennyiben minden könyvtár rendelkezésre áll másik platformon, és ugyanolyan az API (+ bugok:)). Csak lehet, hogy az alkalmazást kézzel optimalizálták adott utasításkészletre (értsd: nem a fordítónak adtak be egy új switchet), endianness is okozhat interoperabilitási gondokat... Mindez azt igényli, hogy a fejlesztő tesztelje újra a programot, terjessze azt, nyújtson támogatást hozzá... Nem biztos, hogy meglépi (főleg, ha esetleg már meg is szűnt).
krajcsovszkig (#12): én nem úgy látom, hogy Win32 manapság súlytalan lenne. Mikor legutoljára XP-t telepítettem, csak a Catalyst (+Paint.NET) miatt kellett .NET FW-t feltolnom... Későbbiekben lehet (idővel biztos:)), hogy csökkenni fog a súlya, de ugye most a visszafelé kompatibilitást feszegettem:) -
Sir Ny #30 „Amint elkezdesz valami olyasmit csinálni amihez rendszer függvények kellenek"
Mire gondolsz? -
#29
Én csak azt látom, hogy van ipad2 mondjuk és ezen kellemes sebességgel megy rengeteg dolog. HD játékok stb. A kisebb macbookokba is elég lenne ez a teljesítmény. Ráadásul ez x év múlva lesz addigra ki tudja hol tart majd az ARM technika. (Meg mivan ha 2-t, 5-t raknak egy gépbe...) -
#28
én eddig a Dock-on rákattintottam az alkalmazások mappára és ott volt az összes, nem tudom ki és minek spotlighoz egy programindítás miatt:D -
#27
Jelentem, én használom. Sokkal kényelmesebb indítani vele progikat, ha csak egy kezed van a trackpaden. Kényelmesebb mint előredőlni, és elkezdeni gépelni 2 kézzel a spotlightba. -
Komolytalan #26 Elvileg a JAVA volna a nagyon platformfüggetlen nyelv, aztán kis túlzással az is csak addig az, amíg megmaradsz a for ciklus meg az értékadás szintjén. Amint elkezdesz valami olyasmit csinálni amihez rendszer függvények kellenek, az már különböző Windowsokon is máshogy van, linuxon pláne, és akkor még architektúrán belül vagyunk. És ezt egy újrafordítás nem oldja meg.
Amik per pill nagyjából platformfüggetlenek (persze azok se teljesen) azok a böngészős cuccok. -
krajcsovszkig #25 Ja, kb ennyi lenne (az újrafordítás alatt azt értem, hogy arm-re is le kell külön fordítani, nem csak x86-ra), de terjeszteni is kell a másik verziót is, ami megduplázza a terjesztési költségeket. -
Sir Ny #24 De miért kell hozzá újrafordítani a programot? nemértem ( nyilván nem vagyok programozó, csak úgy érdeklődöm ). Megírják a programot mondjuk qt-ben vagy c-ben tökmindegy, használnak hozzá win32 api-t. Ha jól sejtem, akkor megnyomnak egy gombot, ami lefordítja a programjukat x86-ra, és kész, nem? Miért nem tudják ugyanígy lefordítani ARM-ra? -
krajcsovszkig #23 hát ha megírják rá, akkor fog, de újra kell fordítani hozzá a programokat és külön verzióban kiadni, amit a cégek jelentős része b*szik megtenni ha nem kényszerülnek rá. -
Sir Ny #22 Mért, a win32 API nem fut ARM-on? -
sanyicks #21 kivéve ha win32 api-t meg directx-et meg hasonló szarságokat használnak :) -
Sir Ny #20 Én nem értem ezt, gyerekek. Mégis ki az, aki ASM-ben ír programokat? ASM-en kívül meg mi archifüggő programnyelv? c? c++? cisz? python? qt? tcl/tk? Ezek nem csak, hogy bármilyen procin, de bármilyen oprendszeren elfutnak. Vagy a mai programokat miben írják? -
sanyicks #19 Hát akkor ennyi erővel már wint sem lesz kötelező használni :D mert kb mindegyik valamennyire multiplatform. Arról ne is álmodozz hogy az m$ ez fogja hagyni, amikor a vendor lock in-ből élnek. -
Komolytalan #18 Hát mondjuk ez a JS-ben megírunk mindent - mert html5 ugye nem programnyelv, csak egy leírónyelv - ez egyelőre még csak egy álom az MS, meg mindenki más részéről. -
krajcsovszkig #17 Arra válaszoltam, hogy az x86-os alkalmazások vajon menni fognak-e az ARM-es win8-on.
És persze, szerintem is lassabbak lesznek, de biztos hogy menni fognak. -
Komolytalan #16 Phenomh=Phenom, még mielőtt belekötne valaki. -
Komolytalan #15 Egy interpretált kód mitől menne simábban egy gyenge procin, mint egy natív kód egy erősebben? Itt arról van szó, hogy ha valakinek eddig volt MacBook Pro-ja, az majd valami Arm procis csodára cserélje. -
Komolytalan #14 Egy Corei7-re vagy Phenomh-ra gondoltam, nem a szerver procikra. Azokhoz képest is gyengék. -
Sir Ny #13 „hogy 10x lassabb lesz a csúcs Intel prociknál egész pontos számításban"
A mikhez képest? Mér hasonlítasz te egy ARM procit az Itaniumokhoz/Xenonokhoz? Ennek mi értelme?
Hasonlítsd őket a pentiumokhoz/celeronokhoz, úgy is az a réteg tart igényt ARM procákra, amelyik pentiumot/veleront venne. Úgy kéne nézni, hogy melyik éri meg nekik. SENKI, ismétlem SENKI nem fogja vásárláskor mérlegelni, hogy most ARM-ot vegyen, vagy Itaniumot. Mert nem egy piaci kategória a kettő. -
krajcsovszkig #12 .net, silverlight és az új html5-javascript alapú cucc biztos menni fog simán arm-en is, win32-ben meg már egyre kevesebben programoznak, az esetek jelentős részében teljesen fölösleges is. -
#11
Eh, Snapdragon-ben nyilván nem neon van. -
#10
Korábbi ARM CPU-khoz korábban is elérhető volt a VFP extension (pl Omnia2-ben elvileg van FPU), olyan Cortex A8-ról (illetve ARMv7-el kompatibilisről, mert Snapdragon-ben is van) pedig nem tudok, amiből kihagyták volna a Neont (SIMD extension, FP támogatással). Persze ez utóbbi lehet, hogy csak engem minősít:)
Azt, hogy az Apple leváltja az X86-ot ARM-ra a közeljövőben, több okból is kétlem:
-korábbi szoftverekkel való kompatibilitás megtartásához emulálni kell. Ehhez nem túl szerencsés, ha az emulálandó architektúra nagyobb teljesítményű, felhasználók azt fogják látni, hogy az új "twice as amazing" MacBook*-juk sokkal lassabban csinál meg dolgokat, mint a korábbi...
-Windowssal való kompatibilitás elvesztése (ok, lesz ARM-os Win8, de ennek x86-ossal való bináris kompatibilitásáról egyelőre nem lehet sokat tudni - szerintem nem véletlenül...) -
Komolytalan #9 A processzor nem olyan mint az autó, hogy megnézed az autóskártyán a végsebességet, és rögtön tudod melyik a gyorsabb és mennyivel. Az ARM eleve RISC technológiájú, vagyis egyszerű, mint a faék. Az Intel/AMD cuccosok meg CISC-ek, vagyis bonyolultak, rengeteg tranzisztorból állnak, drágák. Az ARM proci nem tud lebegőpontos számítást, az Intel/AMD cuccosok igen. Ahol össze lehet őket hasonlítani, az az egész számok aritmetikája, illetve memória (string) műveletek. Ezekben a csúcs ARM proci van ahol eléri egy 10 éves, azonos órajelű Athlon teljesítményét, van ahol 4x lassabb. Cserébe minimális a fogyasztása.
Másik oldalról a processzorban lévő lebegőpontos számítási képesség - amiben az ARM nem 100x, de inkább 1000x lassabb - az ma már nem feltétlenül szükséges valami. Ha sokat kell lebegőpontosan számolni akkor ott vannak a GPU-k, ha keveset akkor meg meg lehet oldani emulátorral, úgyse fog befolyásolni semmit se. Az persze tény, hogy jelenleg a GPU programozása messze nem olyan szinten automatikus, ahogy az prociban lévő FPU-é.
Mindezeket összevetve az ARM az Intel architekturához képest brutális teljesítmény visszalépést jelent - Cortex A-15 ide vagy oda. Ha azt mondom, hogy 10x lassabb lesz a csúcs Intel prociknál egész pontos számításban, és 1000x lebegőpontos számításban, akkor sokat nem tévedek.Viszont nem szabad két tényezőt elfelejteni:
1. Apple egy vallás. Ők képesek voltak a totál instabil, lassú, buta, folyton fagyó, Win3.1 szintű MacOS 9.x-el dolgozni 2000-ben is, vigyorogva, felsőbbrendűként. Vagyis attól hogy klasszissal szarabb lesz a gép, mint a jelenlegi almás termékek, még ugyanúgy meglesz a vásárló közönsége.
2. Apple az utóbbi évtizedben megmutatta hogy nagyon erős abban, hogy a gyenge, olcsó hw köré mókusvakító szoftvereket rakjon, amivel elfedi a gyengeségeket. Ha nem lesz lebegőpontos számítás, akkor első körben megmondják, hogy video konvertálás ördögtől való, második körben meg megcsinálják vagy (Intel/AMD alapú) felhőben az egészet, vagy GPU-val. -
coolbboy83 #8 Vers .... te ne féltsd az ARM rendszert, mert a NVidia Tegrák csúnyán jönnek föl, és pl Grafikus magban pont az Intel nincs kb sehol, bár haladnak ők is valamelyest :-) -
coolbboy83 #7 Ha egy kicsit előrébb nézünk, akkor hamar rá lehet jönni, hogy a klaviatúra is felesleges lesz néhány év mulva :-) de persze lesz még...
iOS és OS X összeolvadás..... lesz kereszteződés, de egy darabig tuti nem egyesül a két platform, aminek számos oka van egyértelműen ! -
coolbboy83 #6 Jön a Cortex A-15... na az már nem lesz olyan nagyon lassú, és keveset fog zabálni :-)
Az Apple 2008-ban kompletten megvett egy P.A.Semi nevű céget... mind a 250 fős CPU fejlesztő csapattal.. hivatalosan is PowerPC és ARM licenjogok tulajdonosa, valamint az AMD átadott neki több ATI GPU mérnököt tavaly ideiglenesen......
Daniel W. Dobberpuhl és hasonló nevek vannak a cégnél..... akik a legnagyobb CPU mérnökök a világon...
Annyira nem aggódnék az Apple nyilván saját rendszert akar minden téren ahogyan eddig is és nem akar majd függeni az x86-tól... vagyis az Inteltől... ami egykoron kényszerlépés volt a kedves IBM miatt, az más kérdés, hogy pont a P.A. Semi csinált egy 1.6 Ghz PowerPC procit, ami jó lett volna (fél évvel az Intelre váltás után) ez a chip pedig Dual Core volt és rendesen alázta az Intelt... lám 2008, a P.A.Semi az Apple kezébe került..... VALAMI KÉSZÜL, és az nem az A4 és A5 processzorok :-) az csak a sallang :-)
-
Vers #5 konkretan egy armos processzor 100-szor lassabb teljesitmenyt nyujt az intel jelenlegi csucsprocesszoranal, gpu teljesitmenyben meg rosszabb az arany 350-szer gyorsabb egy nvidia gpu pl az ipadnal -
endrúdí #4 És megszületik az EOS.
http://techline.hu/blogbazar/20110522_apple_future.aspx -
kvp #3 Kernel oldalon eddig se volt tul nagy elteres, csak a gui volt mas es sok dolgot kihagytak az ios-bol. Viszont ami nagy szam, az az, hogy a macos-en megint processzor valtas lesz, az m68k-ppc-x86 utan most az arm jon. Ez azert eleg durva, bar a masik ket korabbi valtast is megoldottak... Viszont erdekes az, hogy az apple szerint az atlagembernek nincs szuksege pc-re vagy teljes erteku operacios rendszerre. -
#2
Lion újdonságai alapján nekem is ez jön le, de nem feltétlen tartom jónak az irányt. Ami elsődleges beviteli célra érintőkijelzőt alkalmazó rendszernél bevált, az nem feltétlen célszerű, mikor billentyűzet is rendelkezésre áll (pl a Launchpad, mint feature szerintem vicc, Spotlight mellett vajon használja valaki?).
Az, hogy Apple megint meglépne egy architektúra váltást, szerintem még legalábbis odébb van, ARM processzorok sebessége még messze elmarad az x86-osokétól, s ez belátható időn belül aligha fog megváltozni. (Mondjuk egy heterogén multiprocesszoros számítógépet ki tudnék nézni az Apple-ből, még ha elég meredeknek tűnik így elsőre az ötlet
)
-
Inquisitor #1 Bejelenthették volna ezt a Windows8 hisztéria kitörése előtt is :)