Hello, After I started reading the thread, I thought that the question was answered after the first couple of posts. The rest of the posts are interesting in respect to the back seat driver's perspective. In the end it will probably be written in C++, and the programmer probably has unlimited time and money or this possible performance problem would not have been a concern of his.
-----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Stoyan Damov Sent: Tuesday, October 31, 2006 2:39 AM To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Subject: Re: [ADVANCED-DOTNET] Efficient .NET Networking J, while I agree completely w/ you and Knuth ;), there are certain types of software applications where "if you fail to design for performance, you're performing a design failure". Choosing the platform, language and technology is part of the design. We don't know what Itay is building and can only assume. If he's building the transport layer of real-time market data platform and aims for the lowest possible latency, GC might matter. If I were Itay I'd build a simple server and client in both C++ (using ACE Proactor) and .NET (System.Net.Sockets), and measure their throughput and latency. It would take a day tops and would be worth it. If you simply start building the software w/ any language/technology at the time you're finished w/ and have a working software it might be impossible to make it fast - that's my point. Btw, memory allocation still matters, especially in the unmanged world. Last time I checked, a message passing app started running 30% faster when we replaced the dumb general purpose memory allocator w/ Hoard. Also, having a 8-way machine won't help you if you've designed your app as a single threaded one, or create a dumb thread pool, or lock like crazy (or use the general-purpose (C++) memory allocator, which will do that for you)... On 10/31/06, J. Merrill <[EMAIL PROTECTED]> wrote: > (I re-read this just before sending, and I think it's necessary to say that I don't intend this to be treated as a personal attack. When I say "you" I'm not trying to single you out personally. Treat of it as "those who have these ideas" or some such. I do not intend to attack anyone personally, but I am willing to "take on" what I think are baseless concerns.) > > I think you're worried about (what I think are) non-issues without any evidence that they're actually issues. It's not as though memory allocation in .Net is a performance pig; it's a few assembler instructions (an add followed by a compare to see if a GC is needed). > > When your network hardware and software stack is so fast and efficient that it makes your "high performance communications" code a bottleneck, maybe you'll need to re-write. However, keep in mind that any "high performance computer" today is literally 100 times faster than the fastest machine available only a couple of years ago -- and that's before the server is a multiple-processor box with 4 or 8 quad-core processors, like it will be in 6-12 months. (The laptop I'm writing this on has 4 times the RAM of the desktop I've been writing software on for years.) How much faster must the hardware get before it's time to stop worrying about the performance of the software you didn't write and worry instead about finishing the software that you're being asked to write? > > Who said "first make it work, then make it fast"? I don't remember, but that was a good thought. Are you in the "performance tuning" part of your application life-cycle? Are there no user-visible features left to build? > > The whole idea of the .Net framework (and every other bit of "software layering" that we deal with) is to reduce the time, effort, and low-level knowledge it takes to produce the desired software. You do that by giving up some control over the nitty-gritty in order to work, and hopefully think, at a higher level. > > "Premature optimization is the root of all evil" was said by people much smarter than I. Keep it in mind, now that the machines are so unbelievably much faster than they were when TCP/IP networking, garbage collectors, dynamic memory management (and on and one) were first implemented. Back then, perhaps you had to worry about every memory allocation. Today, you're wasting the money of the people who are paying you if you don't start working on the problems they think they're paying you to solve and ignore the problems that they think someone has already solved and provided as tools for you to use. > > At 04:53 AM 10/30/2006, Itay Zandbank wrote (in part) > >The answer may very well be "for high performance communications, use C++ and the Windows API", I'm just hoping it's not. > > > J. Merrill / Analytical Software Corp Cheers, Stoyan =================================== This list is hosted by DevelopMentor(r) http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
