4 ms·

This is a tad tangential but has anyone done extensive software development using an ARM device? I was able to get pretty far with a rooted Samsung tablet runn

by Youden 7y ago

This is a tad tangential but has anyone done extensive software development using an ARM device? I was able to get pretty far with a rooted Samsung tablet running Debian in a container (C++ development works great, you can install stuff like VSCode and Clang without too much trouble) but when it came to anything mobile, ironically it all fell apart because the Android toolchain isn't built for ARM64 (save the one in the Debian repositories, which is too old). I even tried to update the package myself but apparently Debian copies all the code into its own repositories and doesn't make clear how to update it. The Pinebook Pro, having the same CPU architecture, should have the same problems, at least for now. I'm very interested in seeing them solved though.

hajile 7y ago
I've done some web development work on my raspberry pi 4. It's almost there, but even using vim, some things are still too slow (I do primarily front-end development). 4gb of RAM means I can't have a ton of things going on, but it's easily enough for back-end, webpack, editor, and a handful of tabs without much issue. Now, there are some CPU differences here. 3399 has 2 A72 cores at 2GHz and 4 A53 cores at 1.5GHz. The pi 4 can be overclocked to 1.8-2GHz pretty easily which makes it about as fast. I believe the Pi 4 GPU is slower, but it's mostly not relevant for dev work. When Ubuntu finishes working out the bugs with their 64-bit OS, it should offer another big speedup. That is probably enough to boost JS performance (and general system performance) high enough to not feel especially painful.
- tsukurimashou 7y ago
  stock vim or do you use plugins?
  - hajile 7y ago
    I use a few plugins to make web development a better experience. Nothing particularly exceptional. Syntax highlighting, nerdtree, ctr-p, linter, prettier, bracket highlighter, etc.
    - tsukurimashou 7y ago
      I would suggest to try with / without plugins, it can make a big difference on ARM. If it feels alright when you don't have any plugin, then try to see which is / are causing the slow downs. Vim shouldn't be slow without any plugin.
- floatboth 7y ago
  I would take 4xA72 over 2xA72+4xA53 any time. Heterogeneous systems are annoying. Linux probably has some fancy scheduler settings to prefer fast cores (??) but FreeBSD will happily schedule compile jobs onto the slow-ass A53 cores when the A72s are idle, which is annoying. UPD: NetBSD prefers fast cores now: https://twitter.com/mrgtwentythree/status/1216619886937403392 https://twitter.com/mrgtwentythree/status/121661988693740339... 4xA72@2GHz is not bad for web development (I have that on my MACCHIATObin), the thing with the RPi4 is that it has worse RAM and I/O. SD cards are garbage and you really only have USB3 to share between everything else. Having native SATA makes everything better :)
  - hajile 7y ago
    There is only 1 PCIe lane and it goes to the USB3 controller. Running from a SSD on USB3 isn't that bad, but they still haven't made default booting from USB possible yet. I don't think RAM is an issue though. Performance seems to scale pretty much linearly with clockspeed improvements which indicates either the RAM timing is tied to the clockspeeds (seems unlikely) so bandwidth is increasing or it already has more than it can use. That said, rk3399 designs tend to get about 20% better performance (or around 1gb/s) on synthetics. I'm surprised better IO doesn't exist on the chip if Broadcomm planned on selling it to other customers. I don't think a single SATA port would greatly increase costs, but would have a huge impact on performance. As a final thought, they really need to consider mounting the RAM and CPU on the other side of the PCB. That would allow good cooling solutions that don't compromise the other board functionality.
btreecat 7y ago
I think for now the best solution is to use this as a mobile terminal for a machine that is running an x86/64 chip then just remote in either via SSH or x2go.
floatboth 7y ago
I use a MACCHIATObin (Marvell Armada8k - 4xCA72@2GHz) as a second desktop. I don't do mobile, but for what I do — C (FreeBSD kernel), Rust, Elixir, D, GTK, web frontend with Firefox — everything is fine. Also I usually develop my website's backend (Elixir) directly on the EC2 a1 instance it runs on :)
zozbot234 7y ago
> but apparently Debian copies all the code into its own repositories and doesn't make clear how to update it. Debian always keeps the maintainer's patches separate from the "clean" upstream code. I'm not saying that it can't sometimes be hard to do major updates but please don't blame the Debian folks for that, it's not cool.
- Youden 7y ago
  I'm sure Debian has reasons for doing it that way but the undeniable consequence is that they made a decision that resulted in more complicated package updates. I'm used to Arch Linux where, for the most part, you can just download a PKGBUILD, increment the version number and you're done. Have a look at Arch [0] vs. Debian [1]. Arch's package specification just tells the build tools where to get the code and how to build it. Debian's includes all the code so the repository has to be updated first (which I tried, resulting in merge conflicts). Perhaps this approach has advantages (like not relying on the third party code hosting) but it also comes with disadvantages. I have no ill feelings towards the Debian project or its contributors but they are responsible for the choice that led to the issue I have, so I feel it's entirely reasonable to "blame" them (I don't feel that's the right word, they just made a tradeoff that is inconvenient to me but might make sense to them). [0]: https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/android-tools https://git.archlinux.org/svntogit/community.git/tree/trunk/... [1]: https://salsa.debian.org/android-tools-team/android-platform-build https://salsa.debian.org/android-tools-team/android-platform...
  - _-___________-_ 7y ago
    I've generally found Arch to be an excellent distribution for development. It's years since I used Debian but by comparison it used to be a world of pain. Arch runs well on ARM devices; why not try that on the Samsung?
  - zozbot234 7y ago
    You get merge conflicts because you're relying on debian patches. You can just download a clean package from upstream, compile it and create a binary .deb for local use via Debian's packaging tools.

by Youden 7y ago

hajile 7y ago

I've done some web development work on my raspberry pi 4. It's almost there, but even using vim, some things are still too slow (I do primarily front-end development). 4gb of RAM means I can't have a ton of things going on, but it's easily enough for back-end, webpack, editor, and a handful of tabs without much issue. Now, there are some CPU differences here. 3399 has 2 A72 cores at 2GHz and 4 A53 cores at 1.5GHz. The pi 4 can be overclocked to 1.8-2GHz pretty easily which makes it about as fast. I believe the Pi 4 GPU is slower, but it's mostly not relevant for dev work. When Ubuntu finishes working out the bugs with their 64-bit OS, it should offer another big speedup. That is probably enough to boost JS performance (and general system performance) high enough to not feel especially painful.

tsukurimashou 7y ago
stock vim or do you use plugins?
- hajile 7y ago
  I use a few plugins to make web development a better experience. Nothing particularly exceptional. Syntax highlighting, nerdtree, ctr-p, linter, prettier, bracket highlighter, etc.
  - tsukurimashou 7y ago
    I would suggest to try with / without plugins, it can make a big difference on ARM. If it feels alright when you don't have any plugin, then try to see which is / are causing the slow downs. Vim shouldn't be slow without any plugin.
floatboth 7y ago
I would take 4xA72 over 2xA72+4xA53 any time. Heterogeneous systems are annoying. Linux probably has some fancy scheduler settings to prefer fast cores (??) but FreeBSD will happily schedule compile jobs onto the slow-ass A53 cores when the A72s are idle, which is annoying. UPD: NetBSD prefers fast cores now: https://twitter.com/mrgtwentythree/status/1216619886937403392 https://twitter.com/mrgtwentythree/status/121661988693740339... 4xA72@2GHz is not bad for web development (I have that on my MACCHIATObin), the thing with the RPi4 is that it has worse RAM and I/O. SD cards are garbage and you really only have USB3 to share between everything else. Having native SATA makes everything better :)
- hajile 7y ago
  There is only 1 PCIe lane and it goes to the USB3 controller. Running from a SSD on USB3 isn't that bad, but they still haven't made default booting from USB possible yet. I don't think RAM is an issue though. Performance seems to scale pretty much linearly with clockspeed improvements which indicates either the RAM timing is tied to the clockspeeds (seems unlikely) so bandwidth is increasing or it already has more than it can use. That said, rk3399 designs tend to get about 20% better performance (or around 1gb/s) on synthetics. I'm surprised better IO doesn't exist on the chip if Broadcomm planned on selling it to other customers. I don't think a single SATA port would greatly increase costs, but would have a huge impact on performance. As a final thought, they really need to consider mounting the RAM and CPU on the other side of the PCB. That would allow good cooling solutions that don't compromise the other board functionality.

btreecat 7y ago

I think for now the best solution is to use this as a mobile terminal for a machine that is running an x86/64 chip then just remote in either via SSH or x2go.

floatboth 7y ago

I use a MACCHIATObin (Marvell Armada8k - 4xCA72@2GHz) as a second desktop. I don't do mobile, but for what I do — C (FreeBSD kernel), Rust, Elixir, D, GTK, web frontend with Firefox — everything is fine. Also I usually develop my website's backend (Elixir) directly on the EC2 a1 instance it runs on :)

zozbot234 7y ago

> but apparently Debian copies all the code into its own repositories and doesn't make clear how to update it. Debian always keeps the maintainer's patches separate from the "clean" upstream code. I'm not saying that it can't sometimes be hard to do major updates but please don't blame the Debian folks for that, it's not cool.

Youden 7y ago
I'm sure Debian has reasons for doing it that way but the undeniable consequence is that they made a decision that resulted in more complicated package updates. I'm used to Arch Linux where, for the most part, you can just download a PKGBUILD, increment the version number and you're done. Have a look at Arch [0] vs. Debian [1]. Arch's package specification just tells the build tools where to get the code and how to build it. Debian's includes all the code so the repository has to be updated first (which I tried, resulting in merge conflicts). Perhaps this approach has advantages (like not relying on the third party code hosting) but it also comes with disadvantages. I have no ill feelings towards the Debian project or its contributors but they are responsible for the choice that led to the issue I have, so I feel it's entirely reasonable to "blame" them (I don't feel that's the right word, they just made a tradeoff that is inconvenient to me but might make sense to them). [0]: https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/android-tools https://git.archlinux.org/svntogit/community.git/tree/trunk/... [1]: https://salsa.debian.org/android-tools-team/android-platform-build https://salsa.debian.org/android-tools-team/android-platform...
- _-___________-_ 7y ago
  I've generally found Arch to be an excellent distribution for development. It's years since I used Debian but by comparison it used to be a world of pain. Arch runs well on ARM devices; why not try that on the Samsung?
- zozbot234 7y ago
  You get merge conflicts because you're relying on debian patches. You can just download a clean package from upstream, compile it and create a binary .deb for local use via Debian's packaging tools.