1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 <2017> 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 <2017> 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: ADSimDetector |
From: | Mark Rivers <[email protected]> |
To: | "'Mark S. Engbretson'" <[email protected]> |
Cc: | "[email protected]" <[email protected]> |
Date: | Fri, 26 May 2017 22:24:12 +0000 |
Hi Mark, Most plugins that support multiple threads in ADCore R3-0 do have linear increase in performance as the number of threads is increased, at least up to 5 threads. However,
I have not proven this for NDPluginStdArrays because it is so fast that it is hard to send it frames fast enough. Here is I benchmark I just ran on a 20 core RHEL 7 machine: - simDetector 1024x1024, UInt8 data. - AcquireTime and AcquirePeriod both 0.0001 seconds - Peaks mode, PeakNumX=1, PeakNumY=1, PeakWidthX=2, PeakWidthY=2 - NDPluginStdArrays BlockingCallbacks=No - All plugins disabled simDetector ArrayRate_RBV = ~2200 frames/s simDetector task using 66% of 1 core. - NDPluginStdArrays plugin enabled, 1 thread simDetector ArrayRate_RBV = ~2200 frames/s (no change) simDetector task using 66% of 1 core. NDPluginStdArrays ArrayRate_RBV = ~1550 NDPluginStdArrays task using 99.5% of 1 core. So with 1 thread it cannot quite keep up with the simDetector - NDPluginStdArrays plugin enabled, 2 threads simDetector ArrayRate_RBV = ~2200 frames/s (no change) simDetector task using 66% of 1 core. NDPluginStdArrays ArrayRate_RBV = ~2200 NDPluginStdArrays tasks (2) each using 89% of 1 core. So by using 2 threads for NDPluginStdArrays it can keep up with the simDetector at 2200 frames/s. The NDPluginStdArrays plugin is so fast that it is hard to test how many cores it can use because the simDetector cannot really generate frames fast enough to saturate
it. Mark From: Mark S. Engbretson [mailto:[email protected]]
Mark – Hypothetical question. You have posted at various time ADSimDetector beanchmarks. Historical values from a PDF that I am looking at now being about 485 FPS for a 1024 x4 1024 image. If I increase this image dimensions to 3078 by 4096, basically 12 times the
data, the frame rate drops by about the same factor of 12 down to 40 FPS or so (This is confirmed using one of your old AD1.9 windows prebuilts and playing with image sizes). This FPS value is pulled from at the very top level NDStdArray plugin, blocking,
so frames are not dropped. In AD3-0, This plugin is multi-thread enabled. I’m assuming that if someone did not specify a value, 1 thread is allocated for this plugin and that more *might* make it handle bigger data or faster data. I.e., 5 threads might make
that original 1024 x 1024 image collect at . . . 2400+ FPS . . . and that larger image perhaps 200 FPS without dropping frames. Or am I mistaken on how the AD3.0 threads work? I have a newer model Xeon computer with 12 real cores, most of which are idle at any given moment, and was wondering which plugins may be worth committing cores to.
Me |