On 01/30/09 02:39 PM, Elad Lahav wrote:
>> I don't think that follows.
>>
>> You've put together a compute intensive benchmark - so the constraint
>> on that code is how many instructions per second you can execute.
>>
>> It doesn't follow that it is analogous to a webserver. A webserver is
>>
On Fri, 30 Jan 2009, Elad Lahav wrote:
>> Ahh.. is there something specific that leads you to believe it's
>> related to integer performance?
> Definitely not. I just wanted to get some basic notion of the
> relative "power" of the machine in a benchmark that was supposed to
> be biased in favo
> I don't think that follows.
>
> You've put together a compute intensive benchmark - so the constraint on
> that code is how many instructions per second you can execute.
>
> It doesn't follow that it is analogous to a webserver. A webserver is
> not generally so compute intensive. If there's
On 01/30/09 01:40 PM, Elad Lahav wrote:
>> I'm not sure that I follow your argument. The T1000's architecture
>> favors workloads that have many parallel tasks that involve data
>> throughput. The Xenon is going to have a better showing for straight
>> number-crunching work. If your webserver
> > I'm not sure that I follow your argument. The T1000's architecture
> > favors workloads that have many parallel tasks that involve data
> > throughput. The Xenon is going to have a better showing for straight
> > number-crunching work. If your webserver benchmark is trying to measure
> > the
> I'm not sure that I follow your argument. The T1000's architecture
> favors workloads that have many parallel tasks that involve data
> throughput. The Xenon is going to have a better showing for straight
> number-crunching work. If your webserver benchmark is trying to measure
> the throughpu
On Fri, Jan 30, 2009 at 04:14:50PM -0500, Elad Lahav wrote:
> > Ahh.. is there something specific that leads you to believe it's
> > related to integer performance?
>
> Definitely not. I just wanted to get some basic notion of the relative
> "power" of the machine in a benchmark that was supposed t
> Ahh.. is there something specific that leads you to believe it's
> related to integer performance?
Definitely not. I just wanted to get some basic notion of the relative "power"
of the
machine in a benchmark that was supposed to be biased in favour of the
architecture. Since
the quad-core Xeo
On Fri, Jan 30, 2009 at 2:49 PM, Elad Lahav wrote:
>> Getting back to the original problem, I'm wondering if a more detailed
>> explanation of what is trying to be measured and why might help. Is it
>> crypto performance (in which case, the crypto apis might be useful to
>> look at), or something
> Getting back to the original problem, I'm wondering if a more detailed
> explanation of what is trying to be measured and why might help. Is it
> crypto performance (in which case, the crypto apis might be useful to
> look at), or something else?
The root of the issue was my attempt to compare in
On 01/30/09 12:33 PM, Jason King wrote:
> Getting back to the original problem, I'm wondering if a more detailed
> explanation of what is trying to be measured and why might help. Is it
> crypto performance (in which case, the crypto apis might be useful to
> look at), or something else?
Detai
On Fri, Jan 30, 2009 at 2:21 PM, Darryl Gove wrote:
>
>
> On 01/30/09 12:10 PM, Elad Lahav wrote:
>>> I think the point was that with 64-bit ints you might be able to use a
>>> different algorithm, or perhaps require fewer iterations and converge
>>> faster.
>> I guess that part of the answer is t
On 01/30/09 12:10 PM, Elad Lahav wrote:
>> I think the point was that with 64-bit ints you might be able to use a
>> different algorithm, or perhaps require fewer iterations and converge
>> faster.
> I guess that part of the answer is that you would be hard-pressed to
> find code that preserve
> I think the point was that with 64-bit ints you might be able to use a
> different algorithm, or perhaps require fewer iterations and converge
> faster.
I guess that part of the answer is that you would be hard-pressed to find code
that
preserves its 32-bit semantics when compiled as 64 bits,
On 01/30/09 10:52 AM, Elad Lahav wrote:
>> Just to state what might be obvious (but then again maybe not), it
>> sounds like the original expectation was that in 64-bit mode, the
>> 64-bit integers would be used to reduce the number of operations
>> needed for a given input size. However, depend
On Fri, 30 Jan 2009, Elad Lahav wrote:
>
> My expectation was that something like the following loop would run faster on
> 64 bit:
>
> unsigned long array[ARR_SIZE];
> for (i = 0; i < ARR_SIZE; i++) {
> array[i] ^= (unsigned long)SOME_CONSTANT;
> }
>
> However, the two previous replies seem
> Just to state what might be obvious (but then again maybe not), it
> sounds like the original expectation was that in 64-bit mode, the
> 64-bit integers would be used to reduce the number of operations
> needed for a given input size. However, depending on how the
> libgcrypt code is written, th
On Fri, Jan 30, 2009 at 11:20 AM, Darryl Gove wrote:
> Hi,
>
> 64-big gives you a larger address space. The downside of this is that
> pointers and longs go from 32-bits to 64-bits. This results in a slight
> drop in performance.
>
> So in general you should probably expect a 64-bit application to
Some time ago I reported on problems I had with a simple TCP benchmark running
on a T1000.
I was able to solve the problems, and now have a fairly sturdy application for
testing raw
TCP performance.
The testbed includes an 8-core T1000 with 4 Intel Gigabit NICs. On Linux, the
maximal
through
Hi,
64-big gives you a larger address space. The downside of this is that
pointers and longs go from 32-bits to 64-bits. This results in a slight
drop in performance.
So in general you should probably expect a 64-bit application to run
slightly slower than the same application compiled 32-bit.
I wrote a simple benchmark that takes a 1 GB file and encrypts it in parallel
using
libgcrypt. On an 8-core T1000, using 32 threads, the benchmark completed in ~45
seconds
(after warming the file cache, of course).
I then recompiled everything (libgcrypt and the application) in 64 bits, and
wa
21 matches
Mail list logo
