While risking to be of too much annoyance, I would
like to persist on topic slightly further:
1. I'm using aes-128-cfb for media streaming and I
think it's rather good choice for the job.
2. Currently, aes-128-cfb works slower than it can (by
more than 20% and often beyond that) and suffers from
Hi,
3. From my experience with gcc on powerpc, gcc handles
large unaligned load/stores correctly by splitting
them (sometimes unnecessary), but the code remains
correct and in working order.
Just as a counter example, on SUN, unaligned load stores
just crash. Reliably and every time,
In message [EMAIL PROTECTED] on Thu, 25 May 2006 22:50:15 -0700 (PDT), Alex
Dubov [EMAIL PROTECTED] said:
oakad I thought all major compilers have sort of long long,
oakad didn't them? After all, emulated long long is still
oakad only two integer xors as opposed to 8 with char.
If you look in
Ok. How about now?
--- Richard Levitte - VMS Whacker
[EMAIL PROTECTED] wrote:
In message
[EMAIL PROTECTED]
on Thu, 25 May 2006 22:50:15 -0700 (PDT), Alex Dubov
[EMAIL PROTECTED] said:
oakad I thought all major compilers have sort of
long long,
oakad didn't them? After all, emulated long
Hello Alex,
Friday, May 26, 2006, 9:50:15 AM, you wrote:
AD I thought all major compilers have sort of long long,
AD didn't them?
I'm on QNX4 with Watcom C v10.6B which has neither int_64 nor long
long.
So, I'm very anxious about not being able to keep my port current
after such improvements...
On Fri, 26 May 2006 14:32:36 +0400, [EMAIL PROTECTED] wrote:
Hello Alex,
Friday, May 26, 2006, 9:50:15 AM, you wrote:
AD I thought all major compilers have sort of long long,
AD didn't them?
I'm on QNX4 with Watcom C v10.6B which has neither int_64 nor long
long.
So, I'm very anxious about not
Hello Brian,
Friday, May 26, 2006, 5:55:34 PM, you wrote:
BH Can't you use OpenWatcom? It's had long long for some time and
BH appears to still support QNX.
Indeed it knows QNX4 still. The problem is that OW is not ported to
QNX4 yet (and never will, I'm afraid). So it takes to cross-compile on
Thus spake Alex Dubov [EMAIL PROTECTED]
Ok. How about now?
I'm curious if there's a significant performance difference between using
u32 and u64; the former should be portable to all supported platforms, and
may make the latter unnecessary.
Plus, if we're going to go that route, we should
Ok. How about now?
Subject to SIGBUS on most platforms. It's easy to carry away and score
on x86 and render support for other platforms void, isn't it? I mean do
mind unaligned access!
I'm curious if there's a significant performance difference between
using u32 and u64; the former should
Thus spake Andy Polyakov [EMAIL PROTECTED]
Ok. How about now?
Subject to SIGBUS on most platforms. It's easy to carry away and score on
x86 and render support for other platforms void, isn't it? I mean do mind
unaligned access!
Ah, that may have been why I didn't fix that code to use u32.
I'm very sorry, that's not as easy as I thought. I
hope this one should work as expected.
--- Alex Dubov [EMAIL PROTECTED] wrote:
Oops, minor correction.
--- Alex Dubov [EMAIL PROTECTED] wrote:
Hello.
I was working on apache project using openssl and
found that using larger integers
On Thu, 25 May 2006, Alex Dubov wrote:
Hello.
I was working on apache project using openssl and
found that using larger integers in cfb128 xor
improves performance by more than 50% in most
cases.
There are no drawbacks whatsoever, except the look.
...
--- aes_cfb.c.prev
I thought all major compilers have sort of long long,
didn't them? After all, emulated long long is still
only two integer xors as opposed to 8 with char.
--- Tim Rice [EMAIL PROTECTED] wrote:
On Thu, 25 May 2006, Alex Dubov wrote:
Hello.
I was working on apache project using openssl
13 matches
Mail list logo
