Re: Leigh's GUI [OT]

Discussion in 'C++' started by 88888 Dihedral, Jan 28, 2012.

  1. 在 2012å¹´1月28日星期六UTC+8上åˆ8æ—¶09分22秒,Paul写é“:
    > "Leigh Johnston" <> wrote in message
    > news:...
    > > On 27/01/2012 22:23, Paul
    > > Hello
    > >> Leigh are you sure there is a market/requirement amongst Android
    > >> developers
    > >> for your C++ graphics thingy, re: http://neogfx.org
    > >>
    > >> I was looking at developing for Android it seems all applications run in
    > >> a
    > >> JVM. Sure native code can be used but this would be through JNI so I
    > >> don't
    > >> see how your neogfx program would work on an android system.

    > >
    > > That is off-topic, yes.
    > >

    >
    > Well I thought it may make an interesting discussion since there isn't much
    > else going on around here.
    >
    > The android OS has become quite a big player in the booming smartphone
    > sector. I think most C++ programmers would be interested in what the C++
    > languages' role is in this OS.
    > AFAICT there is not a not much support for C++ at application level , other
    > than through JNI. It would be interesting to see how C++ is being used in
    > lower level devopment with this OS.
    >
    > Anyways regards the neogfx thing , I don't see why you have chosen to make
    > this GUI library compatable with two incompatable OS's. If you were
    > targetting windows(CE) and android , I could see a connection. Anyways there
    > is already a Graphics library on both windows and android and that is OpenGL
    > but on android OpenGL is exposed as a Java interface as opposed to windows
    > where it's exposed as a C++ API.
    >
    >
    >
    > --- Posted via news://freenews.netfront.net/ - Complaints to ---


    Don't be fool by Apple's consumer ready to use techie toys at all.
    The roadmap is WIMAX to LTE before 2020 to relpace the cheap old GSM.
    In this part C++ is not very useful for those DSP routines in mobile systems.
    88888 Dihedral, Jan 28, 2012
    #1
    1. Advertising

  2. 88888 Dihedral

    Ian Collins Guest

    On 01/29/12 10:35 AM, 88888 Dihedral wrote:

    > The roadmap is WIMAX to LTE before 2020 to relpace the cheap old GSM.
    > In this part C++ is not very useful for those DSP routines in mobile systems.


    The last mobile DSP project I was involved in used C++.

    --
    Ian Collins
    Ian Collins, Jan 28, 2012
    #2
    1. Advertising

  3. 在 2012å¹´1月29日星期日UTC+8上åˆ6æ—¶29分10秒,Ian Collins写é“:
    > On 01/29/12 10:35 AM, 88888 Dihedral wrote:
    >
    > > The roadmap is WIMAX to LTE before 2020 to relpace the cheap old GSM.
    > > In this part C++ is not very useful for those DSP routines in mobile systems.

    >
    > The last mobile DSP project I was involved in used C++.
    >
    > --
    > Ian Collins


    I'll use pointers to structures for any heavy computing jobs in DSP
    in the C way.

    Even the v-pointer to the v-table for each element in 2D or 3D are
    slowingdown the process.

    Of course a lot people don't do digtal image or video processing for
    a window convolution larger than 16X16.

    Just implement a Wiener filter of a simple model for an image of a high priced
    digital camcorder for hand shakinking elimanation of motion blurred sources,
    then the C++ funny way is not very useful at all.
    88888 Dihedral, Jan 28, 2012
    #3
  4. 88888 Dihedral

    Ian Collins Guest

    On 01/29/12 11:46 AM, 88888 Dihedral wrote:
    > 在 2012å¹´1月29日星期日UTC+8上åˆ6æ—¶29分10秒,Ian Collins写é“:
    >> On 01/29/12 10:35 AM, 88888 Dihedral wrote:
    >>
    >>> The roadmap is WIMAX to LTE before 2020 to relpace the cheap old GSM.
    >>> In this part C++ is not very useful for those DSP routines in mobile systems.

    >>
    >> The last mobile DSP project I was involved in used C++.


    Please don't quote signatures

    > I'll use pointers to structures for any heavy computing jobs in DSP
    > in the C way.
    >
    > Even the v-pointer to the v-table for each element in 2D or 3D are
    > slowingdown the process.
    >
    > Of course a lot people don't do digtal image or video processing for
    > a window convolution larger than 16X16.


    Even more people don't do any video processing. DSPs have many uses.

    > Just implement a Wiener filter of a simple model for an image of a high priced
    > digital camcorder for hand shakinking elimanation of motion blurred sources,
    > then the C++ funny way is not very useful at all.


    What "C++ funny way"? There are as many ways to use C++ as there are
    problems to solve.

    --
    Ian Collins
    Ian Collins, Jan 28, 2012
    #4
  5. 在 2012å¹´1月29日星期日UTC+8上åˆ7æ—¶28分39秒,Ian Collins写é“:
    > On 01/29/12 11:46 AM, 88888 Dihedral wrote:
    > > 在 2012å¹´1月29日星期日UTC+8上åˆ6æ—¶29分10秒,Ian Collins写é“:
    > >> On 01/29/12 10:35 AM, 88888 Dihedral wrote:
    > >>
    > >>> The roadmap is WIMAX to LTE before 2020 to relpace the cheap old GSM..
    > >>> In this part C++ is not very useful for those DSP routines in mobile systems.
    > >>
    > >> The last mobile DSP project I was involved in used C++.

    >
    > Please don't quote signatures
    >
    > > I'll use pointers to structures for any heavy computing jobs in DSP
    > > in the C way.
    > >
    > > Even the v-pointer to the v-table for each element in 2D or 3D are
    > > slowingdown the process.
    > >
    > > Of course a lot people don't do digtal image or video processing for
    > > a window convolution larger than 16X16.

    >
    > Even more people don't do any video processing. DSPs have many uses.
    >
    > > Just implement a Wiener filter of a simple model for an image of a highpriced
    > > digital camcorder for hand shakinking elimanation of motion blurred sources,
    > > then the C++ funny way is not very useful at all.

    >
    > What "C++ funny way"? There are as many ways to use C++ as there are
    > problems to solve.
    >
    > --
    > Ian Collins


    I'll make my point clear in heavy computing tasks. It is better to program
    in registers directly supported in hardware operations without any extra-
    overhead in the basic operations.

    Higher level languages that will introduce any overhead in basic operationsare not very helpful in this situation.
    88888 Dihedral, Jan 29, 2012
    #5
  6. 在 2012å¹´1月29日星期日UTC+8上åˆ6æ—¶29分10秒,Ian Collins写é“:
    > On 01/29/12 10:35 AM, 88888 Dihedral wrote:
    >
    > > The roadmap is WIMAX to LTE before 2020 to relpace the cheap old GSM.
    > > In this part C++ is not very useful for those DSP routines in mobile systems.

    >
    > The last mobile DSP project I was involved in used C++.
    >
    > --
    > Ian Collins


    In my experiments of implementing arithmetics in different fields or rings
    for DSP algorithms, the operator reloading in C++ actually will slow down basic operations.
    88888 Dihedral, Jan 30, 2012
    #6
  7. 88888 Dihedral

    hanukas Guest

    On Jan 29, 12:46 am, 88888 Dihedral <>
    wrote:
    > 在 2012å¹´1月29日星期日UTC+8上åˆ6æ—¶29分10秒,Ian Collins写é“:
    >
    > > On 01/29/12 10:35 AM, 88888 Dihedral wrote:

    >
    > > > The roadmap is WIMAX to LTE before 2020 to relpace the cheap old  GSM.
    > > > In this part C++ is not very useful for those DSP routines in mobile systems.

    >
    > > The last mobile DSP project I was involved in used C++.

    >
    > > --
    > > Ian Collins

    >
    > I'll use  pointers to  structures for any heavy computing jobs in DSP
    > in the C way.
    >
    > Even the v-pointer to the v-table for each element in 2D or 3D are
    > slowingdown the process.


    Of course. Same can be said about redundant computation, for example:

    process_sample(x, y, ..);
    -->
    *(address + offset)
    ++offset
    -->
    ~= address[offset++]

    - avoid unnecessary method/function calls

    - don't compute stride*y for each sample, you KNOW the address of next
    sample when process samples in predictable order

    - if you process samples in predictable order, you can also predict
    the access pattern from cache's point of view; for 2D data, tile it
    for better local coherency and minimize cache misses

    - can you reduce ALU cost with data-level parallelism?

    - can you reduce overhead with process level parallelism?

    ... and other interesting architectural decisions that you can make. C/C
    ++ is irrelevant argument when the programmer is proficient. The C++
    constructs allow more readable code with no performance impact. No one
    is suggesting you need to invoke virtual c++ method call for each
    processed sample, except you.. why are you using that as argument
    against C++ if you are a very good programmer?


    > Of course a lot people don't do digtal image or video processing for
    > a window convolution larger than 16X16.


    I do something where we have to process over 100,000,000 samples per
    second, 1-2 million samples at 60 fps. It's called real-time
    rendering. And we have to do that with only few watts, there isn't
    much room to waste power on redundant computation.


    > Just implement a Wiener filter of a simple model for an image of a high priced
    > digital camcorder for hand shakinking elimanation of motion blurred sources,
    > then the C++ funny way is not very useful at all.


    The C++ funny way, whatever it is that you mean by that probably
    isn't. But there is nothing in C (!) that it could do better. It comes
    down to knowing what you are doing, sounds to me that you only know
    how to write poorly performing C++ code so I would say that you're not
    the best possible go-to guy for advice. No offence, it just comes out
    that way.
    hanukas, Jan 30, 2012
    #7
  8. 在 2012å¹´1月30日星期一UTC+8下åˆ4æ—¶55分39秒,hanukas写é“:
    > On Jan 29, 12:46 am, 88888 Dihedral <>
    > wrote:
    > > 在 2012å¹´1月29日星期日UTC+8上åˆ6æ—¶29分10秒,Ian Collins写é“:
    > >
    > > > On 01/29/12 10:35 AM, 88888 Dihedral wrote:

    > >
    > > > > The roadmap is WIMAX to LTE before 2020 to relpace the cheap old  GSM.
    > > > > In this part C++ is not very useful for those DSP routines in mobile systems.

    > >
    > > > The last mobile DSP project I was involved in used C++.

    > >
    > > > --
    > > > Ian Collins

    > >
    > > I'll use  pointers to  structures for any heavy computing jobs in DSP
    > > in the C way.
    > >
    > > Even the v-pointer to the v-table for each element in 2D or 3D are
    > > slowingdown the process.

    >
    > Of course. Same can be said about redundant computation, for example:
    >
    > process_sample(x, y, ..);
    > -->
    > *(address + offset)
    > ++offset
    > -->
    > ~= address[offset++]
    >
    > - avoid unnecessary method/function calls
    >
    > - don't compute stride*y for each sample, you KNOW the address of next
    > sample when process samples in predictable order
    >
    > - if you process samples in predictable order, you can also predict
    > the access pattern from cache's point of view; for 2D data, tile it
    > for better local coherency and minimize cache misses
    >
    > - can you reduce ALU cost with data-level parallelism?
    >
    > - can you reduce overhead with process level parallelism?
    >
    > .. and other interesting architectural decisions that you can make. C/C
    > ++ is irrelevant argument when the programmer is proficient. The C++
    > constructs allow more readable code with no performance impact. No one
    > is suggesting you need to invoke virtual c++ method call for each
    > processed sample, except you.. why are you using that as argument
    > against C++ if you are a very good programmer?
    >
    >
    > > Of course a lot people don't do digtal image or video processing for
    > > a window convolution larger than 16X16.

    >
    > I do something where we have to process over 100,000,000 samples per
    > second, 1-2 million samples at 60 fps. It's called real-time
    > rendering. And we have to do that with only few watts, there isn't
    > much room to waste power on redundant computation.
    >
    >
    > > Just implement a Wiener filter of a simple model for an image of a highpriced
    > > digital camcorder for hand shakinking elimanation of motion blurred sources,
    > > then the C++ funny way is not very useful at all.

    >
    > The C++ funny way, whatever it is that you mean by that probably
    > isn't. But there is nothing in C (!) that it could do better. It comes
    > down to knowing what you are doing, sounds to me that you only know
    > how to write poorly performing C++ code so I would say that you're not
    > the best possible go-to guy for advice. No offence, it just comes out
    > that way.


    What I have emphasized is that C++ is better in a high level of controls
    of complex components organized as easy to use objects in a library or a package to be used by others, but it should not be
    used for heavy computing in the low level that needs to deal with hardware
    to avoid unnecessary overheads in repeated basic operations.
    88888 Dihedral, Jan 30, 2012
    #8
  9. 88888 Dihedral

    hanukas Guest

    On Jan 30, 8:46 pm, 88888 Dihedral <>
    wrote:
    > 在 2012å¹´1月30日星期一UTC+8下åˆ4æ—¶55分39秒,hanukas写é“:
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > On Jan 29, 12:46 am, 88888 Dihedral <>
    > > wrote:
    > > > 在 2012å¹´1月29日星期日UTC+8上åˆ6æ—¶29分10秒,Ian Collins写é“:

    >
    > > > > On 01/29/12 10:35 AM, 88888 Dihedral wrote:

    >
    > > > > > The roadmap is WIMAX to LTE before 2020 to relpace the cheap old  GSM.
    > > > > > In this part C++ is not very useful for those DSP routines in mobile systems.

    >
    > > > > The last mobile DSP project I was involved in used C++.

    >
    > > > > --
    > > > > Ian Collins

    >
    > > > I'll use  pointers to  structures for any heavy computing jobs in DSP
    > > > in the C way.

    >
    > > > Even the v-pointer to the v-table for each element in 2D or 3D are
    > > > slowingdown the process.

    >
    > > Of course. Same can be said about redundant computation, for example:

    >
    > > process_sample(x, y, ..);
    > > -->
    > > *(address + offset)
    > > ++offset
    > > -->
    > > ~= address[offset++]

    >
    > > - avoid unnecessary method/function calls

    >
    > > - don't compute stride*y for each sample, you KNOW the address of next
    > > sample when process samples in predictable order

    >
    > > - if you process samples in predictable order, you can also predict
    > > the access pattern from cache's point of view; for 2D data, tile it
    > > for better local coherency and minimize cache misses

    >
    > > - can you reduce ALU cost with data-level parallelism?

    >
    > > - can you reduce overhead with process level parallelism?

    >
    > > .. and other interesting architectural decisions that you can make. C/C
    > > ++ is irrelevant argument when the programmer is proficient. The C++
    > > constructs allow more readable code with no performance impact. No one
    > > is suggesting you need to invoke virtual c++ method call for each
    > > processed sample, except you.. why are you using that as argument
    > > against C++ if you are a very good programmer?

    >
    > > > Of course a lot people don't do digtal image or video processing for
    > > > a window convolution larger than 16X16.

    >
    > > I do something where we have to process over 100,000,000 samples per
    > > second, 1-2 million samples at 60 fps. It's called real-time
    > > rendering. And we have to do that with only few watts, there isn't
    > > much room to waste power on redundant computation.

    >
    > > > Just implement a Wiener filter of a simple model for an image of a high priced
    > > > digital camcorder for hand shakinking elimanation of motion blurred sources,
    > > > then the C++ funny way is not very useful at all.

    >
    > > The C++ funny way, whatever it is that you mean by that probably
    > > isn't. But there is nothing in C (!) that it could do better. It comes
    > > down to knowing what you are doing, sounds to me that you only know
    > > how to write poorly performing C++ code so I would say that you're not
    > > the best possible go-to guy for advice. No offence, it just comes out
    > > that way.

    >
    > What I have emphasized is that C++ is better in a high level of controls
    > of complex components organized as easy to use objects in a library or a package to be used by others, but it should not be
    > used for heavy computing in the low level that needs to deal with hardware
    > to avoid unnecessary overheads in repeated basic operations.


    For dealing with hardware there are two primary choices which are
    preferred:

    1. GPU: CUDA, OpenCL, OpenGL/GLSL, D3D/HLSL, Cg, etc.
    2. CPU: SIMD/MT -JIT

    The (1) is self-explatonary. The less often taken path is the (2),
    which is very expensive to implement as in worst case it is task
    comparable to writing optimizing compiler. In less complicated
    scenario it is just putting macro blocks of machine code together in
    controlled fashion. The middle ground is to generate the machine code
    in intermediate format where all symbols are named and register
    allocator is the largest single task to overcome.

    In both cases the implementation language is not as interesting as
    what is done with it. The (1) has the goal to create solid quality
    microcode for the GPU to execute and have good paths for data to go
    through. The (2) has the same idea, but instead of microcode we
    generate code for the CPU ALU instead, the data paths are less
    sensitive to latency but more sensitive to cache as this path is more
    flexible than the streaming model preferred for GPU.

    If you are writing inner loops in HLL like C/C++ in that case again,
    the C does not offer any real-world advantage over C if the programmer
    understands his tools and knows how the HLL constructs map into
    hardware instructions. This requires some experience with the compiler
    and linker toolchain to have realistic expectations of the outcome of
    HLL expressions. Usually at this level two things are done:

    1. The results are measured against other alternatives
    2. The output assembly (.s, .asm) is inspected so that there aren't
    any surprises like calls to _ftol, or call to inline method and so on.
    Inline keyword cannot be trusted in generic portable code to always
    get the job done, sure, macros and other constructs can be used to
    guide the code into the right direction.

    The main thing is to measure, profile and check the output and adjust
    the source code accordingly. It is a realistic expectation that the
    compilers get better over time, not worse, so any optimization along
    these guidelines will stay effective. On the other hand, some work-
    arounds to get better output become obsolete over time and more
    straightforward and descriptive expression usually slowly gains
    ground.

    All code written with this mindset is CONTEMPORARY and gets STALE over
    time! VERY important to keep in mind.

    This kind of micro-optimization is unnecessary for most programmers
    for most of the time. Especially now that we have hardware to process
    streamed data. For example, seems that what you are working on is a 2D
    matrix of input that you map into output with 2D, finite-size kernel..
    this kind of workload is often ideal for graphics processor to take a
    peek at. The problem with this kind of thinking is the round-trip to
    GPU local address space and back, if you can't synchronize the data
    processing w/o flushing you're better off using the CPU most of the
    time, where the technique (2) comes in.

    What I'm getting at in roundabout way is that the C vs. C++ argument
    is out-dated and even if that is the language of choice for the actual
    inner loop, the C++ doesn't have ANY disadvantage except poor
    programmers. The C is more hard-core and has less facilities to ****
    things up if you don't know how everything works. IN THAT SENSE it is
    much better choice rather than let some sloppy C++ programmer try to
    do a good job w/ tool he has no idea how to use properly. The key
    concept is that this same sloppy C++ programmer might be TOP GUN C
    programmer, so let him use the tools he knows best. But this is
    totally different argument than that the C++ is inherently slow; it's
    not.
    hanukas, Jan 30, 2012
    #9
  10. 88888 Dihedral

    Ian Collins Guest

    On 01/31/12 07:46 AM, 88888 Dihedral wrote:
    >
    > What I have emphasized is that C++ is better in a high level of controls
    > of complex components organized as easy to use objects in a library or a package to be used by others, but it should not be
    > used for heavy computing in the low level that needs to deal with hardware
    > to avoid unnecessary overheads in repeated basic operations.


    That problem only occurs if you don't know what you are doing. The C++
    overheads are no greater than C overheads for the same operations.

    --
    Ian Collins
    Ian Collins, Jan 31, 2012
    #10
    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. paul.foreman

    GUI - GUI value passing

    paul.foreman, Oct 22, 2004, in forum: Java
    Replies:
    5
    Views:
    731
    Michael Rauscher
    Oct 25, 2004
  2. ulysses
    Replies:
    4
    Views:
    748
    Werner Schiendl
    Oct 22, 2003
  3. Andrew Lapidas

    PyGTK GUI update without signals from GUI

    Andrew Lapidas, Apr 13, 2008, in forum: Python
    Replies:
    0
    Views:
    398
    Andrew Lapidas
    Apr 13, 2008
  4. Paul

    A question for Leigh

    Paul, Apr 27, 2011, in forum: C++
    Replies:
    2
    Views:
    187
  5. Stefan Ram
    Replies:
    3
    Views:
    476
    Arne Vajhøj
    Nov 20, 2011
Loading...

Share This Page