UDP Speed Test Version 2.93 Now Available ! - TCP-IP

This is a discussion on UDP Speed Test Version 2.93 Now Available ! - TCP-IP ; "Skybuck Flying" wrote in message news:fclotp$sh7$1@news6.zwoll1.ov.home.nl... [...] >>> Other parts complain it can't find the *.lib > > I used Visual Studio 2005 (newer ) > > And I added the library paths/libs to the project properties > > In ...

+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast
Results 21 to 40 of 69

Thread: UDP Speed Test Version 2.93 Now Available !

  1. Re: UDP Speed Test Version 2.93 Now Available !

    "Skybuck Flying" wrote in message
    news:fclotp$sh7$1@news6.zwoll1.ov.home.nl...
    [...]
    >>> Other parts complain it can't find the *.lib

    >
    > I used Visual Studio 2005 (newer )
    >
    > And I added the library paths/libs to the project properties
    >
    > In linker->general->additional library etc... only path needed
    > And I also placed the dll in there and it did work.
    > Many worker thread created.
    > It says acceptex.
    > And then nothing lol
    > And then I close it and it frees the stuff and then later it looks like
    > app hangs but it's not responding anymore
    > because it's cleaning up and then program is done.
    > So it proves the code compiles, builds, and works.. but haven't seen
    > anything really interesting performance wise yet.
    > I am not TCP guy so I guess the examples are useless for me...
    > So I won't access how to use EchoServer and HTTP Proxy.. but maybe I
    > should ask just in case it might be interesting so I will ask:
    >
    > How would other computer programs "communicate" with these two examples ?
    >
    > what about http proxy... what kind of proxy is this.. is this maybe a
    > socks5 proxy ???

    [...]

    Its a basic HTTP 1.0 proxy. Add the '/lib' to your linker
    directory search paths. Build the HttpProxy example. Run the program, and it
    will setup the server and listen on port 5000. Configure your web-browser to
    use a proxy with http/1.0 on port 5000, and go to a web page or two. You
    should see the console of the proxy server respond to the requests, and the
    pages should load up on your browser. Also, I believe that the EchoServer
    listens on port 5000 as well.


    > An UDP example would be much more interesting ====DDDD


    I agree. BTW, I am sorry for the crappy state of that old code. The more I
    look at it the more I remember how crusty it actually is!


  2. Re: UDP Speed Test Version 2.93 Now Available !

    "Skybuck Flying" wrote in message
    news:fcllnq$vo0$1@news1.zwoll1.ov.home.nl...
    >
    > "Chris Thomasson" wrote in message
    > news:AdOdnWXHxb510HPbnZ2dnUVZ_t2inZ2d@comcast.com. ..

    [...]
    >> Well, that old AppCore code Implements a TCP server framework; I am
    >> looking for my old udp stuff. However, I would actually like to see the
    >> following code converted to Delphi:
    >>
    >> http://appcore.home.comcast.net
    >>
    >> This has nothing to do with network programming, although it can be made
    >> to work within the infrastructure of such code; something like this:
    >>
    >> http://groups.google.com/group/alt.w...1b5d37dc84e7b2
    >>
    >> The lock-free algorithms can be used to implement the internal
    >> data-structured within any number of server frameworks.

    >
    > I took a quick look at the code and the discussion.
    >
    > The code looks portable to delphi, not sure about the macro's or ifdef's
    > etc.
    >
    > Only thing I saw that was doubtfull was some align cacheline directive...


    Yeah. That could be a problem...

    > Some questions:
    >
    > 1. Do you really need this in Delphi or would it be a port exercise only ?


    It would be for a port exercise only. I am not really skilled in the art of
    programming in Delphi. I am a die-hard C/Assembly Language programmer. FWIW,
    I have had somebody else interested in porting AppCore over to Delphi. You
    can read some of our discussions here:

    http://monkey.org/sl/0a73ed17



    > 3. Have you compared your "lock" algorithms/implementations with for
    > example critical sections ?
    >
    > How much faster are your algorithms/implementations ?????


    Order of magnitude. Here are some of the reasons why:

    http://groups.google.com/group/comp....c665e616176dce

    https://coolthreads.dev.java.net/ser...1&forumID=1797
    (follow all links I point to at end of msg...)

    http://groups.google.com/group/comp....62e1bfa460a375


    The following link points to some articles by Sun Microsystems and Intel
    that reference to my work...

    http://groups.google.com/group/comp....5dcaed77941352



    > (The code seems quite complex I dare to ask if it's maybe even slower ?)


    All the code in AppCore can beat traditional locking schemes. Although, some
    lock-free code can indeed be slower than its lock-based equivalent. Here is
    one reason why:

    http://groups.google.com/group/comp....f5f99388172527


    Also, here some of the reasons why even pure uncontended locking has
    overheads:

    http://groups.google.com/group/micro...920ba447f3f1f2


  3. Re: UDP Speed Test Version 2.93 Now Available !

    "Chris Thomasson" wrote in message
    news:-_qdnZTorKCl8XPbnZ2dnUVZ_vihnZ2d@comcast.com...
    [...]
    > Its a basic HTTP 1.0 proxy. [...]
    >> An UDP example would be much more interesting ====DDDD

    >
    > I agree. BTW, I am sorry for the crappy state of that old code. The more I
    > look at it the more I remember how crusty it actually is!


    IIRC, the proxy had some problems with really long urls, and one or two
    websites. I never got around to fixing them.


  4. Re: UDP Speed Test Version 2.93 Now Available !

    "Chris Thomasson" wrote in message
    news:PZadnbbVvvfP7XPbnZ2dnUVZ_s6mnZ2d@comcast.com. ..
    > "Skybuck Flying" wrote in message
    > news:fcllnq$vo0$1@news1.zwoll1.ov.home.nl...

    [...]
    >
    >> 3. Have you compared your "lock" algorithms/implementations with for
    >> example critical sections ?
    >>
    >> How much faster are your algorithms/implementations ?????

    >
    > Order of magnitude. Here are some of the reasons why:


    The following thread might be of interest as well:

    http://groups.google.com/group/comp....ab878bfcaffc03



  5. Re: UDP Speed Test Version 2.93 Now Available !

    "Skybuck Flying" wrote in message
    news:fcllnq$vo0$1@news1.zwoll1.ov.home.nl...
    [...]
    > I took a quick look at the code and the discussion.

    [...]

    Let me apologize for the off-topic discussion. If you are interested in
    multi-threading, visit comp.programming.threads in order to talk to the
    experts.


  6. Re: UDP Speed Test Version 2.93 Now Available !


    "Chris Thomasson" wrote in message
    news:Yr2dnSJzgtba73PbnZ2dnUVZ_h2pnZ2d@comcast.com. ..
    > "Chris Thomasson" wrote in message
    > news:PZadnbbVvvfP7XPbnZ2dnUVZ_s6mnZ2d@comcast.com. ..
    >> "Skybuck Flying" wrote in message
    >> news:fcllnq$vo0$1@news1.zwoll1.ov.home.nl...

    > [...]
    >>
    >>> 3. Have you compared your "lock" algorithms/implementations with for
    >>> example critical sections ?
    >>>
    >>> How much faster are your algorithms/implementations ?????

    >>
    >> Order of magnitude. Here are some of the reasons why:

    >
    > The following thread might be of interest as well:
    >
    > http://groups.google.com/group/comp....ab878bfcaffc03


    Well you know what they say: "Talk is cheap"

    I want to see some benchmarks, and not only that I want to see user friendly
    code.

    When I program in Delphi I simply write:

    .... some code ...

    mCriticalSection.Enter;

    .... some more code ...

    mCriticalSection.Leave;

    .... some code...

    You claim you have "thread locking code" or something like that which works
    faster ?

    I am skeptical !

    "For the record": Delphi implements critical sections simply by calling
    Windows API:

    EnterCriticalSection
    LeaveCriticalSection

    Are you claiming you have something which works just as well but than faster
    ?

    If so I really wanna see some decent benchmarks

    Shouldn't be to hard for you to create some sort of benchmark ?

    So that I can compare !

    (And it should be just as simple to use too !!! )

    Bye,
    Skybuck.



  7. Re: UDP Speed Test Version 2.93 Now Available !

    "Skybuck Flying" wrote in message
    news:fclu73$vtu$1@news6.zwoll1.ov.home.nl...
    >
    > "Chris Thomasson" wrote in message
    > news:Yr2dnSJzgtba73PbnZ2dnUVZ_h2pnZ2d@comcast.com. ..
    >> "Chris Thomasson" wrote in message
    >> news:PZadnbbVvvfP7XPbnZ2dnUVZ_s6mnZ2d@comcast.com. ..
    >>> "Skybuck Flying" wrote in message
    >>> news:fcllnq$vo0$1@news1.zwoll1.ov.home.nl...

    >> [...]
    >>>
    >>>> 3. Have you compared your "lock" algorithms/implementations with for
    >>>> example critical sections ?
    >>>>
    >>>> How much faster are your algorithms/implementations ?????
    >>>
    >>> Order of magnitude. Here are some of the reasons why:

    >>
    >> The following thread might be of interest as well:
    >>
    >> http://groups.google.com/group/comp....ab878bfcaffc03

    >
    > Well you know what they say: "Talk is cheap"
    >
    > I want to see some benchmarks, and not only that I want to see user
    > friendly code.


    [...]

    Look at the example programs from the AppCore library:

    http://appcore.home.comcast.net/appcore_0-0-1-i686.zip


    Here is a challenge to you:

    Create a equivalent program that uses CRITICAL_SECTIONS, then we can talk
    about benchmarks. I have had people say your benchmarks are rigged, then
    they create their own tests and e-mail me back saying you were right all
    along. I urge you to do the same. Please inform me if you can beat the
    lock-free single-producer/consumer queue presented in AppCore with your
    lock-based equivalent.

    I will be VERY, VEERRY, impressed if you can do such a thing! Seriously.

    Please note that this challenge applies to ANY reader of this post!

    :^)



    P.S.
    ________

    Read this for starter and look at the references links at the end:

    http://en.wikipedia.org/wiki/Lock-fr...ree_algorithms


    Any thoughts?


  8. Re: UDP Speed Test Version 2.93 Now Available !

    Those examples to complex.

    Just some simple examples will do.

    For example make some threads, calculate some things like a counter or so
    that's incremented.

    Do that in each thread.

    Have one thread read the data and update it to gui or console or so.

    First I would need a DLL where your method is exported or something or some
    code.

    Bye,
    Skybuck.



  9. Re: UDP Speed Test Version 2.93 Now Available !

    "Skybuck Flying" wrote in message
    news:fcnujl$m2g$1@news4.zwoll1.ov.home.nl...
    > Those examples to complex.
    >
    > Just some simple examples will do.


    Here is a simpler example:

    http://groups.google.com/group/comp....34f93b2543ccf5

    Beat that with mutex based solution.


    >
    > For example make some threads, calculate some things like a counter or so
    > that's incremented.
    >
    > Do that in each thread.


    That's too simple. Let's stick to a single-producer/consumer example like
    the one linked to above. High-speed thread-to-thread communication channels.


    > Have one thread read the data and update it to gui or console or so.
    >
    > First I would need a DLL where your method is exported or something or
    > some code.


    Why not do a producer/consumer where producer thread generates data and
    consumer thread gathers it and presents it to GUI?


  10. Re: UDP Speed Test Version 2.93 Now Available !

    Why would "too simple" be a problem to benchmark it ?

    Bye,
    Skybuck.



  11. Re: UDP Speed Test Version 2.93 Now Available !

    How does your queueing mechanism work ?

    Suppose one thread fills the queue real fast.

    Suppose another thread empties it slowly... and can't keep up.

    What will happen with your code ?

    Also you do realize that queueing adds delays ?

    Calling procedures directly are immediatly executed as soon as the lock is
    acquired.

    If the piece of code is not being used by another thread and is not locked
    it will probably execute quickly..

    Though I must admit I have some sections of code which are probably always
    locked etc...

    So some things might have to wait... I can see maybe queueing technique
    might be faster...

    Bye,
    Skybuck.



  12. Re: UDP Speed Test Version 2.93 Now Available !

    However this queueing technique requires a different way of writing code...

    Data has to be passed to god knows what.

    Simply calling routine is not possible anymore.

    So a totally different logic flow/control flow would be necessary.

    It requires a different way of thinking.

    It's more weird really I don't like that.

    I like to be able to step,step,step,step,step through code.

    Now having to inspects lists to what the hell is going on sounds great.

    Lists/queues might be a nightmare to debug what is going on.

    Bye,
    Skybuck.



  13. Re: UDP Speed Test Version 2.93 Now Available !

    > Why not do a producer/consumer where producer thread generates data and
    > consumer thread gathers it and presents it to GUI?


    The data needs only to be displayed once per second.

    Constantly adding data to some sort of list or queue is insane.

    Bye,
    Skybuck.



  14. Re: UDP Speed Test Version 2.93 Now Available !

    "Skybuck Flying" wrote in message
    news:fcobp1$uqo$1@news6.zwoll1.ov.home.nl...
    > How does your queueing mechanism work ?


    It uses simple loads and stores to get the job done. Are you asking about
    pseudo-code? I can show you that if you want.


    > Suppose one thread fills the queue real fast.


    The queue is limited by the memory in the system. Filling the queue could be
    quite a task in a real world application.


    > Suppose another thread empties it slowly... and can't keep up.
    >
    > What will happen with your code ?


    The consumer thread runs independently from the producer. My code would
    service the consumer when it asked to be serviced; as long as the queue has
    an item of course. If not, it blocks on an eventcount algorithm I invented
    here:

    http://groups.google.com/group/comp....8c62ad06dbb380



    > Also you do realize that queuing adds delays ?


    Yes. FIFO you know?


    > Calling procedures directly are immediately executed as soon as the lock
    > is acquired.


    There is not lock in my implementation. No mutual exclusion is needed at
    all.



    > If the piece of code is not being used by another thread and is not locked
    > it will probably execute quickly..


    Again, no locking. Do you realize that lock-free means lock-free?


    > Though I must admit I have some sections of code which are probably always
    > locked etc...


    What do you mean? That is a design flaw IMVHO of course.


    > So some things might have to wait... I can see maybe queuing technique
    > might be faster...


    Waiting for a lock-based queue can be accomplished by using a
    condition-variable. Waiting for a lock-free queue can use an eventcount.
    Please note that the only time a consumer thread needs to wait on the queue
    is when its empty. Consumer threads can wait on an empty queue condition;
    wait for a producer thread to do its thing that is.


    It seems like you are confused about the logic of this type of concurrent
    programming... Do some more research on lock-free programming in
    comp.programming.threads.


  15. Re: UDP Speed Test Version 2.93 Now Available !

    "Skybuck Flying" wrote in message
    news:fcobcs$bo8$1@news6.zwoll1.ov.home.nl...
    > Why would "too simple" be a problem to benchmark it ?


    You want a simple counter to beat a mutex based counter?

    Okay... Here is pseudo-code:


    lock-free counter
    __________________________

    struct counter {
    atomic_word_t m_count; // = 0;

    atomic_word_t xadd(atomic_word_t val) {
    return InterlockedExchangeAdd(&m_count, val);
    }
    };
    __________________________




    lock-based counter
    __________________________

    struct counter {
    atomic_word_t m_count; // = 0;
    CRITICAL_SECTION m_lock;

    atomic_word_t xadd(atomic_word_t val) {
    atomic_word_t old;
    EnterCriticalSection(&m_lock);
    old = m_count;
    m_count += val;
    LeaveCriticalSection(&m_lock);
    return old;
    }
    };
    __________________________





    Which one is faster?


  16. Re: UDP Speed Test Version 2.93 Now Available !

    "Skybuck Flying" wrote in message
    news:fcoc5m$gbe$1@news6.zwoll1.ov.home.nl...
    >> Why not do a producer/consumer where producer thread generates data and
    >> consumer thread gathers it and presents it to GUI?

    >
    > The data needs only to be displayed once per second.


    Then the consumer would just display once per-second? Why not? It could
    dequeue a thousand messages and only display them once per-second, no?


    > Constantly adding data to some sort of list or queue is insane.


    What's wrong with the producer/consumer model Skybuk? Its been around for
    ages upon ages. If you don't like producer/consumer then you don't like
    message passing... Talk to AMD and try to tell them that their
    HyperTransport is insane.


  17. Re: UDP Speed Test Version 2.93 Now Available !

    "Chris Thomasson" wrote in message
    news:bYudnUKrk4R7KXLbnZ2dnUVZ_jidnZ2d@comcast.com. ..
    [...]
    >> Calling procedures directly are immediately executed as soon as the lock
    >> is acquired.

    >
    > There is not lock in my implementation. No mutual exclusion is needed at
    > all.

    [...]

    The eventcount uses a lock when a consumer tries to dequeue something from
    an empty queue. This is called the slow-path. Google for slow-path wrt
    thread synchronization algorithms for further info. A consumer that tries to
    dequeue something from a queue that is _NOT_ empty will hit the fast-path
    which consists of simple loads and stores. Google for fast-path wrt thread
    synchronization algorithms for further info...


  18. Re: UDP Speed Test Version 2.93 Now Available !

    "Chris Thomasson" wrote in message
    news:RMWdnYlPX9_6K3LbnZ2dnUVZ_ournZ2d@comcast.com. ..
    > "Skybuck Flying" wrote in message
    > news:fcoc5m$gbe$1@news6.zwoll1.ov.home.nl...
    >>> Why not do a producer/consumer where producer thread generates data and
    >>> consumer thread gathers it and presents it to GUI?

    >>
    >> The data needs only to be displayed once per second.

    >
    > Then the consumer would just display once per-second? Why not? It could
    > dequeue a thousand messages and only display them once per-second, no?
    >
    >
    >> Constantly adding data to some sort of list or queue is insane.

    >
    > What's wrong with the producer/consumer model Skybuk? Its been around for
    > ages upon ages.


    IOCP is a prime example of a multiple producer/consumer primitive.


  19. Re: UDP Speed Test Version 2.93 Now Available !

    "Chris Thomasson" wrote in message
    news:bYudnUKrk4R7KXLbnZ2dnUVZ_jidnZ2d@comcast.com. ..
    > "Skybuck Flying" wrote in message
    > news:fcobp1$uqo$1@news6.zwoll1.ov.home.nl...

    [...]
    >> Suppose another thread empties it slowly... and can't keep up.

    [...]

    Well that is the nature of a queue. FIFO ordering. If the producer is
    producing faster than the consumer can consume then queuing happens. Of
    course you could use a FULL boundary condition as a predicate to a
    condition-variable, or an eventcount for that matter.


  20. Re: UDP Speed Test Version 2.93 Now Available !

    Irrelevant example, it's too simple.

    What I ment is a slightly less simple example:

    Here is a better example:

    CriticalSection.Enter;

    A := A + 1;
    B := B + 1;
    C := C + A;
    D := D + B;
    E := E + 5;
    F := F + 7;

    CriticalSection.Leave;

    What you described is now useless.

    All the "counters" must remain synchronized.

    What is your alternative for the critical section ?

    Bye,
    Skybuck.



+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast