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 ...

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!

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:

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.

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:

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.

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.

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.

>
> 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?

Re: UDP Speed Test Version 2.93 Now Available !

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

Bye,
Skybuck.

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.

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.

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.

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:

> 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.

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 ?

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.

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...

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.

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.