[ENet-discuss] Multi-threading ENet the easy way...

[Nuno Silva]

What i meant when i said it was a linear array was that it's contiguous
(sp?) in memory, so reallocs may happen, which may slow down adding/removing
members to the vector.

On Fri, Feb 5, 2010 at 10:10 AM, Syed Setia Pernama <syedhs at yahoo.com>wrote:

>
> *From:* Nuno Silva <little.coding.fox at gmail.com>
> *To:* Discussion of the ENet library <enet-discuss at cubik.org>
> *Sent:* Fri, February 5, 2010 5:25:16 PM
>
> *Subject:* Re: [ENet-discuss] Multi-threading ENet the easy way...
>
> Also, vector may be a bit slow since it's a linear array and all, try using
> either map or list and see if it speeds things up.
>
> std::vector should be okay as the main thread will access the data linearly
> (I am not going to find data base on ENetPeer) and the std::pair is there to
> make sure that I know where the packet is coming from.
>
>
> On Fri, Feb 5, 2010 at 8:14 AM, Syed Setia Pernama <syedhs at yahoo.com>wrote:
>
>> I am using Intel VTune profiler and the hits ~20% was in the function
>> enet_protocol_dispatch_incoming_commands.
>> I think the reason why enet is taking much of the processing time because
>> first
>>
>> 1) it receives the packet from up to 5 clients (which send @60hz, and each
>> of them is about 1kb-2kb, so each second it receives up to 120kb per
>> client). The packet size received is just my estimation but I tried not to
>> exceed the MTU max size.
>>
>> 2) and then it will retransmit some of the packets back to all clients.
>>
>> I have a dateline this tuesday to have stable server and to have a stable
>> one, the most crucial thing is to have server running the physics @60hz. I
>> think without mult-threading, it is not possible. Anyway, I will post my
>> findings once the code is working.
>>
>> I think this could be interesting as CPU dice scales up (quad-core,
>> eight-core etc) and I dont think multi-threading enet is that difficult as
>> the enet can keep most of the data to iself (hence, the thread it is running
>> on).
>>
>> ------------------------------
>> *From:* Blair Holloway <thynameisblair at chaosandcode.com>
>> *To:* Discussion of the ENet library <enet-discuss at cubik.org>
>> *Sent:* Fri, February 5, 2010 6:39:40 AM
>> *Subject:* Re: [ENet-discuss] Multi-threading ENet the easy way...
>>
>> The last game I worked on handled 16 players, fully connected (so each
>> machine had 15 active connections), and I think in heated dogfights we
>> peaked around 200 outbound packets per second. I'm reasonably sure
>> enet_host_service wasn't taking 20% of our frame time, or my lead would have
>> whacked me over the head with a cricket bat. :)
>>
>> I'd be curious to see a more detailed profiling here - do you know where
>> Enet is spending its time?
>>
>> Regards,
>>
>> - Blair
>>
>> On Fri, Feb 5, 2010 at 1:04 AM, Syed Setia Pernama <syedhs at yahoo.com>wrote:
>>
>>> Hi,
>>>
>>> I have profiled my server which use enet and found that many enet
>>> functions are using quite substantial of cpu processing (~20%). I know
>>> probably many of you don't see enet as the bottleneck while profiling, but
>>> mine is a little different, it is a server which can send (and receive) 60
>>> packets/second to 5 clients. I know, i know that there are some past
>>> postings suggested that this is not the best way to do it (60hz), but as it
>>> is now it is running okay. But the more pressing issue now is to increase
>>> the performance so we decide to make full use of quad core via
>>> multi-threading technique.
>>>
>>> What I am thinking of the easy way to multi-thread enet is to
>>> specifically run this:-
>>>
>>> std::vector<std::pair<ENetPacket*,ENetPeer*>packets;
>>> while (enet_host_service (mHost, & event, 0) > 0) {
>>>   ...
>>>   switch (event.type) {
>>>     case ENET_EVENT_TYPE_RECEIVE:
>>>       packets.push_back(std::make_pair(event.packet, event.peer));
>>>  ....
>>> }
>>>
>>> on thread. The thread will be continuously run 'enet_host_service'
>>> function until the server shutdown.
>>>
>>> And the enet packet which is stored using 'packets' variable above, will
>>> be made available to main thread via another function -
>>>
>>> void getPackets(std::vector<std::pair<ENetPacket*,ENetPeer*>>& packets)
>>>
>>> Of course, this function will perform the necessary lock for
>>> multithreading so as to prevent the thread from inserting while main thread
>>> is reading it.
>>>
>>> And that's it. The sending part will be in the main thread. The network
>>> thread only concern about receiving packets.
>>>
>>> So the big question is, is the design okay?
>>>
>>> TIA.
>>>
>>>
>>>
>>> _______________________________________________
>>> ENet-discuss mailing list
>>> ENet-discuss at cubik.org
>>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>>
>>
>>
>>
>> _______________________________________________
>> ENet-discuss mailing list
>> ENet-discuss at cubik.org
>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>
>>
>
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20100205/d9b35550/attachment-0001.htm>