The same can be said about the windows intel gpu app, there is a reason why I stopped running the igpu, and that was because of abysmal driver support. As such I believe the reason is due to the marketing flops that jason was saying earlier

The same can be said about the windows intel gpu app, there is a reason why I stopped running the igpu, and that was because of abysmal driver support. As such I believe the reason is due to the marketing flops that jason was saying earlier

Interesting. I know that support to the Khronos Group by AMD and nVidia is very high (naturally with their own vested interests). Strange that possibly the wealthiest of contributors has the least support for their own products.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

...One of the GPU compilation steps is under our control - the ordinary C-code compiler. My suspicion is that something went wrong with the stock Mac CPU app at this stage - a compiler option set for speed instead of accuracy, perhaps. If we could contact whoever compiled that app in the first place, it could be fixed...

The same OpenCL App works fine with the Older version of OSX. Even the OpenCL AstroPulse App is affected by the newer OS. I don't think that was caused by a compiler option. It's the Same App. Most likely the newer OS has a slightly different implementation of OpenCL. I believe Raistmer is aware of this. The objective should be to find what changed between Darwin 14.5 and 15.0 so adjustments can be made. The problem with the Intel iGPUs is probably due to Intel favoring Apple's OpenCL implementation so their iGPUs work well with the Apple driver. Hence, when the code doesn't work well with the Apple OpenCL it also doesn't work well with the Intel OpenCL.
That's my assessment anyway.

The same can be said about the windows intel gpu app, there is a reason why I stopped running the igpu, and that was because of abysmal driver support. As such I believe the reason is due to the marketing flops that jason was saying earlier

Interesting. I know that support to the Khronos Group by AMD and nVidia is very high (naturally with their own vested interests). Strange that possibly the wealthiest of contributors has the least support for their own products.

The stupid thing is that the Windows intel_gpu drivers started out well (the ones I'm using date from 2014) and have gone downhill since then. Assuming (and it's still an assumption, though I think the evidence is strong) that the incompatibility between application and driver lies at the driver end, that does suggest that the development push is coming from display acceleration (where Intel seem to have gained a greater market share recently, in business machines if not in gaming), and their eye has been taken off the 'general purpose computing' aspect of GPUs.

...One of the GPU compilation steps is under our control - the ordinary C-code compiler. My suspicion is that something went wrong with the stock Mac CPU app at this stage - a compiler option set for speed instead of accuracy, perhaps. If we could contact whoever compiled that app in the first place, it could be fixed...

The same OpenCL App works fine with the Older version of OSX. Even the OpenCL AstroPulse App is affected by the newer OS. I don't think that was caused by a compiler option. It's the Same App. Most likely the newer OS has a slightly different implementation of OpenCL. I believe Raistmer is aware of this. The objective should be to find what changed between Darwin 14.5 and 15.0 so adjustments can be made. The problem with the Intel iGPUs is probably due to Intel favoring Apple's OpenCL implementation so their iGPUs work well with the Apple driver. Hence, when the code doesn't work well with the Apple OpenCL it also doesn't work well with the Intel OpenCL.
That's my assessment anyway.

A lot changed in both Linux and Mac infrastructure to support NVME, that in the Windows world was switched to circa 2005. Not saying that m$ is fantastic or some kindof prophet, though wouldn't hurt Linux or Mac to look forward more than they do.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

The same can be said about the windows intel gpu app, there is a reason why I stopped running the igpu, and that was because of abysmal driver support. As such I believe the reason is due to the marketing flops that jason was saying earlier

Interesting. I know that support to the Khronos Group by AMD and nVidia is very high (naturally with their own vested interests). Strange that possibly the wealthiest of contributors has the least support for their own products.

The stupid thing is that the Windows intel_gpu drivers started out well (the ones I'm using date from 2014) and have gone downhill since then. Assuming (and it's still an assumption, though I think the evidence is strong) that the incompatibility between application and driver lies at the driver end, that does suggest that the development push is coming from display acceleration (where Intel seem to have gained a greater market share recently, in business machines if not in gaming), and their eye has been taken off the 'general purpose computing' aspect of GPUs.

It's pretty much the pattern ongoing with all those big companies contracting. Investing in the future becomes secondary to survival when your job is on the line. Not many of us have the luxury of looking 10-20 years forward.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

... Assuming (and it's still an assumption, though I think the evidence is strong) that the incompatibility between application and driver lies at the driver end,

For that end, you can take that assumption pretty much as Gospel, since nVidia have publicly stated that no game (AAA or otherwise) is bug free, in that the developers routinely ignore proper API usage and most updated drivers are about installing workarounds. Down with hipster pretend programmers.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

...One of the GPU compilation steps is under our control - the ordinary C-code compiler. My suspicion is that something went wrong with the stock Mac CPU app at this stage - a compiler option set for speed instead of accuracy, perhaps. If we could contact whoever compiled that app in the first place, it could be fixed...

The same OpenCL App works fine with the Older version of OSX. Even the OpenCL AstroPulse App is affected by the newer OS. I don't think that was caused by a compiler option. It's the Same App. Most likely the newer OS has a slightly different implementation of OpenCL. I believe Raistmer is aware of this. The objective should be to find what changed between Darwin 14.5 and 15.0 so adjustments can be made. The problem with the Intel iGPUs is probably due to Intel favoring Apple's OpenCL implementation so their iGPUs work well with the Apple driver. Hence, when the code doesn't work well with the Apple OpenCL it also doesn't work well with the Intel OpenCL.
That's my assessment anyway.

A lot changed in both Linux and Mac infrastructure to support NVME, that in the Windows world was switched to circa 2005. Not saying that m$ is fantastic or some kindof prophet, though wouldn't hurt Linux or Mac to look forward more than they do.

I'm not a Windows expert, but the last time I checked Windows doesn't have a built-in version of OpenCL the way Apple does. Windows relies on drivers from AMD, nVidia, and Intel. As long as those drivers don't change much the existing Code will still work reasonably well. Since Windows doesn't appear to be very involved in OpenCL the way Apple is, they probably don't change much. When certain people are actively involved in developing the technology changes do occur. It's up to the developers to be aware of those changes and respond accordingly. SETI is not the only game in town. I don't get out much anymore, however, I'm not aware of other people having trouble with Apple or Intel's OpenCL. I'm sure there are a few, and they probably make the necessary changes...eventually.

The reason CUDA still works in OSX is because the Drivers come from nVidia, and nVidia has a vested interest in keeping their hardware working and code the drivers to work in newer versions of OSX. That's why you see new nVidia CUDA and Video driver with every new version of OSX.

...One of the GPU compilation steps is under our control - the ordinary C-code compiler. My suspicion is that something went wrong with the stock Mac CPU app at this stage - a compiler option set for speed instead of accuracy, perhaps. If we could contact whoever compiled that app in the first place, it could be fixed...

The same OpenCL App works fine with the Older version of OSX. Even the OpenCL AstroPulse App is affected by the newer OS. I don't think that was caused by a compiler option. It's the Same App. Most likely the newer OS has a slightly different implementation of OpenCL. I believe Raistmer is aware of this. The objective should be to find what changed between Darwin 14.5 and 15.0 so adjustments can be made. The problem with the Intel iGPUs is probably due to Intel favoring Apple's OpenCL implementation so their iGPUs work well with the Apple driver. Hence, when the code doesn't work well with the Apple OpenCL it also doesn't work well with the Intel OpenCL.
That's my assessment anyway.

A lot changed in both Linux and Mac infrastructure to support NVME, that in the Windows world was switched to circa 2005. Not saying that m$ is fantastic or some kindof prophet, though wouldn't hurt Linux or Mac to look forward more than they do.

I'm not a Windows expert, but the last time I checked Windows doesn't have a built-in version of OpenCL the way Apple does. Windows relies on drivers from AMD, nVidia, and Intel. As long as those drivers don't change much the existing Code will still work reasonably well. Since Windows doesn't appear to be very involved in OpenCL the way Apple is, they probably don't change much. When certain people are actively involved in developing the technology changes do occur. It's up to the developers to be aware of those changes and respond accordingly. SETI is not the only game in town. I don't get out much anymore, however, I'm not aware of other people having trouble with Apple or Intel's OpenCL. I'm sure there are a few, and they probably make the necessary changes...eventually.

The reason CUDA still works in OSX is because the Drivers come from nVidia, and nVidia has a vested interest in keeping their hardware working and code them to work in newer versions of OSX.

All true, though you need the bigger picture for context. m$ gurus foresaw our current situation, in that single core performance is running into limits. Now you have a situation where Windows already has multithreaded drivers, Runtime libraries, and programmers familiar with thread safety. On the other hand you have snotty Linux and Mac developers not able to use max bandwidth, because conspiracy. See ?

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

*snicker*
I have a PowerMac from 2003 that has dual CPUs.
Dual CPUs appeared in Macs long ago, they must have seen something ya think ;-)

*snicker*
I have a PowerMac from 2003 that has dual CPUs.
Dual CPUs appeared in Macs long ago, they must have seen something ya think ;-)

exactly.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

...When certain people are actively involved in developing the technology changes do occur. It's up to the developers to be aware of those changes and respond accordingly. SETI is not the only game in town. I don't get out much anymore, however, I'm not aware of other people having trouble with Apple or Intel's OpenCL. I'm sure there are a few, and they probably make the necessary changes...eventually.

Found one. Apparently even the big boys got zapped by the OpenCL in El Capitan;

Hey Simone, this is probably a known issue with OpenCL processing....On Macbook Pro after updating to el Capitan in system preferences I found a tab, called CUDA. opened it. Updated CUDA driver . Switched the project to CUDA rendering and everything works fine now!)

...Even Apple has warned of using FCPX with 10.11 at this point, it’s simply too early....
https://blogs.adobe.com/creativecloud/premiere-pro-cc-and-mac-os-x-10-11-el-capitan/

I keep hearing about this Metal thing as well. Definitely big changes to OpenCL in El Capitan.

BTW, remember this post?

I looked a little deeper on the LapTops and it seems some of them started having trouble around Mavericks. Then a few more models started have much longer times with Yosemite. Now with El Capitan it appears the GT 640M, 650M, 660M, 750M, and 755M are all giving much longer runtimes and many inconclusives with OpenCL. My guess would be an OS/OpenCL conflict. Might be a good time for a couple CUDA Apps at Beta...
« Last Edit: February 03, 2016, 12:22:57 by TBar »
http://www.arkayn.us/forum/index.php?topic=192.msg4484#msg4484

Yes, it's been going on for quite some time.

So, after seemingly thorough discussion what iGPU plan class limits for Mac should be?

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

Hi,

Here's one pulse I'm missing:

<pulse>
  <peak_power>3.7004590034485</peak_power>
  <mean_power>0.12950158119202</mean_power>
  <time>2457452.3013487</time>
  <ra>23.841133333333</ra>
  <decl>32.3532</decl>
  <q_pix>0</q_pix>
  <freq>1230904961.0049</freq>
  <detection_freq>1230905150.8841</detection_freq>
  <barycentric_freq>0</barycentric_freq>
  <fft_len>2048</fft_len>
  <chirp_rate>4.13657984209</chirp_rate>
  <rfi_checked>0</rfi_checked>
  <rfi_found>0</rfi_found>
  <reserved>0</reserved>
  <period>8.9702181546667</period>
  <snr>11.701878547668</snr>
  <thresh>11.584579467773</thresh>
  <score>0</score>
  <len_prof>50</len_prof>
  <pot length=165 encoding="x-csv">
    13,20,10,19,45,0,22,37,37,14,54,16,42,47,11,26,26,52,29,16,45,36,34,254,
    20,88,46,19,33,26,23,30,25,48,43,38,65,34,38,1,2,48,39,52,16,66,34,12,
    58,60
  </pot>
</pulse>

To save time I do not want to invent the wheel again. So, how to translate the result file output to those values that are meaningful to the programmer and visible in the pulse find kernels? PoT, p, di?

I know that fft_len is trivial. Chirp rate can be passed in pulse find settings if not already done, but the other values?

I need this information to reduce the range of kernels doing printf...

---

To overcome Heisenbergs:
"You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones

I know this is about GBT data, but I was having a read through and have saved the below Arecibo one if anyone wants it. All 3 validated after I finished and uploaded. Stock CUDA 5 (GTX970) vs Apple Darwin iGPU (Intel(R) Core(TM) i5-4278U CPU @ 2.60GHz- Number of processors 4 - INTEL Iris (1536MB) OpenCL: 1.2) was inconclusive before it was sent to me and i ran it with SOG.

Workunit 2249145377

Workunit

Result File From My Computer

Also, if you want these too, the STDERR from both the original people who processed them are below also, in case you come too late to the thread.

Apple STDERR

Cuda 5 STDERR

---

To save time I do not want to invent the wheel again. So, how to translate the result file output to those values that are meaningful to the programmer and visible in the pulse find kernels? PoT, p, di?

I know that fft_len is trivial. Chirp rate can be passed in pulse find settings if not already done, but the other values?

I need this information to reduce the range of kernels doing printf...

Digging into the cudaAcc_ReportPulseEvent(...) call, through to the CPU ReportPulseEvent(...) I found helpful.

It links res1.x, y and z to the corresponding peak, mean etc.

To ease debugging/refinement I wouldn't mind if we changed the types from vanilla float4, to similar unions with more meaningful names. Backtracking further into the cuda Kernels does provide some insight as to which offsets/indexes & calculated fields end up where, although it's not very clean. Some thorough refactoring for x42 will probably make that easier.

quite a few of those fields are calculated as the pulse is recorded CPU side, so won't directly link back to the pulse result table fields.

In the case of p, di etc, there are some integer rounding gymnastics going on, so as to yield PoT bin positions and range, with each fold by 2. Ultimately I've managed to visualise the pulse folding process *once* clearly, then the picture sadly faded. I do recall, however, that the visualisation involved successive peak refinement, and that I may still have some diagrams stashed away, illustating the indexes, somewhere that I'll have to locate (but not sure where at the moment.)

We'd probably need that if we want to try out a wavelet prescan, or other techniqes, so as to translate the offsets/periods to feed a focused/reduced normal pulsefind run for the final numbers.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Hi,

Here's one pulse I'm missing:

<pulse>
  <peak_power>3.7004590034485</peak_power>
  <mean_power>0.12950158119202</mean_power>
  <time>2457452.3013487</time>
  <ra>23.841133333333</ra>
  <decl>32.3532</decl>
  <q_pix>0</q_pix>
  <freq>1230904961.0049</freq>
  <detection_freq>1230905150.8841</detection_freq>
  <barycentric_freq>0</barycentric_freq>
  <fft_len>2048</fft_len>
  <chirp_rate>4.13657984209</chirp_rate>
  <rfi_checked>0</rfi_checked>
  <rfi_found>0</rfi_found>
  <reserved>0</reserved>
  <period>8.9702181546667</period>
  <snr>11.701878547668</snr>
  <thresh>11.584579467773</thresh>
  <score>0</score>
  <len_prof>50</len_prof>
  <pot length=165 encoding="x-csv">
    13,20,10,19,45,0,22,37,37,14,54,16,42,47,11,26,26,52,29,16,45,36,34,254,
    20,88,46,19,33,26,23,30,25,48,43,38,65,34,38,1,2,48,39,52,16,66,34,12,
    58,60
  </pot>
</pulse>

To save time I do not want to invent the wheel again. So, how to translate the result file output to those values that are meaningful to the programmer and visible in the pulse find kernels? PoT, p, di?

I know that fft_len is trivial. Chirp rate can be passed in pulse find settings if not already done, but the other values?

I need this information to reduce the range of kernels doing printf...

PulseFind checks for power field mostly. It should be above threshold.
I'll look for more precise formula.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

That's how pulse detection looks in one of my Pulsefind kernels:

			if (tmp_max.x>dis_thresh.x || tmp_max.y>dis_thresh.y ||
				tmp_max.z>dis_thresh.z || tmp_max.w>dis_thresh.w) {
				// unscale for reporting
				tmp_max /= (float4)num_adds;
				cur_thresh = (dis_thresh / (float4)num_adds - avg) * rcfg_dis_thresh + avg;

				float4 _snr = (tmp_max-avg)/(cur_thresh-avg);
				if (_snr.x  > best_pulse_score ||
					_snr.y  > best_pulse_score ||
					_snr.z  > best_pulse_score ||
					_snr.w  > best_pulse_score ) {
					need_cpu_reprocess = 1;
				}
				if( (tmp_max.x>cur_thresh.x) ||
					(tmp_max.y>cur_thresh.y) ||
					(tmp_max.z>cur_thresh.z) ||
					(tmp_max.w>cur_thresh.w) ) {
					need_cpu_reprocess = 1;//return;
				}
			}

I kept same variable names where possible so direct comparison with CUDA kernel should be possible.

need_cpu_reprocess=1 means pulse detected.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

I've run a few tests with some Mac OpenCL Apps. First in Darwin 15.4, which for some reason failed to compile a GPU OpenCL App that would run in standalone. I did test a few Apps with the reference_work_unit_r3215.wu.
Basically the the CUDA Apps came in at Strongly similar 99.80% with the CPU App r3344. The App now at Beta gave the best score;

KWSN-Darwin-MBbench v2.1.07
Running on TomsMacPro.local at Tue Aug 30 05:36:14 2016
---------------------------------------------------
Starting benchmark run...
---------------------------------------------------
Listing wu-file(s) in /testWUs :
reference_work_unit_r3215.wu

Listing executable(s) in /APPS :
setiathome_8.11_x86_64-apple-darwin__cuda75_mac

Listing executable in /REF_APPs :
MBv8_8.05r3344_sse41_x86_64-apple-darwin
---------------------------------------------------
Current WU: reference_work_unit_r3215.wu
---------------------------------------------------
Running default app with command : MBv8_8.05r3344_sse41_x86_64-apple-darwin
Elapsed Time: ………………………………… 2104 seconds

---------------------------------------------------
Running app with command : setiathome_8.11_x86_64-apple-darwin__cuda75_mac
Elapsed Time : ……………………………… 561 seconds
Speed compared to default : 375 %
-----------------
Comparing results
Result      : Strongly similar,  Q= 99.82%
---------------------------------------------------

The OpenCL Apps scored much worse in Darwin 15.4 even though these Apps worked very well in Darwin 14.5.

KWSN-Darwin-MBbench v2.1.07
Running on TomsMacPro.local at Tue Aug 30 07:31:46 2016
---------------------------------------------------
Starting benchmark run...
---------------------------------------------------
Listing wu-file(s) in /testWUs :
reference_work_unit_r3215.wu

Listing executable(s) in /APPS :
MBv8_8.05r3346_nvidia_ssse3_x86_64-apple-darwin

Listing executable in /REF_APPs :
MBv8_8.05r3344_sse41_x86_64-apple-darwin
---------------------------------------------------
Current WU: reference_work_unit_r3215.wu
---------------------------------------------------
Skipping default app MBv8_8.05r3344_sse41_x86_64-apple-darwin, displaying saved result(s)
Elapsed Time: ………………………………… 2104 seconds
---------------------------------------------------
Running app with command : MBv8_8.05r3346_nvidia_ssse3_x86_64-apple-darwin
Elapsed Time : ……………………………… 480 seconds
Speed compared to default : 438 %
-----------------
Comparing results
                ------------- R1:R2 ------------     ------------- R2:R1 ------------
                Exact  Super  Tight  Good    Bad     Exact  Super  Tight  Good    Bad
        Spike      0      9     11     13      0        0      9     11     13      0
     Autocorr      0      1      1      1      0        0      1      1      1      0
     Gaussian      0      0      0      1      5        0      0      0      1      5
        Pulse      0      0      0      0      0        0      0      0      0      2
      Triplet      0      1      1      2      0        0      1      1      2      1
   Best Spike      0      1      1      1      0        0      1      1      1      0
Best Autocorr      0      1      1      1      0        0      1      1      1      0
Best Gaussian      0      0      0      0      1        0      0      0      0      1
   Best Pulse      0      0      0      0      1        0      0      0      0      1
 Best Triplet      0      1      1      1      0        0      1      1      1      0
                ----   ----   ----   ----   ----     ----   ----   ----   ----   ----
                   0     14     16     20      7        0     14     16     20     10

Unmatched signal(s) in R1 at line(s) 499 526 580 607 634 694 720
Unmatched signal(s) in R2 at line(s) 482 509 526 569 595 649 676 703 763 789
For R1:R2 matched signals only, Q= 7.881%
Result      : Weakly similar.
-------------------------------------------------------------------------------------

KWSN-Darwin-MBbench v2.1.07
Running on TomsMacPro.local at Tue Aug 30 06:28:05 2016
---------------------------------------------------
Starting benchmark run...
---------------------------------------------------
Listing wu-file(s) in /testWUs :
reference_work_unit_r3215.wu

Listing executable(s) in /APPS :
MBv8_8.17r3515_ati5_ssse3_x86_64-apple-darwin

Listing executable in /REF_APPs :
MBv8_8.05r3344_sse41_x86_64-apple-darwin
---------------------------------------------------
Current WU: reference_work_unit_r3215.wu
---------------------------------------------------
Skipping default app MBv8_8.05r3344_sse41_x86_64-apple-darwin, displaying saved result(s)
Elapsed Time: ………………………………… 2104 seconds
---------------------------------------------------
Running app with command : MBv8_8.17r3515_ati5_ssse3_x86_64-apple-darwin
Elapsed Time : ……………………………… 464 seconds
Speed compared to default : 453 %
-----------------
Comparing results
                ------------- R1:R2 ------------     ------------- R2:R1 ------------
                Exact  Super  Tight  Good    Bad     Exact  Super  Tight  Good    Bad
        Spike      0      9     11     13      0        0      9     11     13      0
     Autocorr      0      1      1      1      0        0      1      1      1      0
     Gaussian      0      0      0      1      5        0      0      0      1      5
        Pulse      0      0      0      0      0        0      0      0      0      2
      Triplet      0      1      1      2      0        0      1      1      2      1
   Best Spike      0      1      1      1      0        0      1      1      1      0
Best Autocorr      0      1      1      1      0        0      1      1      1      0
Best Gaussian      0      0      0      0      1        0      0      0      0      1
   Best Pulse      0      0      0      0      1        0      0      0      0      1
 Best Triplet      0      1      1      1      0        0      1      1      1      0
                ----   ----   ----   ----   ----     ----   ----   ----   ----   ----
                   0     14     16     20      7        0     14     16     20     10

Unmatched signal(s) in R1 at line(s) 499 526 580 607 634 694 720
Unmatched signal(s) in R2 at line(s) 482 509 526 569 595 649 676 703 763 789
For R1:R2 matched signals only, Q= 7.882%
Result      : Weakly similar.
---------------------------------------------------

Then I booted into Darwin 15.6 and was able to compile a working nVidia OpenCL App. First I ran the short test;

KWSN-Darwin-MBbench v2.1.07
Running on TomsMacPro.local at Tue Aug 30 08:43:29 2016
---------------------------------------------------
Starting benchmark run...
---------------------------------------------------
Listing wu-file(s) in /testWUs :
work_unit.wu

Listing executable(s) in /APPS :
MBv8_8.17r3516_cNV_SoG_x86_64-apple-darwin

Listing executable in /REF_APPs :
MBv8_8.05r3344_sse41_x86_64-apple-darwin
---------------------------------------------------
Current WU: work_unit.wu
---------------------------------------------------
Running default app with command : MBv8_8.05r3344_sse41_x86_64-apple-darwin
       69.13 real        66.99 user         0.15 sys
Elapsed Time: ………………………………… 70 seconds
---------------------------------------------------
Running app with command : MBv8_8.17r3516_cNV_SoG_x86_64-apple-darwin
       55.59 real        17.91 user         2.64 sys
Elapsed Time : ……………………………… 55 seconds
Speed compared to default : 127 %
-----------------
Comparing results
                ------------- R1:R2 ------------     ------------- R2:R1 ------------
                Exact  Super  Tight  Good    Bad     Exact  Super  Tight  Good    Bad
        Spike      0      2      5     10      1        0      2      5     10      0
     Autocorr      0      1      1      2      0        0      1      1      2      0
     Gaussian      0      0      0      7      4        0      0      0      7      4
        Pulse      0      1      1      1      2        0      1      1      1      2
      Triplet      0      2      2      2      0        0      2      2      2      0
   Best Spike      0      0      1      1      0        0      0      1      1      0
Best Autocorr      0      0      0      1      0        0      0      0      1      0
Best Gaussian      0      0      0      0      1        0      0      0      0      1
   Best Pulse      0      0      0      0      1        0      0      0      0      1
 Best Triplet      0      1      1      1      0        0      1      1      1      0
                ----   ----   ----   ----   ----     ----   ----   ----   ----   ----
                   0      7     11     25      9        0      7     11     25      8

Unmatched signal(s) in R1 at line(s) 554 613 738 765 792 808 834 894 920
Unmatched signal(s) in R2 at line(s) 317 345 721 764 791 818 878 904
For R1:R2 matched signals only, Q= ????
Result      : Weakly similar.
---------------------------------------------------

Then the Longer test;

KWSN-Darwin-MBbench v2.1.07
Running on TomsMacPro.local at Tue Aug 30 08:33:38 2016
---------------------------------------------------
Starting benchmark run...
---------------------------------------------------
Listing wu-file(s) in /testWUs :
reference_work_unit_r3215.wu

Listing executable(s) in /APPS :
MBv8_8.17r3516_cNV_SoG_x86_64-apple-darwin

Listing executable in /REF_APPs :
MBv8_8.05r3344_sse41_x86_64-apple-darwin
---------------------------------------------------
Current WU: reference_work_unit_r3215.wu
---------------------------------------------------
Running default app with command : MBv8_8.05r3344_sse41_x86_64-apple-darwin
     2109.30 real      2103.91 user         3.45 sys
Elapsed Time: ………………………………… 2110 seconds
---------------------------------------------------
Running app with command : MBv8_8.17r3516_cNV_SoG_x86_64-apple-darwin
      926.80 real       576.59 user       159.68 sys
Elapsed Time : ……………………………… 927 seconds
Speed compared to default : 227 %
-----------------
Comparing results
                ------------- R1:R2 ------------     ------------- R2:R1 ------------
                Exact  Super  Tight  Good    Bad     Exact  Super  Tight  Good    Bad
        Spike      0      9     11     13      0        0      9     11     13      0
     Autocorr      0      1      1      1      0        0      1      1      1      0
     Gaussian      0      0      0      1      5        0      0      0      1      5
        Pulse      0      0      0      0      0        0      0      0      0      2
      Triplet      0      1      1      2      0        0      1      1      2      1
   Best Spike      0      1      1      1      0        0      1      1      1      0
Best Autocorr      0      1      1      1      0        0      1      1      1      0
Best Gaussian      0      0      0      0      1        0      0      0      0      1
   Best Pulse      0      0      0      0      1        0      0      0      0      1
 Best Triplet      0      1      1      1      0        0      1      1      1      0
                ----   ----   ----   ----   ----     ----   ----   ----   ----   ----
                   0     14     16     20      7        0     14     16     20     10

Unmatched signal(s) in R1 at line(s) 499 526 580 607 634 694 720
Unmatched signal(s) in R2 at line(s) 482 509 526 569 595 649 676 703 763 789
For R1:R2 matched signals only, Q= 7.882%
Result      : Weakly similar.
---------------------------------------------------

Not good with OpenCL in Darwin 15.x.

BTW, Which GUPPI data unit is being used? I don't see a GUPPI unit in the Lunatics Download section.

BTW, Which GUPPI data unit is being used? I don't see a GUPPI unit in the Lunatics Download section.

Grab your own, or use one of the ones that Kiska has been archiving.

Most of the Lunatics test tasks have been tweaked to reduce their run times - they are useful for comparing multiple application speeds, but are less good at catching sporadic signal errors which even get missed when running new applications against the limited range of tapes deployed on the Beta site.