Tiny Core Extensions > TCE Talk

Compiler flags and semi-portable extensions for "newer" pcs?

<< < (2/4) > >>

bmarkus:
qopit: Are you sure you need a 64-bit system?

Rich:
Hi qopit
Changing  -march  to a more recent processor will only provide a performance gain if the software running on it
makes use of faster instructions available on it. And then, the level of increased performance you get is a function
of what percentage of execution time is spent using those faster instructions. If an application spends most of its time
performing disk I/O and a small amount of time executing instructions that could be optimized, you won't see much
of a performance gain. All the above holds true for applications, libraries, and the kernel.

curaga:

--- Quote ---Is it that i486 provide some performance improvements over m32 (which seems to go back to support 386 instruction sets, per the docs), while also going back far enough to meet a minimum supportable hardware platform for Tiny Core?
--- End quote ---

It's both that, and that glibc also has 486 as the minimum. 386 did not have some atomic instructions, some swap instructions etc. 486 as a baseline also guarantees we run on about 99% of existing x86 hardware. Some eBoxes for example have only 486 capable cpus, despite being 1Ghz.


--- Quote ---For example, I want to make a custom python extension (or even just a portable dir for frugal installs) that I can move around my servers that has presumably better performance than would be obtained with -march=i486 and -mtune=i686, when I am certain that all the machines/CPUs I will be running it on are < 5 years old.
--- End quote ---

For custom builds, just do a survey around your hw and use the minimum set ;)
If all your hw is indeed <5 years old, and does not include Atoms, they all should be 64-bit capable. x64 requires sse2.

Therefore you could use "-march=pentium-m".


--- Quote ---On the core64 thing... is it that core64 enables the OS to support processes that total up to more than 4 GB of RAM, but "as-is" we can only have 32-bit applications due to there only being a support suite of 32-bit libraries easily available?
--- End quote ---

Yes.

@Rich:
Recent gcc is quite good in producing optimized code even when you don't explicitly use say SSE.

qopit:
bmarkus:
I'm sure I need a 64-bit system since processes will definitely chew up more than 4GB of memory in total at one time.  Upon further investigation/learning it seems I don't need 64-bit applications, though... as long as each process doesn't need to access more than 3GB of memory (which seems to be the userland default for linux... need to check core64, though).

For python, this means splitting tasks up with multiprocessing (or os.fork) vs threads to avoid total combined memory access > 3 GB (no single task will do it).  I'll also be using postgresql, but it is be fork-based and each process there shouldn't need more than 3 GB either.

So... it appears that 32-bit apps on a 64-bit core should be fine from a memory perspective.  Or at least so I understand so far :).  If I want to look at the trade-off between use of 64bit instructions and dragging 64-bit pointers everywhere, I'll have to do some benchmarking at some point.

Rich:
Thanks for the comments.  What you say makes perfect sense.  I have no idea what % of the time would be spent using the new/faster instruction sets, but I could be quite high beneficial or there isn't a massive point in beefing up instruction sets past what is available for a 80486.  eg: Why not drop down to i386?  The instruction set history shows that not much was added with the 486, at least from an integer instructions perspective.  My guess is that the integrated FPU in the 80486 may have something to do with it, but this guess only makes sense if  -march=i486 includes the i487 instruction set where -march=i386 doesn't include the i387 set... which may make sense since it wasn't integrated.  But then again, not all 486 chips had the FPU either.

If I'm right about -march=i486 being the "first" to provide FPU instructions, it is a clear minimum baseline to require, but has there been nothing beyond that that is of large enough benefit to bump the baseline?

In the end I'm sure I'll stick with the recommended/proven -march=i486 and -mtune=i686, but I figure the questions were worth asking.

At the very least, looking into this has made me have a better understanding of what the Gentoo crowd is about.  It also makes me wonder what the heck the larger distros (Debian, RHEL, or even Windows) do regarding instruction set usage for performance+portability of libs, or how much is abstracted out by the OS-provided libraries.

qopit:
Curaga: Awesome.  Thanks!  I read yours after starting/posting my reply #8... I should have edited it based on your post.

Navigation

[0] Message Index

[#] Next page

[*] Previous page