|
Interesting. Did you get to the bottom of this?
.NET is fast, so something is amiss. I don't know about web stuff like V8, but this looks like code that runs on the CPU rather than the GPU. Pete might be onto something with the number of object instantiations, but these are stupidly fast. It's the GC that comes later that slows things down. I notice you swapped the class for a struct - did that make any difference?
Regards,
Rob Philpott.
|
|
|
|
|
yes there was huge increase (~50%) but still far from Java performances. And also it's not very fair to use it for the benchmark, as the other VM does not have values types (ok, I see the argument of using the best of each language).
|
|
|
|
|
I've found your big holdup. It's this line:
if(x==639) Document.canvas.Refresh(); Basically, you're forcing the user control to refresh its content here, which is slowing you down because you're refreshing on the same thread that you're performing your calculations on.
|
|
|
|
|
I just downloaded your code and ran the C# version. Running the Debug version under Visual Studio took 54 seconds. Running the Release version under Visual Studio took 43 seconds. Running the Release version from the command line took 14 seconds.
Part of the problem here is that you are running everything on the UI thread, so there is nothing at all being offloaded to the GPU.
|
|
|
|
|
I tried calculating bitmap rows on a separate thread, but it was ~2% slower (I guess for the thread preparation overhead). So the problem isn't the UI thread.
I did it sequentially (one single separate thread, no multiple threads) to make it comparable with the other versions (Java, Dart ecc..).
|
|
|
|
|
The problem IS the UI thread. If you don't believe me, which you plainly don't, comment that line out and run it again. You're doing a bare bones GDI implementation here, and this is notoriously inefficient in C#. As this is something that no sane person would ever do in C# using this pattern, you really aren't comparing like for like here. The normal way to do this would be to use unsafe code and standard techniques such as LockBits.
|
|
|
|
|
Pete O'Hanlon wrote: If you don't believe me, which you plainly don't, comment that line out and run it again.
I did that, and also made a better thing: I made a Console version of the program, where all the calculations are done "in memory". As expected, it didn't gain much: from 33 secs it went down to 31 seconds only (in this actual machine).
For me this clearly tells it's not a graphic issue, and it's not a UI thread issue.
|
|
|
|
|
And yet when I took your existing code and commented out 1 line - the Refresh line, it ran in less than 10 seconds. Oh look, a graphics and UI issue - could it possibly be that I know something of what I'm talking about, having dealt with the various vagaries of this stuff for nigh on 14 years.
It's easy for you to replicate this - comment out the Refresh call on your canvas and run your app in Release mode from the command line (don't run it inside Visual Studio).
|
|
|
|
|
Sorry, I don't want to seem crazy or stubborn, but I get different numbers here!
This one is taken with commenting out all the .Refresh() calls and run out of Visual Studio:
Picture 1: no refresh
in this other you can see the original (no comments on refresh and run out of VS) and the Console version (run from prompt):
Picture 2: original + console side by side
So to sum up:
- Original in UI thread: 18 secs
- Refresh commented: 17 secs
- Console 16: secs
these are my numbers.
|
|
|
|
|
I get about 10s on my machine with the .NET version -- have not tested the others, but 40 seconds seems way too long. I've actually written a ray tracer in C# before, and it could render images very quickly (it included advanced features like transparency as well). There is definitely something wrong.
I see a bunch of odd things that could be making this much less efficient than it could be:
* Color should probably be a struct instead of class (but measure and find out)
* The stopwatch class uses DateTime, which is really, really bad for measuring small amounts of time. It's slow and inprecise for this usage. Use System.Diagnostics.Stopwatch instead.
* Outputting to the console is slow -- even at once per row, it might be enough to skew the timing.
** Related: calling String.Format is expensive. Might not matter for this application.
* Profiling this shows that the most expensive method is Sphere.Intersect. I suspect it's just the math and the fact that you're calling it so much.
* You can optimize the Sphere.Intersect method a bit more. You can store a precalculated radiusSquared value. You can put off the call to Math.Sqrt by squaring both sides of the equation and still checking against 0. You only need to cal Sqrt when distance > 0.
* a bunch of foreach statements. In many cases, these can be transformed into for-loops by the JIT, but not always. Enumerator.MoveNext is showing up in the profile, so consider changing these.
Lastly, what is the CPU usage like during each version of the program? Could other versions be automatically parallelizing some of the loops? Seems like a long shot, but I don't know.
And yeah, I know it's an obvious plug, but I've written an entire book on .NET performance. See my signature. It can teach you a bunch of stuff like the above, but more importantly, how to measure and diagnose these problems.
In the end, .NET is really just x86/x64 code running on a processor just like anything else. To see such a wide disparity in running times, especially compared to javascript is a red flag that something major is wrong.
modified 4-Sep-14 12:23pm.
|
|
|
|
|
thank you for your reply it's really appreciated 
Agree totally with your considerations, there is lot to optimize in the code, but still that doesn't explain why the Java or the Dart version are much faster (and they don't even have structs). One could point out that it's like comparing apples vs oranges, but Java and C# are very close sharing common traits to the point that the two source codes can be compared line by line. So what's exactly the reason why .NET is so slow here? Do you have an idea?
|
|
|
|
|
Hey guys recently I've been wondering about which would be the best way to implement a localization system based on namespaces.
Let's say that for some reason I wanted to use a few source code files in many different projects, and for some other reason I don't want or cannot build a DLL out of them (which of course would be the "right" way to do this). Let's also say I need to localize that code in a few different languages. Also, the files I'll be sharing all use the same namespace.
Now, the standard localization technique in Visual Studio works real fine and is very easy to maintain and update within the IDE, but it's all tied to the project's main assembly name. So, while I could just copy and paste over all the necessary localization strings for my shared files each time, and prefix all the relevant localized string names with my namespace ID, that would be clumsy and error prone.
I was wondering if there was a way to build up some DLL or resource files and just bundle them up with the source code to be shared. I've been considering for example building up a few resource files within the IDE, using file names that include the namespace and the different culture IDs, and then implementing a custom resource manager using ResXResourceReader or something similar.
Any other ideas ?
P.S.: we are talking C# here.
In theory, there is no difference between theory and practice, but not in practice. - Anonymous
A computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are, in short, a perfect match. - B. Bryson
|
|
|
|
|
You are trying a really weird way of code re-use.
In my opinion, you have to update your tool which you use for your current code sharing such that it can handle the resources also.
|
|
|
|
|
I'm not discussing the way to re-use code here. As I said, I'm perfectly aware the "right" way to do this is by using DLLs to share code.
I'll take your answer as "I don't think what you propose can/should be done". 
In theory, there is no difference between theory and practice, but not in practice. - Anonymous
A computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are, in short, a perfect match. - B. Bryson
|
|
|
|
|
Moreno Airoldi wrote: but it's all tied to the project's main assembly name
How so?
You can add a *.res file to a project, and name it as you like. You can then add resources there. You could name it after your class, having a *.cs and .res file for it (and optionally a .xaml/.cs.Designer file).
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Of course you can andd a .res file to a project and name it as you like.
What I'm asking is a whole different thing.
I'll try to be more specific.
In a Visual Studio solution, the standard way to add localization is by creating a set of resource files named "Localization" plus the culture ID. So for example you will have "localization.resx", "Localization.it.resx", "Localization.de.resx" for your default language, Italian and German, and so on.
Then, you can use a ResourceManager to get your localized strings:
ResourceManager LocalizationResourceManager = new ResourceManager(Assembly.GetExecutingAssembly().GetName().Name + ".Localization", Assembly.GetExecutingAssembly());
...
string LocalizedString = LocalizationResourceManager.GetString(ResourceName, Culture);
Now this is perfectly fine and of course does not stop me from doing what I need to, even if I share code by copying over source files. But as you see clearly in the ResourceManager constructor, it's tied to the assembly name, simply because the resource file is compiled together with the project's main assembly.
I was simply wondering if there was a way to somehow change this so that the DLLs compiled from the resource files will be tied to a different namespace.
What I'm asking basically is: can I have VS compile a resource file in a project and not automatically assign the resources to the project's main namespace ?
Hope it's more clear now.
EDIT: Just to be even more clear - nothing stops me from naming my resource files "Localization_MYNAMESPACE" or something similar, that's actually what I would most likely do (haven't actually tried this but I'm pretty sure there is no reason why it should not work). I'm just wondering if there are different approaches, and found it quite interesting to investigate how one can configure the way the compiler acts on resource files.
In theory, there is no difference between theory and practice, but not in practice. - Anonymous
A computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are, in short, a perfect match. - B. Bryson
|
|
|
|
|
Moreno Airoldi wrote: but it's all tied to the project's main assembly name
I kind of doubt that. I would suspect that although that is one way to use it there are others.
Moreno Airoldi wrote: Let's also say I need to localize that code in a few different languages.
You don't localize code - you localize applications. There will be differences otherwise little point in having different applications. If you have common blocks that need to be translated then keep them in their own files and then, if necessary, write a tool that merges them in the build process as a pre-build step.
|
|
|
|
|
jschell wrote: You don't localize code - you localize applications.
"Or components thereof".
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
jschell wrote: write a tool that merges them in the build process as a pre-build step
You kind of put the finger on exactly what I was thinking of. 
However, it's most likely not worth it to develop a specific tool for that, since it would still be easier to manage the localized resources semi-manually instead of having to keep the tool up to date and so on.
In theory, there is no difference between theory and practice, but not in practice. - Anonymous
A computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are, in short, a perfect match. - B. Bryson
|
|
|
|
|
Hi All,
As per the title of this post... I have developed a small Dot Net WinForms C# application which uses a SQL Server Express 2008 as the database to link to which I would like to sell.
What I'd like to do is use some remote hosting service so I can put up the app and DB and give customers a trial of it before they commit to paying for it at which point I can roll it out to their own network or leave them with the hosted service if they don't have their own network.
As I've never deployed an app to a cloud based host, can some kind person give me some recommended cloud hosts who won't charge too much monthly and where I can load my Winforms App (dot Net 4.5) and I can install SQLServer Express 2008?
Basically the host will need to support dot net framework 4.5 (or I have the option to put it on myself
) and SQL Server Express 2008 (or I have the option to put it on myself). The end-user would ideally access the app via a VM.
I've had a look at RackSpace but I'm unsure of which of their options I would need...
Many, many thanks.
-- modified 28-Aug-14 3:52am.
|
|
|
|
|
Hi, I find lots about a 64 bit app calling a 32 bit, but I am struggling with the reverse and would like to start a discussion about this. The scenario is that there are legacy calling applications that call our unmanaged C++ dll's. Our product is graphics intensive, and we could greatly benefit from the increased memory a 64 bit app would give.
So first is is it possible? Fortunately we have an intermediate DLL that interfaces the calling apps to our DLL's. The callers are a variety of languages/environments, but are all 32 bits at this time. The thought is to first get our program compiled into 64 bits (that's another discussion), but assuming that is accomplished, I was thinking of wrapping our program with .Net, and then modifying the calls to the intermediate DLL (32 bits) to instantiate us as a 64 bit dll. Am I on the right track? What issues should I be concerned with? What if the system is 32 bit windows vs 64 bit windows?
Many thanks in advance.
|
|
|
|
|
If you use some kind of remoting you can have one process in 64 bit, even if it is seen as a library, and another one in 32 bit calling it.
You can use .NET remoting or WCF to do the job.
You can't really load 32-bit and 64-bit DLLs in the same process.
|
|
|
|
|
Hi all,
I need the following methods for login module and reset-password module.
a) Salted MD5 technique in „authentication or login module‟ and
b) MD5 hash technique in „change password‟ and „reset password‟ modules.
and how it should work, I write the description below.
When a client requests for the login page, the server should generates a random number, the salt, and sends it to the client along with the page. A JavaScript code on the client computes the MD5 hash of the password entered by the user. It then concatenates the salt to the hash and re-computes the MD5 hash. This result is then sent to the server. The server picks the hash of the password from its database, concatenates the salt and computes the MD5 hash. If the user entered the correct password these two hashes should match. The server compares the two and if they match, the user is authenticated.
Any reference any link which does the same.
|
|
|
|
|
Where are you stuck?
And more important: are you sure you understand the procedure correctly? Never heard it in such a strange way...
|
|
|
|
|
Simple answer: don't.
You're adding a password to the site because you want to protect the user's data. You want to add client-side hashing of the user's password in case someone is intercepting the traffic between the client and the server. But if someone is intercepting the traffic, then they can just read the user's data as they request it. They can also hijack the user's session and authentication cookies, and perform whatever action they want on your site.
To properly protect the communication between the client and the server, you need to install an SSL certificate and ensure that your site is only accessible over HTTPS. (Depending on the nature of your site, you might be able to get away with a free certificate from StartSSL[^].)
Once your site is protected with SSL, you don't need to worry about hashing the password on the client-side.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
