ation never hit more than 20% on a bread-and-butter workstation.
-Original Message-
From: Discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Itay Zandbank
Sent: Tuesday, October 31, 2006 4:31 PM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DO
Not a personal attack also, but when I hear/read something similar to
what you said: "Keep it in mind, now that the machines are so
unbelievably much faster than they were when[...]", my first thought
is always "why then applications are not also orders of magnitude
faster".
I leave the answer to
CED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Efficient .NET Networking
Thanks for your comment (and those of others).
The problem I'm facing is more of a conceptual problem than a
real-world problem. We don't have any servers that require very high
throughput and very
Thanks for your comment (and those of others).
The problem I'm facing is more of a conceptual problem than a
real-world problem. We don't have any servers that require very high
throughput and very low latency written in .NET - we stick to C++ for
those. I was hoping that next time around, we c
bject: 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 i
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 on
(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 personal
> Sent: 30 October 2006 09:53
> To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
> Subject: Re: [ADVANCED-DOTNET] Efficient .NET Networking
>
> > buffer[50] = (byte) value;
> > buffer[51] = (byte) (value >> 8);
> > buffer[52] = (byte) (value >> 0x10)
> -Original Message-
> From: Discussion of advanced .NET topics.
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Itay Zandbank
> Sent: 30 October 2006 09:53
> To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
> Subject: Re: [ADVANCED-DOTNET] Efficient .NET Networking
>
>
I just noticed TASE - if you're building a market data transport
layer, you'd better *not* use .NET because the latency will be
unpredictable w/ the GC and you'll end up w/ not-so-real-time data ;)
Although, I don't really know how fast TASE streams and it might not
be that bad at all. If you're
> buffer[50] = (byte) value;
> buffer[51] = (byte) (value >> 8);
> buffer[52] = (byte) (value >> 0x10);
> buffer[53] = (byte) (value >> 0x18);
Yes, I can do that for integers and longs, but I can't really do that
for doubles. And of course, the C *(int *)(buffer+offset) = myI
While I understand your complaints, unless your product is a network
layer component(s) I can bet my ass (and I'm not gay! :P) that copying
memory around won't be a performance issue. WRT memory allocation -
well, this will most certainly run faster than native code because:
a) you don't track mem
gt;> 0x10);
buffer[50] = (byte) (value >> 0x18);
Cheers
Simon
> -Original Message-
> From: Discussion of advanced .NET topics.
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Itay Zandbank
> Sent: 29 October 2006 12:28
> To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Hi.
For the first time since I started working with .NET, I need to write
some TCP/IP code. While I only need to connect to a server socket, send
one handshake packet and wait for incoming data, I started having very
dim thoughts about high-performance communication servers in .NET .
First
14 matches
Mail list logo
