## simdlen sometimes considered useful

General OpenMP discussion
TimM
Posts: 1
Joined: Fri Jun 17, 2016 2:15 am

### simdlen sometimes considered useful

Just a quick note re: the simdlen clause on OpenMP simd directives (as it's so rarely mentioned anywhere and one of the few instances is the brief locked thread http://openmp.org/forum/viewtopic.php?f=18&t=1865...).

Although it may not be obvious what use simdlen could be, I'd suggest that it can be useful where vectorisation changes numeric results, in that it can be used to control vectorisation and therefore limit numeric variance.

We have a strict need to maintain numeric consistency (this may not be a strict issue for many others I realise) - a given sum should return precisely the same result on all machines as far as possible.
For many cases arbitrary simd operation is fine

Code: Select all

``````#pragma omp simd
for(i=0;i<n;++i) y[i] = a*x[i] + y[i];
``````
as the value assigned to y for each index is unaffected by serial or vectored implementation.

But for some operations, vectorisation and unrolling will execute fp operations in a different order and therefore may produce different results

Code: Select all

``````#pragma omp simd
double xsum = 0.0;
for(i=0;i<n;++i)
xsum += x[i];
``````
With the simd clause this will not accumulate a single sum, but a number of partial sums, and then sum those items on completion (remembering that ((a+b)+c) does not always equal (a+(b+c)) under arbitrary precision f.p. maths).

Now while many people do not need to concern themselves with precise numeric consistency, we are forced to use options such as /fp:precise which will normally prevent the compiler unrolling such a loop.
It is not so much that 2-way or 4-way partial summing produces the wrong answer, but it may produce a different answer to serially summing a given array.

Hence previously we may have unrolled such loops by hand, but with simdlen we can tell the compiler the simdlen to use on whichever platform is available (eg the Intel C++ can generate optimised codepaths for SSE3, AVX, and AVX512 processors and do runtime dispatching), and thereby fix the order of the calculation and therefore the result on each platform.
If we specify simdlen(8), the compiler can generate code that on older platforms will use 4 128 bit registers, on newer platforms it uses 2 256 bit registers, and on the newest platforms it will use a single 512 bit register.
If we can then get these 8 partial sums then added in the same order on each code path (which may require the compiler writers to understand this sort of situation), then we know we will get the same final result regardless of the spec of the machine that actually performs the calculation.

It's not a case that will necessarily arise for a lot of people, but I'd be interested to know of any other solid use cases for simdlen (or other techniques people use to address this issue).

--
Tim
{"ft_lang_label":"__label__en","ft_lang_prob":0.8958421,"math_prob":0.9423751,"size":2207,"snap":"2020-34-2020-40","text_gpt3_token_len":491,"char_repetition_ratio":0.09895597,"word_repetition_ratio":0.01055409,"special_character_ratio":0.22066154,"punctuation_ratio":0.076744184,"nsfw_num_words":0,"has_unicode_error":false,"math_prob_llama3":0.97607464,"pos_list":[0],"im_url_duplicate_count":[null],"WARC_HEADER":"{\"WARC-Type\":\"response\",\"WARC-Date\":\"2020-09-18T16:59:50Z\",\"WARC-Record-ID\":\"<urn:uuid:36fb05ea-d228-41b8-9ae9-ba8bbfbc1995>\",\"Content-Length\":\"23935\",\"Content-Type\":\"application/http; msgtype=response\",\"WARC-Warcinfo-ID\":\"<urn:uuid:c41334b9-feff-4f43-95b5-37dc861d6753>\",\"WARC-Concurrent-To\":\"<urn:uuid:f93c3d12-7c59-452d-9e1e-de52a3c4537a>\",\"WARC-IP-Address\":\"159.203.82.159\",\"WARC-Target-URI\":\"https://forum.openmp.org/viewtopic.php?f=3&t=1936&p=7606\",\"WARC-Payload-Digest\":\"sha1:E42P2KXOROSSEB3RCXIXRZM3TP3Y7M7F\",\"WARC-Block-Digest\":\"sha1:E6DYXP3KBQHWWW2CAH2B356EZWMFOK5C\",\"WARC-Identified-Payload-Type\":\"text/html\",\"warc_filename\":\"/cc_download/warc_2020/CC-MAIN-2020-40/CC-MAIN-2020-40_segments_1600400188049.8_warc_CC-MAIN-20200918155203-20200918185203-00192.warc.gz\"}"}