Bajosnak ígérkezik a fejlesztés az Apple legújabb gépeire
2020-11-12T14:52:48+01:00
2020-11-28T05:55:01+01:00
2022-07-20T12:46:50+02:00
  • Elég meggyőző a teljesítmény, egy nem gyerekjáték projecttel:

    PostgreSQL Benchmarks: Apple ARM M1 MacBook Pro 2020

    (
    ez apple clang a fordító.
    a postgresql forráskódon a mérete és az eltelt idő miatt sokmindent nem reszelhettek,
    és ha egy akkora project fordul, akkor az apple-s cuccokkal biztosan nem lesz gond.
    szerintem nem kell sokat várni a gcc-re sem.
    )
    Mutasd a teljes hozzászólást!
  • M1 == MONE(Y)
    Mutasd a teljes hozzászólást!
  • Inkább az eszed amit kapsz

    Inkább. De a lehetőség mindig ott van, hogy lecseréljék azt a digitális kockásfüzetet valami arra alkalmasabb dologra. Csak jóvanazúgy. Ha eddig jó volt, most is az, csak aggyá' ramot mer' nem megy ez a sz*r. És sosem a kacsa a hülye, amiért a víz nem tartja fent.
    Mutasd a teljes hozzászólást!
  • És nagyon jól fut a M1-es Apple chip-eken a Visual Studio Code.
    Mutasd a teljes hozzászólást!
  • Inkább az eszed amit kapsz jellegű helyzet szokott lenni..
    Mutasd a teljes hozzászólást!
  • Ja. Üdv a pokolban.
    Mutasd a teljes hozzászólást!
  • A VS Code egy tök jó cucc, és nem akkora dinoszaurusz mint a Visual Studio. Azt a 32-bites lassú, instabil, platformfüggő förmedvényt már ezer éve ki kellett volna dobnia a Microsoftnak, csak hát pont a sok ezer Pistike által összegányolt plugin miatt nem lehet.
    Mutasd a teljes hozzászólást!
  • Annyi légy nem tévedhet. ;)
    Mutasd a teljes hozzászólást!
  • Akkor még nem jártál a való világban... ;)
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • akkor még nem Exceleztél rendesen... ;)

    Akkor nem a feladathoz választottad az eszközt... ;)
    Mutasd a teljes hozzászólást!
  • akkor még nem Exceleztél rendesen... ;)
    Mutasd a teljes hozzászólást!
  • WSL2 azert joval tobb, mint egy atlag virtualis gep. A VSCode meg meg mindig csak egy text editor, amiket telepaszhatsz tobbnyire pistike altal keszitett pluginokkal, hogy OLYASMI legyen, mint egy IDE, de sosem lesz az. A hype miatt megprobaltam mar tobbszor is valtani ra, de max 2 het utan mindig visszavaltottam.
    Mutasd a teljes hozzászólást!
  • Ha elindítasz pár docker konténert hamar elfogy a 8GB akkor is, ha az összes toolod assemblyben van, és áttérsz a code-ról a vim-re. Amúgy mostanság én is code-ot használok.

    Az új windows terminál már egész jó, felveszi a versenyt a linuxos terminál emulátorokkal, és azért a powershell sem annyira rossz cucc (de van fenn bash is). Ja, és a wsl2-vel bármikor tudok linuxos command promptot is indítani, kb. a sima powershelles command sebességével indul, és a dockerem is WSL2-ből megy.
    Mutasd a teljes hozzászólást!
  • A nyelv jobb alsó sarokban, és bárhol a képernyőn elhelyezve nálam okafogyott, mert kb mindent full screenben használok a desktopot kb, sohase látom. 
    A WSL is csak egy virtuális oprendszer Win alatt ha jól tévedek 2 oprendszer persze több memóriát eszik. 
    Nálam az IDE az VS code, az egy kicsit kevesebbet eszik mint a JetBrains.

    Nem tudom mennyire volt szó róla, de az új ARM mac-en az iPhone appok is natívan fognak futni ... nem mintha nálam ez különösen fontos lenne.

    Plusz ideje megtanulni az ARM assembly-t.
    Mutasd a teljes hozzászólást!
  • Azzal egyet ertek, hogy a UX jobb, mint Windows-on, de azert a felsorolt "kulonbsegekkel" nehez egyet ertenem.

    - Windows Terminal + WSL2 / Docker
    - Choco, Scoop, WinGet, vagy netan npm
    - Van ugyan olyan meret Windowsos gepbol is
    - A touchpad meretei valoban jobbak, de a mai ertelmesebb Windows-os laptopokban is van Precision tamogatott remek miosegu touchpad.
    - Touchbar, ezzel nem tudok vitatkozni, szeretnem, ha nekem is lenne.
    - En touchbar nelkul is tudom ezt, hisz Windows irja kozvetlenull az ora mellett a jobb also sarokban.

    Kinek mi, de nekem a 8GB az mar evekkel ezelott sem volt eleg semmire. Laptopon mar valtottam 32GB-ra kb. egy eve, asztali gepen most tervezek 32-rol 64-re menni, folyton 80% felett van. Nehany JetBrains IDE, 20-30+ Chrome ablak, nehany Docker container WSL2 alatt es mar el is tunt...

    A max 16GB miatt nekem igy szoba se johetne.

    Szamomra az egyetlen igazi elony egy Mac-en a UX lenne, de mar csak elvbol sem lesz Apple termekem sosem.
    Mutasd a teljes hozzászólást!
  • Mint a neve is mutatja az git-re van kitalalva, ha barmi olyat szeretnel ami cd,ls,git kombon tulmutat jo esellyel nem fog mukodni. Akkor mar inkabb cygwin de miota van wsl azota felesleges barmi masra idot vesztegetni.
    Mutasd a teljes hozzászólást!
  • Mi a borzasztó a GitBash-ben?
    (Csak mert én azt szoktam ajánlani winnél :D )
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Miert van ez a gondolat, hogy gondok adodhatnak?

    Szerintem nem kene gondnak adodnia. 

    Mert amit nemreg kiadott az Apple fejlesztoi mac minit abban is mar az Apple silicon mukoditt, igaz nem pont ez a fajta de ez az architektura, es a korabbi ipadekben is ez mukodott.

    Tehat ha ment a fejlesztes ipadre, menni fog az uj gepeken is.

    Ha architekturalisan megnezitek, milyen egy iPad procija, es milyen az uj gepeke, kb annyi az elteres, hogy az orajel fol van tekerve, es a RAM belekerult a processzorba, ami szerintem negyon erdekes ... de ez minidegy, a lenyeg, hogy a processzor az egy felcsavart iPad proci ha jol megnezitek ... nincs dedikalt videokartya, max 16 gigaram a magok szerkezete pedig feltehetoen azonos a telefonokban hasznalt magokeval hozzavetolegesen.

    Lehet lesz nemi libekben problema, de nem kene hogy legyen feltetlen.
    Mutasd a teljes hozzászólást!
  • gitbash se rossz window-on, de egy iterm2 azért fényévekkel jobb.

    A gitbash borzalmas de szerencsere van WSL.
    Mutasd a teljes hozzászólást!
  • Jelenleg egy 8GB-os 2019-es MacBook Pro-t használok fejlesztésre, és eddig messze ez a legjobb számítógép amivel volt dolgom.

    A kulcs pontok amivel veri a többi gépet: 

    + gyakran használok konzolt és bár a gitbash se rossz window-on, de egy iterm2 azért fényévekkel jobb.
    + brew meg egy csomó jól használható általában rust-ban írt cli parancs: zoxide, tokie, broot, hors
    + optimális méret, mert sokszor változik hogy épp hol van alkalmam kódolni. Digitális nomádoknak kötelező darab
    + touch pad: az előző ponthoz kapcsolódva, remek gesture-ok, villámgyors többképernyő, kiemelkedően jó vertikális és horizontális wheel. Kb. azóta nem használok egeret.
    + touch bar: bár ez még a fizikai esc gomb nélküli model, viszont rengeteg kényelmes funkció kerül rá, pld színválasztás, így nem 
      de az igazi űber funkció a billentyűzet nyelv kijelző / váltó gomb a szélén, így mindig tudom, hogy magyaron vagy angolon van a billentyűzet.

    - komoly 3D modellezésre, intenzív 2D rajzolásra nem használnám, mert túl gyorsan felforr a proci és a venti elég hangos.

    Igaz nem olcsó model, de szerintem megéri az árát. Ha meg filléres gépen akarnék fejleszteni, akkor ott porosodik a polcon egy android TV box, kb. 10eFt, arra már csak egy linux kell felrakni, meg egér, billentyű, monitor,
    egyszer talán lesz rá időm összerakni.
    Mutasd a teljes hozzászólást!
  • Igazából a fix 16GB is elég hülyén hangzik. Excelezni sok egy kicsit, de van jó pár olyan dolog, amihez rohadtul kevés. Persze az is igaz, hogy a célcsoport azt sem tudja, hogy mi az a RAM, nekik az alma logó a lényeg, és hogy elég drága legyen. Amúgy szerintem felesleges fejlesztés: azoknak, akik ezt veszik, Z80-al is eladhatták volna.
    Mutasd a teljes hozzászólást!
  • Az Apple-t ismerve, az lett volna a meglepo, ha ez nincs igy. :)
    Mutasd a teljes hozzászólást!
  • 16 Gigabites RAM? Elég hülyén hangzik. Talán 16 GB-ot akartál írni!

    a legjobb az lett volna ha még az M is kicsi, mert akkor millibit lett volna az első.
    Mutasd a teljes hozzászólást!
  • A cikkben linkelt apple doksibol:

    Apple platforms diverge from the standard 64-bit ARM architecture in a few specific ways. 
    Mutasd a teljes hozzászólást!
  • A probléma ráadásul nem csak az egzotikusabb eszközöket, de az olyan általános célú és elterjedt fordítókat is érinti majd, mint pl. a GCC vagy az LLVM, amik egyelőre szintén nem lesznek képesek kódot generálni az új Mac-ek processzoraira.

    Miért is? Nem 64 bites ARM ez az új csodaprocesszor? Arra már évek óta fordítjuk GCC-vel a kódjainkat, sőt a Linux is évek óta szépen fut rajtuk.

    Tehát miért lesz baj a GCC-vel és az LLVM-mel?
    Mutasd a teljes hozzászólást!
  • Én örülök neki, hogy végre kezdenek felhagyni a CISC-cel, már rég el kellett volna felejteni az x86-ot meg a z/Architecture-t. Már az is bűn volt, hogy az Intel kifejlesztette a 80386-ot: ha annyira kellett a vevőknek az x86, akkor lehetett volna benne egy x86 és egy RISC utasítás-dekódoló egység is, úgy mint a kezdeti Itanium-okban: IA-32, IA-64 is volt. Az pláne bűn volt, hogy az AMD nem így csinálta, hanem az IA-32-t bővítette ki 64 bitesre. Az IBM is áttérhetett volna hardverutasításokkal támogatott szoftveres emulációra: például regiszterek indexelése regiszterben levő regisztersorszámmal, stb. Vagy z és Power utasításdekódolót is építsen bele ha annyira kell neki a z/Architecture: eleve ki se kellett volna fejlesztenie, 32 bites volt az s390, válthatta volna 64 bites Power: x390 + Power utasításdekódoló, vagy szoftveres emulátor. Mikrovezérlőben is felesleges a Motorola 68K sorozat, ott az ARM, MIPS, stb. Asztali számítógépbe remélem majd Fujitsu A64FX-et tesznek: lehet az is 5 nm-es, HBM3/4 memóriával, stb. Sok a 256 byte-os cache vonalméret, jobb lenne 16-64 byte-os.

    Apropó, ECC ebben van-e? Annyit tudok, hogy a Micron gyárt ECC-s LPDDR memóriachipeket, így jöhetnek az ECC-s okostelefonok, tabletek, laptopok, beágyazott rendszerek, Raspberry Pi, stb. Szerencsére a DDR5 már mind Registered lesz, és reméljük mind ECC-s.
    Mutasd a teljes hozzászólást!
  • 16Gb
    Mutasd a teljes hozzászólást!
  • 16 Mb?
    Mutasd a teljes hozzászólást!
abcd