Index
> Linux > Vector libraries for C++ on FASM in x86-64 LinuxGoto page 1, 2 Next |
| Author |
|
|
jackblack 23 Aug 2012, 20:16
I have recently started a project of SIMD libraries development for C++ on FASM for x86-64 Linux.
I would be glad to hear any opinion or feedback about the project, cleanness of the code and documentation. Here is the project's web site on SourceForge. |
|||
23 Aug 2012, 20:16 |
|
|
typedef 24 Aug 2012, 09:51
Nice. Seems like the math library was your most favorite huh?
|
|||
|
24 Aug 2012, 09:51 |
|
|
jackblack 24 Aug 2012, 18:06
Not only the math. But the math lib is a right place for optimization. My libraries were developed mostly for data analysis, and for some fun for myself
 |
|||
|
24 Aug 2012, 18:06 |
|
|
typedef 24 Aug 2012, 21:51
They seem to fit too.
I like the ones that have to do with numbers. By the way did you think of a graphics library. You could use the same libraries (math, Angle, statistics) That would also be a nice way of showcasing what these libraries can do. But I guess that part is left out for some one else. ha ha |
|||
|
24 Aug 2012, 21:51 |
|
|
jackblack 25 Aug 2012, 10:32
>By the way did you think of a graphics library. You could use the same libraries (math, Angle, statistics)
It's a good idea, but it's already done by someone. Here is the project called libjpeg-turbo http://libjpeg-turbo.virtualgl.org/. It's now a part of Arch Linux release. So this job is already done. >That would also be a nice way of showcasing what these libraries can do. This is a good idea. Will think about it. |
|||
|
25 Aug 2012, 10:32 |
|
|
jackblack 25 Aug 2012, 10:35
>I myself started a similar library for a signal analyser project many years before but never went so far.
If you have any fresh ideas for my project, I will be glad for any kinds help. |
|||
|
25 Aug 2012, 10:35 |
|
|
jackblack 25 Aug 2012, 11:18
By the way. Here is a speed test of the Numbers conversion library.
Code: ################################################################################ # Numbers conversion library speed test # ################################################################################ This test converts 1000000 numbers in 100 rounds. Integer numbers conversion: =========================== Octal numbers conversion: 'sscanf' time: 36.097842 sec 'strtoul' time: 9.514678 sec 'LinAsm' time: 6.387945 sec Hexadecimal numbers conversion: 'sscanf' time: 34.354336 sec 'strtoul' time: 10.910184 sec 'LinAsm' time: 9.501984 sec Decimal numbers conversion: 'sscanf' time: 35.352888 sec 'strtoul' time: 9.828523 sec 'LinAsm' time: 7.790533 sec Floating-point numbers conversion: ================================== Hexadecimal numbers conversion: 'sscanf' time: 52.327102 sec 'strtod' time: 20.347512 sec 'LinAsm' time: 12.780951 sec Decimal numbers conversion: 'sscanf' time: 54.220025 sec 'strtod' time: 30.267146 sec 'LinAsm' time: 7.706974 sec Was very interesting to compare floating-point variants with "strtod" function from GNU C lib. LinAsm 2 and 3 times faster in this task. P.S. All tests were run on overclocked Pentium 4 |
|||
|
25 Aug 2012, 11:18 |
|
|
TmX 27 Aug 2012, 10:30
Very nice!
BTW, do you have plan to support 32-bit OSes, at least Linux... or Windows? |
|||
|
27 Aug 2012, 10:30 |
|
|
jackblack 28 Aug 2012, 13:54
No. It is not in my plans. 32 bit OS lose popularity from year to year. Now all CPUs are 64 bit. So many users install 64 bit OS on them. And 64 bit code is going to be dominant trend in software development. Why support platforms which will be legacy in few years?
But I think that it is a good idea to add support for C language besides C++, instead of 32-bit OS. So I added C prototypes to the libraries (release v0.97). They can be used now in both C and C++ programs. |
|||
|
28 Aug 2012, 13:54 |
|
|
randall 28 Aug 2012, 14:18
Windows 9 will be 64 bit only. There won't be 32 bit version. I am afraid fasm will not work there...
|
|||
|
28 Aug 2012, 14:18 |
|
|
f0dder 28 Aug 2012, 15:45
randall wrote: Windows 9 will be 64 bit only. There won't be 32 bit version. I am afraid fasm will not work there... And even if they don't do a 32bit version, I'd be very surprised if they didn't include WoW64. _________________  - carpe noctem |
|||
|
28 Aug 2012, 15:45 |
|
|
randall 28 Aug 2012, 16:11
"Microsoft is planning to drop their 32-bit flavor of Windows beginning with the next release, Windows 9. Microsoft has already shared that Windows 8 will be their last 32-bit release and then Windows 9 will only support "x64" when it comes to the x86 architecture."
From www.phoronix.com. |
|||
|
28 Aug 2012, 16:11 |
|
|
f0dder 28 Aug 2012, 16:23
You could have linked to the article in question (ugh, those phoronix URLs are horrible!) - which links to a mailing list post that links to some 3rd party article. Yeah, sure, there might be some official Microsoft statement somewhere, but the article certainly reads as hearsay. (And I'm too lazy to dig any deeper into this at the moment
).
It would make sense to drop the 32bit support, though... but this doesn't mean WoW64 would be dropped (even if that hearsay article implies it would). I expect we'll have 32bit legacy programs for a whole lot longer than we had 16bit legacy... most software works just fine as 32bit, and aren't going to benefit (heck, might even be ever so slightly penalized) from 64bit ports. There might be a remote possibility of WoW64 being ripped out and delegated to "XP Mode", but that would be rather whacky. |
|||
|
28 Aug 2012, 16:23 |
|
|
jackblack 28 Aug 2012, 21:00
Anyway 32 bit platforms become less and less popular either with WOW64 or native support. LinAsm won't support them because a tons of patches should be applied to the code. And we a trying to catch a train which is already gone and won't come back again.
|
|||
|
28 Aug 2012, 21:00 |
|
|
jackblack 29 Aug 2012, 20:23
For people, who would like to see the library speed, I made a simple performance testing page with graphics. I compare LinAsm algorithms with their GNU libc analogs.
Here is the link to LinAsm performance tests. http://linasm.sourceforge.net/about/performance.php |
|||
|
29 Aug 2012, 20:23 |
|
|
r22 30 Aug 2012, 19:23
@jackblack - nice work. Taking the time to implement and test all those functions is an admirable feat.
I'm a big fan of radix sort http://board.flatassembler.net/topic.php?t=5081 http://stackoverflow.com/questions/8082425/fastest-way-to-sort-32bit-signed-integer-arrays-in-javascript You should use ALIGN for your functions and NOP padding for your loop labels. This will give you a noticeable speed boost. Code: align 16 Function_Name: ... Code:
...
AMDPad16
.loop_label:
...
jmp .loop_label
AMDPad16 is a macro I made that used the optimal combination and pattern of NOP opcodes. http://board.flatassembler.net/topic.php?t=4445 edit: Proper code alignment is the lowest of low hanging fruit for assembly level optimization. |
|||
|
30 Aug 2012, 19:23 |
|
|
jackblack 30 Aug 2012, 19:53
Good idea. I will try it and compare the results. Have you any ideas what performance improvement it can give? Just wonder.
|
|||
|
30 Aug 2012, 19:53 |
|
|
r22 31 Aug 2012, 15:49
5-10% depending on the processor.
|
|||
|
31 Aug 2012, 15:49 |
|
|
jackblack 02 Sep 2012, 18:38
Hi, r22
I made some testing with unaligned and aligned code Seems this is not so actual for modern CPUs. And they operate with the same speed in both situations. 'LinAsm' time (aligned code): 7.056060 sec 'LinAsm' time (unaligned code): 7.050908 sec Looks like the speed overhead of aligned code can be reached for much older CPU: PIII, Pentium MMX, and so on. I used Pentium 4 NetBurst overclocked to 3.7 Ghz for the testing. |
|||
|
02 Sep 2012, 18:38 |
|
| Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|