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 <[email protected]>wrote: > > *From:* Nuno Silva <[email protected]> > *To:* Discussion of the ENet library <[email protected]> > *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 <[email protected]>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 <[email protected]> >> *To:* Discussion of the ENet library <[email protected]> >> *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 <[email protected]>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 >>> [email protected] >>> http://lists.cubik.org/mailman/listinfo/enet-discuss >>> >> >> >> >> _______________________________________________ >> ENet-discuss mailing list >> [email protected] >> http://lists.cubik.org/mailman/listinfo/enet-discuss >> >> > > > _______________________________________________ > ENet-discuss mailing list > [email protected] > http://lists.cubik.org/mailman/listinfo/enet-discuss > >
_______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
