eks Skrevet 7. mars 2018 Del Skrevet 7. mars 2018 Jeg har en MacBook Air som jeg har vært veldig fornøyd med. Det er en 13-tommer (Late 2010) med 4 GB ram og 2,13 GHz Core 2 Duo, 256 GB og GeForce 320M. Med andre ord, ingen racer. Kjøpte den da jeg begynte på jussen i Oslo, og hadde den med meg hele studietiden der. Det er nå tre år siden jeg ble ferdig, og den funker fint fortsatt, har ingen problemer med å kjøre High Sierra, eller behandle råfiler i Adobe Camera Raw. Batteriet begynner kanskje å bli litt skrøpelig, klarer vel ikke så mye mer enn to timer med normal bruk. Jeg må innrømme at jeg har veldig lyst på noe nytt som er så portabelt som mulig (vil ikke ha iPad), og har festet blikket på MacBook 12, vil-ha-faktoren er kjempesterk, problemet er prisen, den ender jo opp på over 20K fullspekket... Så jeg venter i spenning (lommeboka i nervøsitet...) på hva Apple finner på fremover. Lenke til kommentar
Lunaris Skrevet 7. mars 2018 Del Skrevet 7. mars 2018 Du svarer på ditt eget spørsmål her. MacBook Air henger den dag i dag, svært langt bak andre produsenter med tanke på ramme, design, skjerm osv. Det er derfor ganske usannsynlig at Apple velger å introdusere et nytt produkt, billigere eller ei, som er like forhistorisk designet som det MacBook Air er. En kan ikke bare tenke på hva som har vært paralleller tidligere i andre produktkategorier fra Apple. En må se på konkret konkurranse, og mulighetene de har. Jeg ønsker ikke nødvendigvis Core M-prosessor i MacBook Air. Ipad Pro koster 6500 kr, og har vært nede en tusenlapp mindre. Det får meg til å tro at Apple kanskje ikke har de ekstremt store utgiftene for A10X (eller fremtidens A11X), sammenlignet med Core M. Dette vet vi imidlertid ikke med sikkerhet. Det er godt mulig at det er for tidlig å introdusere ARM til MacBook pga. kompatibilitet, men hva vet vi egentlig om Apple sin posisjon i dette? Ikke så mye, vil jeg tro. Jeg vil i grunn gjerne ha en større MacBook, med flere USB-C tilkoblinger og større batteri. Da ser jeg for meg at Apple deler segmentet sitt i: - MacBook: 12-inch kafé-maskin, kall det hva du vil. Etter min mening et dårlig produkt pga pris. - MacBook Air: 13,3" og 15,4". Retina (eller 1600p, IPS etc. etc.), stort batteri, syltynn, strømgjerrig prosessor. - MacBook Pro: 13.3" og 15.4". Samme, bare tjukkere for kjøling, kraftigere prosessor, dGPU, høyttalere etc. Egentlig synes jeg at Apple burde gjort som i starten: MacBook (Air) og MacBook Pro. Førstnevnte til forbrukerne, og sistnevnte til produsentene. Jeg synes det du sier om hva du ønsker fra ny MBA er smart, og jeg er enig i at det ville vært lurt å gjøre og gi et bra produkt. Jeg ville fortsatt hatt en kraftigere CPU, men om jeg tenker meg om så bruker jeg kun den kraftigere CPUen jeg har til Windows programmer, så har forståelse for at Core-M vil være bra og. Det er ikke det jeg er uenig i, tvert imot det gir svært mye mening for meg. Men forskjellen ligger i at jeg ikke tror Apple vil gjøre det, at de har forlatt produktlinjen for godt og alt de gjør nå er bare å melke ut salg så lenge de kan. Altså fortsette med det de har holdt på med så langt. Det er mulig de kunne fått A11X billigere, men om vi antar Intel og TSCM har like produksjonskostnader så er A11X dyrere å produsere pga størrelse. Betale for R&D må de uansett om de bruker egen eller Intels. Men gjerne noe mindre for egne produkter da iPhone dekker det meste av de kostnadene. Så slipper de jo å betale inn ekstra til Intel for at de skal tjene penger. Men er jo godt mulig Intel tar en del ekstra for sine CPUer siden de ikke har så mye konkurranse akkurat. Og ellers, høy pris er jo Apples kjennetegn, hvorfor skulle de endre det? De fleste av Apples produkter legger seg over tilsvarende konkurrenter. Lenke til kommentar
Gjest Slettet+5132 Skrevet 8. mars 2018 Del Skrevet 8. mars 2018 (endret) Du må ikke skrive om alle programmer, du må rekompilere dem, som er for 99% av alle programmer en betydelig mindre oppgave. Det er gjort på et par minutt per program (stemmer ikek helt i virkeligheten siden det kan være små forskjeller også, men det er faktisk ikke så langt unna). Det kan være et lite knippe av programmer som vil kreve en stor endring, men dette er virkelig et lite, lite knippe av programmer og de fleste skrivebordsprogrammer går det nok raskt å rekompilere. For OSet i seg selv er allerede Darwin-kjernen for ARM klar, og jeg tviler på at resten av OSet bruker assembler i særlig grad. Se bare på Linux, der er det en smal sak å få til Ubuntu på ARM, og det har blitt gjort flere ganger. Emuleringen til Windows er kun for å vente på at programleverandørene skal få fingeren ut og støtte plattformen. Er det stor forskjell på Windows og Unix-baserte OS? MS har jo prøvd lenge å få programstøtte også for ARM uten emulering uten videre suksess. Finnes mye eldre programmer, programmer folk ikke ser noe poeng i å kompilere for ARM, og alle de må emuleres. Det vi si spesielt fra starten av så vil alt måtte emuleres. Og så håpe da at folk som har laget programmene kompilerer for ARM. Og selv da så er arkitekturene forskjellige. De har ulike instruksjonssett. Så måten du skriver koden på vil jo påvirke ytelse. God kode for x86 er ikke nødvendigvis god kode for ARM. Programmer er jo kodet rundt det mer komplekse instruksjonssettet CISC. Så da regner jeg med det er ting du vil ønske å skrive annerledes for RISC, selv om det fungerer på RISC så kan det være at du må gjøre mange instruksjoner for å få til noe som ville blitt gjort langt enklere og mer effektivt med CISC pga forskjellen i instruksjonssett. Så rekompilering vil vel heller ikke være helt ideelt? Husk at vi nå snakker om OS X, altså Unix, og her har man portet ganske vellykket over til ARM for Linux For programmer som har store krav til ren CPU-ytelse har du rett i at man nok burde skrive små deler av programmet om for ARM (absolutt ikke hele programmet, kun det som er ytelsesintensivt!). For den store mengde desktopprogramvare er ikke dette tilfellet derimot. Og beviset for dette er 1) På Linux har det gått greit, 2) På Windows klarte de faktisk å få OK hastighet med emulering! Det er et par småforskjeller mellom x86 og ARM, som gjør at kode som kjører på x86 kanskje ikke gjør det på ARM. Dette er derimot ganske lett å oppdage via kodeanalyseverktøy, og lar seg i de fleste tilfeller fikse uten store problem (og ofte gjør det koden mer robust å fikse dette uansett, samt at man kan få en ytelsesøkning på x86). Jeg sier ikke at det alltid er trivielt, men jeg tror også du overdriver litt hvor mye jobb det er Det vil være få programmer tilgjengelig i starten, men det er nok hovedsakelig fordi softwareindustrien ofte kan være en treg, treg masse (selv om vi kanskje tror det motsatte noen ganger). I startfasen vil de uansett også kunne la iOS-programmer kjøre i OS X for å mykne overgangen (dette vil kunne gjøres uten emulering, og uten noen form for rekompilering, spesielt etter iPad Pro hvor størrelsen på Apper er dynamisk). Microsoft sliter vel også fordi de prøvde å gjøre to ting på en gang: Introdusere ARM OG introduserte UWP, det gjør bøygen med å skrive nye programmer veldig stor, men ikke på grunn av ARM, men heller på grunn av helt nye APIer. Uansett regner jeg med at Apple avventer Windows sitt eksperiment med ARM før de gjør noe drastisk selv. En ARM-CPU er for all del ikke like rask som en Intel-CPU, men den kan være "rask nok". Det finnes allerede en haug med Chromebooks som kjører ARM, det samme med en haug av nettbrett som nesten brukes som en laptop, og et lite knippe Linux-laptoper med ARM. Vi har også sett diverse eksperimenter som lar deg bruke ARM-telefonen som skrivebords-PC ala Samsung Dex, Ubuntu Unity (offisielt dødt) og Windows Phone (dødt? med mulighet for gjenoppliving). Det var ikke mitt inntrykk at noen av disse feilet på grunn for lav ytelse, men heller på grunn av for lite nytteverdi / for tungvindt å bruke sammenliknet med en normal laptop. Og når det gjelder andre forskjeller mellom CISC og RISC tar vanligvis kompilatoren seg av dette. Det er uansett ikke ting du vil forholde deg til som utvikler. Endret 8. mars 2018 av Slettet+5132 Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå