Hi,
That makes sense. I was just quite surprised at the time that the methods
were not being inlined as they were only simple maths operations. I checked
monodis for one of the methods and it turned out to be 8 IL instructions,
which is probably 24 bytes, which would explain why it wasn't
I just checked the R01/R02 methods and they both have 20 IL instructions
with 22 bytes of IL code, so this is pretty much a corner case. However the
Ch method that you mention has a mere 9 IL instructions and only 9 bytes of
IL code, so this does not explain why it doesn't get inlined if the
Hi,
On my amd64 machine, that method does get inlined. You can check the
output of mono -v -v -v -v for INLINE lines to see what gets inlined.
Zoltan
2008/4/30 Alan McGovern [EMAIL PROTECTED]:
This method does not get inlined:
private uint Ch (uint u, uint v, uint w)
Hi,
The method ch does get inlined alright:
INLINE START 00B23210
System.Security.Cryptography.SHA256Managed:ProcessBlock (byte[],int) -
System.Security.Cryptography.SHA256Managed:Ch (uint,uint,uint)
created temp 24 of type System.UInt32
method to IR System.Security.Cryptography.SHA256Managed:Ch
Hi,
I get an 10% performance boost (give or take). Surely if the method was
getting inlined, that wouldn't be the case. Could it be that the temp
variables (25-28) aren't being dropped and there is excess variable copying
going on?
Yes, the current JIT is not very good at getting rid of
Hello,
This patch seems to be the cause of the build failures on Win32:
http://mono.ximian.com/monobuild/python/monobuild.py/packagestatus?platform=win-4-i386package=monoHEAD_or_RELEASE=HEAD
svn rev 102051 does not seem to cause the error on my machine, while svn rev
102052 causes the crash
This fixes the problem I previously posted regrading NetworkStream Read/Write
Timeout properties.
Index: Socket.cs
===
--- Socket.cs (revision 101631)
+++ Socket.cs (working copy)
@@ -1166,9 +1166,12 @@
