[HN Gopher] Overview of cross-architecture portability problems
___________________________________________________________________
Overview of cross-architecture portability problems
Author : todsacerdoti
Score : 69 points
Date : 2024-09-23 10:34 UTC (12 hours ago)
(HTM) web link (blogs.gentoo.org)
(TXT) w3m dump (blogs.gentoo.org)
| hanikesn wrote:
| Looks like non 4k page sizes are missing, which tripped out some
| software running on asahi Linux.
| saagarjha wrote:
| Most software doesn't really care. This list only has common
| issues (though the issues it goes over seem more like problems
| from 2010...)
| denotational wrote:
| Missed my favourite one: differences in the memory consistency
| model.
|
| If you're using stdatomic and the like _correctly_ , then the
| library and compiler writers have your back, but if you aren't
| (e.g. using relaxed ordering when acquire/release is required),
| or if you're rolling your own synchronisation primitives (don't
| do this unless you know what you're doing!), then you're going to
| have a bad day.
| Archit3ch wrote:
| The fun of discovering size_t is defined differently on Apple
| Silicon.
| saagarjha wrote:
| Differently from what?
| johnklos wrote:
| One of the larger problems is purely social. Some people
| unnecessarily resist the idea that code can run on something
| other than x86 (and perhaps now Arm).
|
| Interestingly, some apologists say that maintaining portability
| in code is a hinderance that costs time and money, as though the
| profit of a company or the productivity of a programmer will be
| dramatically affected if they need to program without making
| assumptions about the underlying architecture. In reality,
| writing without those assumptions usually makes code better, with
| fewer edge cases.
|
| It'd be nice if people wouldn't go out of their way to fight
| against portability, but some people do :(
| rqtwteye wrote:
| I am for portability but if you decide to go that route, you
| need to do a ton of testing on different platforms to make sure
| it really works. That definitely costs time and effort. There
| are a lot of ways to do it wrong.
| gwbas1c wrote:
| I argue the opposite: It's important to know the _purpose_ of
| the program, including _the computer that the program will run
| on._
|
| I can understand polite disagreements about target
| architectures: You might write a windows desktop program and
| disagree with someone if you should support 32-bit or be 64-bit
| only.
|
| BUT: Outside of x64 and ARM, your program (Windows Desktop) is
| highly unlikely to run on any other instruction set.
|
| The reality is that it's very time consuming and labor-intense
| to ship correctly-working software. Choosing and limiting your
| target architecture is an important part of that decision.
| Either you increase development cost/time (and risk not getting
| a return on your investment,) or you ship something buggy and
| risk your reputation / support costs.
| TZubiri wrote:
| Also, develop on your target architecture. I see too many
| people trying to use their arm macs to develop locally. Just
| ssh into an x86 thing
| magicalhippo wrote:
| One I recall, working on a C++ program that we distributed to
| Windows, Linux and PowerPC OSX at the time, was how some
| platforms had memory zero-initialized by the OS memory manager,
| and some didn't.
|
| Our code didn't mean to take advantage of this, but it sometimes
| meant buggy code would appear fine on one platform as pointers in
| structures would be zeroed out, but crash on others where they
| weren't.
|
| As I recall, it was mostly that and the endianess that caused the
| most grief. Not that there was many issues at all since we used
| Qt and Boost...
___________________________________________________________________
(page generated 2024-09-23 23:00 UTC)