Handling different implementations of the same algorithm

Discussion in 'C++' started by luca, Aug 10, 2011.

  1. luca

    luca Guest

    Hi,

    correct my analysis if i am wrong, please. I am writing a software in
    the computer vision field. Now, i have several algorithms that can be
    regarded as low-level and could be viewed as a single routine. Is it a
    wrong attitude to write a simple class with a single method that do
    the job? Should i use a static method of a namespace or a class
    containing static low-level routines? Consider that sometimes it could
    be useful to create an object, because memory allocation could be done
    only at construction (or better, initialization) time (and i could
    reuse the object untile its destruction). The burden of handling such
    memory would be demanded to the object itself, instead of having to
    manage memory to pass to a static method.

    Another question i have is the following: suppose i have three
    different implementation of the same algorithm. One is written in
    plain C++, one is written in OpenCL (for parallel processing, would
    result in different C++ code, with special function to be called,
    kernel programs that run on the device to be compiled and so on), one
    is written in playin vertex/program shaders for GPU (call it GPU
    implementation, it would use OpenGL for example). The algorithm do the
    same job (for example, processing an image and returnings the a list
    of coordinates of special pixels), but the method to call it and the
    way it returns data can be very different. The problem is the
    following:

    1.
    I will drop C++ implementation of the low-level algorithms in future,
    but for now, OpenCL is not so widespread, and i am forced to implement
    things in different ways.

    2.
    C++ plain implementation results in code to be executed on the CPU.
    Memory is passed/returned as usual (through pointers).

    3.
    OpenCL/GPU implementation: although they are different under every
    aspect, share a common thing: memory must be transferred from main
    system
    to device memory for input parameters and the contrary for output
    parameters.

    So, 2 and 3 call for some sort of interface for input/output
    parameters. Even the format of this parameters is important. For
    example, a graph implemented using pointers would be not suited to be
    passed to the device memory. But this aspect would be decided in
    advance (whatever is the implementation of the low-level algorithm,
    the format of the input parameters must be such that no pointers are
    valid and so on...), so no problem.

    But, one thing to keep in mind and which is important is the
    following: low-level algorithms usually are called one after another,
    that is, one run A1, followed by A2, followed by A3 and so on. Now, it
    can happen that A_{i+1} uses the results provided by A_i and it would
    be a waste of time to transfer memory from device to main system at
    the end of A_i: just tell A_{i+1} that the parameter needed is already
    on the device memory and has handle XXX.

    Ok, it is clear that some form of interface for input/output
    parameters is needed. This object would have a method Create( void
    *memory, etc...) and would handle all of this.

    So, i have an interface for memory object to be used as input/output
    parameters for low-level algorithsm. Ok, but how would you create this
    algorithms?
    I mean, mixing CPU with GPU implementation would be a stupid thing to
    do. OpenCL uses the concept of Context. A natural way would be to
    create an interface IContext and having diffrerent context for
    different implementation (CPU, OPENCL, OPENGL for example). Then i
    would implement a factory for low-level algorithms. This factory
    would create IAlgorithm objects (another interface, but could be a
    void *) given:

    1. the name of the algorithm (for example: ALGO_EDGEDETECTOR_SOBEL)
    2. the actual context

    Finally, who construct the context? The client of the software will
    use a static method, for example:

    IContext *ctx = ContextFactory::CreateContext( CTX_OPENCL );

    So, to sum up:

    .. a context concept, IContext, created by a context factory
    .. a way of handling input/output for low-level algorithm
    (IMemoryObject could be the basic interafce)
    .. a factory for classes implementing low-level algorithms

    Is this general desing a mess? What do you think? How would you handle
    this situation?

    Thank you very much!
    Luca

    PS.
    I have posted this msg already to C++.moderated, but my original
    intent was to post this here, because it is faster! Sorry for cross-
    posting.
     
    luca, Aug 10, 2011
    #1
    1. Advertising

  2. On Aug 10, 5:04 pm, luca <> wrote:

    I think you need to read up on some software design patterns.


    > correct my analysis if i am wrong, please. I am writing a software in
    > the computer vision field. Now, i have several algorithms that can be
    > regarded as low-level and could be viewed as a single routine. Is it a
    > wrong attitude to write a simple class with a single method that do
    > the job?


    this is similar to the Strategy pattern. Hide the actual concrete
    implementation behind an abstract interface. the rest of the program
    need never know what did the calculation.


    > Should i use a static method of a namespace or a class
    > containing static low-level routines? Consider that sometimes it could
    > be useful to create an object, because memory allocation could be done
    > only at construction (or better, initialization) time (and i could
    > reuse the object untile its destruction). The burden of handling such
    > memory would be demanded to the object itself, instead of having to
    > manage memory to pass to a static method.


    yes, this seems like a good reason /not/ to use a static method

    > Another question i have is the following: suppose i have three
    > different implementation of the same algorithm. One is written in
    > plain C++, one is written in OpenCL (for parallel processing, would
    > result in different C++ code, with special function to be called,
    > kernel programs that run on the device to be compiled and so on), one
    > is written in playin vertex/program shaders for GPU (call it GPU
    > implementation, it would use OpenGL for example). The algorithm do the
    > same job (for example, processing an image and returnings the a list
    > of coordinates of special pixels), but the method to call it and the
    > way it returns data can be very different. The problem is the
    > following:
    >
    > 1.
    > I will drop C++ implementation of the low-level algorithms in future,
    > but for now, OpenCL is not so widespread, and i am forced to implement
    > things in different ways.
    >
    > 2.
    > C++ plain implementation results in code to be executed on the CPU.
    > Memory is passed/returned as usual (through pointers).
    >
    > 3.
    > OpenCL/GPU implementation: although they are different under every
    > aspect, share a common thing: memory must be transferred from main
    > system
    > to device memory for input parameters and the contrary for output
    > parameters.
    >
    > So, 2 and 3 call for some sort of interface for input/output
    > parameters. Even the format of this parameters is important. For
    > example, a graph implemented using pointers would be not suited to be
    > passed to the device memory. But this aspect would be decided in
    > advance (whatever is the implementation of the low-level algorithm,
    > the format of the input parameters must be such that no pointers are
    > valid and so on...), so no problem.
    >
    > But, one thing to keep in mind and which is important is the
    > following: low-level algorithms usually are called one after another,
    > that is, one run A1, followed by A2, followed by A3 and so on. Now, it
    > can happen that A_{i+1} uses the results provided by A_i and it would
    > be a waste of time to transfer memory from device to main system at
    > the end of A_i: just tell A_{i+1} that the parameter needed is already
    > on the device memory and has handle XXX.
    >
    > Ok, it is clear that some form of interface for input/output
    > parameters is needed. This object would have a method Create( void
    > *memory, etc...) and would handle all of this.
    >
    > So, i have an interface for memory object to be used as input/output
    > parameters for low-level algorithsm. Ok, but how would you create this
    > algorithms?


    I don't think I know enough about your problem. Could the A1..An
    functions have some sort of context passed to them. The context would
    handle the details of memory management

    > I mean, mixing CPU with GPU implementation would be a stupid thing to
    > do. OpenCL uses the concept of Context.


    ah! :)

    > A natural way would be to
    > create an interface IContext and having diffrerent context for
    > different implementation (CPU, OPENCL, OPENGL for example). Then i
    > would implement a factory for low-level algorithms. This factory
    > would create IAlgorithm objects (another interface, but could be a
    > void *) given:


    I'm not sure why void* is needed.

    > 1. the name of the algorithm (for example: ALGO_EDGEDETECTOR_SOBEL)
    > 2. the actual context
    >
    > Finally, who construct the context? The client of the software will
    > use a static method, for example:
    >
    > IContext *ctx = ContextFactory::CreateContext( CTX_OPENCL );
    >
    > So, to sum up:
    >
    > . a context concept, IContext, created by a context factory
    > . a way of handling input/output for low-level algorithm
    > (IMemoryObject could be the basic interafce)
    > . a factory for classes implementing low-level algorithms
    >
    > Is this general desing a mess? What do you think? How would you handle
    > this situation?


    well it *sounds* sort of reasonable

    > Thank you very much!
    > Luca
    >
    > PS.
    > I have posted this msg already to C++.moderated, but my original
    > intent was to post this here, because it is faster! Sorry for cross-
    > posting.
     
    Nick Keighley, Aug 15, 2011
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Naresh Agarwal
    Replies:
    2
    Views:
    3,592
    Brad BARCLAY
    Jan 8, 2004
  2. Avi
    Replies:
    6
    Views:
    531
    James Kanze
    May 14, 2008
  3. Christopher Brewster
    Replies:
    5
    Views:
    374
    John Machin
    Nov 14, 2008
  4. bluebaron
    Replies:
    3
    Views:
    787
    Jonathan N. Little
    Nov 4, 2009
  5. Guest
    Replies:
    2
    Views:
    203
    Foo Man Chew
    Dec 29, 2003
Loading...

Share This Page