I know the workunits are different sets so they can't be compared directly, but that should give you some idea. :-)
Rob...
Sorry for not being completely clear on my intent... :-) I see you have a join date that's very recent, so here's a very basic explanation of the history:
Some time ago, back when the S5R2 search was in progress (we are currently on S5R3), it was discovered that AMD users were "awarded" with a performance penalty due to how compilers treated the string "AuthenticAMD" existing in the science application's executable. To get around that issue, one can take a hex editor and open the executable and change the string to something else; for example - "AuthenticABC". This would give another speed boost to AMD processors, as the slower performing code that was run when the application encountered an AMD processor would now not be executed.
What I'm about to try to find out is if that type of situation exists now. It wasn't needed on S5R3 until this 4.32 version, as the AuthenticAMD string was not in the binary. It gets in there based on the compiler being used, and for this application an older version of the Microsoft compiler was used. The project staff cannot do this editing themselves (legalities and all), but they did not complain about it being done by us volunteers on our own copies in the past...
That said, if they would like to complain about it, they might want to speak up now... ;-)
I know the workunits are different sets so they can't be compared directly, but that should give you some idea. :-)
Rob...
Sorry for not being completely clear on my intent... :-) I see you have a join date that's very recent, so here's a very basic explanation of the history:
Some time ago, back when the S5R2 search was in progress (we are currently on S5R3), it was discovered that AMD users were "awarded" with a performance penalty due to how compilers treated the string "AuthenticAMD" existing in the science application's executable. To get around that issue, one can take a hex editor and open the executable and change the string to something else; for example - "AuthenticABC". This would give another speed boost to AMD processors, as the slower performing code that was run when the application encountered an AMD processor would now not be executed.
What I'm about to try to find out is if that type of situation exists now. It wasn't needed on S5R3 until this 4.32 version, as the AuthenticAMD string was not in the binary. It gets in there based on the compiler being used, and for this application an older version of the Microsoft compiler was used. The project staff cannot do this editing themselves (legalities and all), but they did not complain about it being done by us volunteers on our own copies in the past...
That said, if they would like to complain about it, they might want to speak up now... ;-)
Hope this helps explain what I'm looking for...
Brian
Oh right. With you now, and thanks for the explanation.
I haven't done hex editing for a while, but I just looked through the binary with a hex editor and could not find either 'AMD' or 'AuthenticAMD'. So good news I think...
I haven't done hex editing for a while, but I just looked through the binary with a hex editor and could not find either 'AMD' or 'AuthenticAMD'. So good news I think...
You might want to check to make sure you looked at the main application and not the graphics executable... The string is there in mine. If it is not in yours, that would be most interesting...
You might want to check to make sure you looked at the main application and not the graphics executable... The string is there in mine. If it is not in yours, that would be most interesting...
Thanks for the warning. I'll have another look and get back to you on that.
You might want to check to make sure you looked at the main application and not the graphics executable... The string is there in mine. If it is not in yours, that would be most interesting...
You might want to check to make sure you looked at the main application and not the graphics executable... The string is there in mine. If it is not in yours, that would be most interesting...
It's in mine, at Hex address 00110de4 - shortly after exp2 exp10 log2, and before PATH runtime error TLOSS error SING error.
File is einstein_S5R3_4.32_windows_intelx86.exe, dated 12 Feb 2008 at 21:23, downloaded 13 Feb 2008 18:51 (I'm in UTC timezone).
Ah - the actual string is "AuthenticAMD". Were you doing a case-sensitive search?
Curiouser and curiouses. I searched for 'AuthenticAMD' (without the quotes) and it wasn't found. My file is date and time-stamped the same as yours, and has the same version number.
I have to go to work in a few minutes, so I can't do anything now. I'll try a different hex editor tomorrow.
>It's in mine, at Hex address 00110de4 - shortly after exp2 exp10 log2, and before >PATH runtime error TLOSS error SING error.
>File is einstein_S5R3_4.32_windows_intelx86.exe, dated 12 Feb 2008 at 21:23, >downloaded 13 Feb 2008 18:51 (I'm in UTC timezone).
>Ah - the actual string is "AuthenticAMD". Were you doing a case-sensitive search?
Maybe I'm picky, but while I agree with
- the address - "00110de4"
- the file name "einstein_S5R3_4.32_windows_intelx86.exe"
I have a different date code - 2/25/2008 11:21 AM. The date code - 12 Feb 2008 at 21:23 - is for the graphics file.
I've been using "Groovy Hex Editor" and it has found "AuthenticAMD" in the app.
You might try searching just for "AMD". I don't know why that should work but sometimes just doing things a different why does wonders.
I have a different date code - 2/25/2008 11:21 AM. The date code - 12 Feb 2008 at 21:23 - is for the graphics file.
I still had the original downloaded .zip file. I took a clean copy from that, and reported the datestamp.
I've just downloaded the .zip again. Both the worker application, and the graphics application, still have the datestamp "12/02/2008 21:23" - which is ambiguous, but in my corner of the globe (sic!) means 12 February etc.
RE: I know the workunits
)
Rob...
Sorry for not being completely clear on my intent... :-) I see you have a join date that's very recent, so here's a very basic explanation of the history:
Some time ago, back when the S5R2 search was in progress (we are currently on S5R3), it was discovered that AMD users were "awarded" with a performance penalty due to how compilers treated the string "AuthenticAMD" existing in the science application's executable. To get around that issue, one can take a hex editor and open the executable and change the string to something else; for example - "AuthenticABC". This would give another speed boost to AMD processors, as the slower performing code that was run when the application encountered an AMD processor would now not be executed.
What I'm about to try to find out is if that type of situation exists now. It wasn't needed on S5R3 until this 4.32 version, as the AuthenticAMD string was not in the binary. It gets in there based on the compiler being used, and for this application an older version of the Microsoft compiler was used. The project staff cannot do this editing themselves (legalities and all), but they did not complain about it being done by us volunteers on our own copies in the past...
That said, if they would like to complain about it, they might want to speak up now... ;-)
Hope this helps explain what I'm looking for...
Brian
RE: RE: I know the
)
Oh right. With you now, and thanks for the explanation.
I haven't done hex editing for a while, but I just looked through the binary with a hex editor and could not find either 'AMD' or 'AuthenticAMD'. So good news I think...
Rob.
RE: I haven't done hex
)
You might want to check to make sure you looked at the main application and not the graphics executable... The string is there in mine. If it is not in yours, that would be most interesting...
RE: You might want to check
)
Thanks for the warning. I'll have another look and get back to you on that.
Rob.
RE: You might want to check
)
I checked again and this is what I got:
File: einstein_S5R3_4.32_windows_intelx86.exe
'AuthenticAMD': no occurrences
'Authentic': 5 occurrences
offset 1045712: authenticator
offset 1045728: authenticator
offset 1046784: authenticator
offset 1067872: authentication
offset 1069328: authentication
I honestly cannot find the vendor string. :-/
Rob.
RE: offset 1045712:
)
Try looking starting at address 110DE4 (hex), 1117668 (decimal).
I can see the ones you found, and the addresses translate within a few bytes, so I think you should see this one.
I used Textpad.
RE: RE: You might want to
)
It's in mine, at Hex address 00110de4 - shortly after exp2 exp10 log2, and before PATH runtime error TLOSS error SING error.
File is einstein_S5R3_4.32_windows_intelx86.exe, dated 12 Feb 2008 at 21:23, downloaded 13 Feb 2008 18:51 (I'm in UTC timezone).
Ah - the actual string is "AuthenticAMD". Were you doing a case-sensitive search?
RE: It's in mine, at Hex
)
Curiouser and curiouses. I searched for 'AuthenticAMD' (without the quotes) and it wasn't found. My file is date and time-stamped the same as yours, and has the same version number.
I have to go to work in a few minutes, so I can't do anything now. I'll try a different hex editor tomorrow.
>It's in mine, at Hex address
)
>It's in mine, at Hex address 00110de4 - shortly after exp2 exp10 log2, and before >PATH runtime error TLOSS error SING error.
>File is einstein_S5R3_4.32_windows_intelx86.exe, dated 12 Feb 2008 at 21:23, >downloaded 13 Feb 2008 18:51 (I'm in UTC timezone).
>Ah - the actual string is "AuthenticAMD". Were you doing a case-sensitive search?
Maybe I'm picky, but while I agree with
- the address - "00110de4"
- the file name "einstein_S5R3_4.32_windows_intelx86.exe"
I have a different date code - 2/25/2008 11:21 AM. The date code - 12 Feb 2008 at 21:23 - is for the graphics file.
I've been using "Groovy Hex Editor" and it has found "AuthenticAMD" in the app.
You might try searching just for "AMD". I don't know why that should work but sometimes just doing things a different why does wonders.
Joe B
RE: I have a different date
)
I still had the original downloaded .zip file. I took a clean copy from that, and reported the datestamp.
I've just downloaded the .zip again. Both the worker application, and the graphics application, still have the datestamp "12/02/2008 21:23" - which is ambiguous, but in my corner of the globe (sic!) means 12 February etc.