Timeline for Relevant performance difference C#-VB.NET - Integer Division
Current License: CC BY-SA 3.0
44 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 26, 2014 at 15:08 | history | edited | Jamal | CC BY-SA 3.0 |
Removed "curious note" as it has nothing to do with the question
|
| Feb 23, 2014 at 17:09 | history | edited | varocarbas | CC BY-SA 3.0 |
Update.
|
| Feb 23, 2014 at 13:04 | history | edited | varocarbas | CC BY-SA 3.0 |
ChrisW was right
|
| Feb 23, 2014 at 12:50 | comment | added | varocarbas | @ChrisW Just to confirm that you were completely right this time. Using the \ operator is enough to avoid any problem. My tests yesterday where done too quickly and without respecting the minimum rules to deliver accurate measurements under so demanding conditions (e.g., high number of repetitions, not running tests on form load, etc.), but honestly wasn't expecting this to be so influential (I never use this operator!!). Anyway... thanks again, I have learned quite a few things from this post and I hope that future readers will do too. | |
| Feb 23, 2014 at 12:42 | history | edited | varocarbas | CC BY-SA 3.0 |
ChrisW was right.
|
| Feb 23, 2014 at 12:34 | history | edited | varocarbas | CC BY-SA 3.0 |
ChisW was right.
|
| Feb 23, 2014 at 10:34 | history | edited | varocarbas | CC BY-SA 3.0 |
Solution
|
| Feb 23, 2014 at 10:14 | comment | added | varocarbas | @ChrisW Thanks for pointing this out. Actually, I did test the integer division operator when you firstly suggested it and observed equivalent performance to the plain VB.NET "imin + (imax - imin) / 2" one. Although you are completely right: I have to do a proper testing of all this. Now I am busy with something else; but will come back in some hours after having performed more detailed tests. | |
| Feb 23, 2014 at 10:11 | history | edited | varocarbas | CC BY-SA 3.0 |
Solution
|
| Feb 23, 2014 at 10:02 | history | edited | varocarbas | CC BY-SA 3.0 |
Solution
|
| Feb 23, 2014 at 10:02 | comment | added | ChrisW | You said, "Thus integer division is ALWAYS slower in VB.NET than in C#". But VB.NET vs C# integer division suggests that VB.NET does support an integer division operator, which is \ instead of / ... I suggest you test the performance of (and/or compare the IL of) that operator. | |
| Feb 23, 2014 at 9:53 | history | edited | varocarbas | CC BY-SA 3.0 |
Solution
|
| Feb 23, 2014 at 9:47 | vote | accept | CommunityBot | moved from User.Id=37324 by developer User.Id=258257 | |
| Feb 23, 2014 at 9:47 | history | edited | varocarbas | CC BY-SA 3.0 |
Solution
|
| Feb 23, 2014 at 0:30 | history | edited | varocarbas | CC BY-SA 3.0 |
Clarification; Post Made Community Wiki
|
| Feb 23, 2014 at 0:03 | history | edited | varocarbas | CC BY-SA 3.0 |
Update
|
| Feb 22, 2014 at 23:46 | history | edited | varocarbas | CC BY-SA 3.0 |
A small bit missed by the previous correction.
|
| Feb 22, 2014 at 23:43 | history | edited | Jamal | CC BY-SA 3.0 |
deleted 35 characters in body
|
| Feb 22, 2014 at 23:35 | history | edited | varocarbas | CC BY-SA 3.0 |
added 276 characters in body
|
| Feb 22, 2014 at 23:09 | history | edited | varocarbas | CC BY-SA 3.0 |
Small corrections.
|
| Feb 22, 2014 at 22:57 | history | edited | varocarbas | CC BY-SA 3.0 |
To be considered on-topic again.
|
| Feb 22, 2014 at 22:44 | history | reopened |
amon ChrisW syb0rg Simon Forsberg Malachi |
||
| Feb 22, 2014 at 21:45 | history | closed |
amon Comintern Simon Forsberg rolfl syb0rg |
Not suitable for this site | |
| Feb 22, 2014 at 21:26 | comment | added | varocarbas | @MarkAtRamp51 Actually, I did perform the tests and there are appreciable differences. Although it is not completely clear to me which alternative is better (i.e., the explicit conversion is a bit faster but much more instable). Also bear in mind that I have already replaced the middle calculation with the bitwise alternative to avoid all these problems and remain a lag always: until the recursion is not converted into a loop, the performances are not equal. | |
| Feb 22, 2014 at 21:14 | comment | added | Mark At Ramp51 | Casting can be a costly process, especially when you consider that you can overload implicit and explicit. Wouldn't you agree that writing proper code provides the compiler with hints that can be used to optimize the performance of the IL that it outputs? If writing better code helps the compiler output better peforming IL code, than we can argue the option strict produces better performing code. | |
| Feb 22, 2014 at 21:01 | comment | added | varocarbas | @MarkAtRamp51 Please, read my comments to Chris: Option Strict On is meant for other thing (writing proper code and thus avoid crashes). There might be a (really, really) slight difference when coming to implicit casting (one in this code); but I wouldn't ever expect this to be so influential, that is: Dim var As Integer = "5" vs. Dim Var as Integer Convert.ToInt32("5") -> in both cases the conversion would occur; so... why one option would be faster? As said to Chris: I will do some testing anyway (cannot be 100%). | |
| Feb 22, 2014 at 20:50 | comment | added | Mark At Ramp51 | Gotcha. It seems like ChrisW's answer would have some merit when reviewing the 600ms discrepancy there. Have you tried it with Option Strict On? | |
| Feb 22, 2014 at 20:47 | comment | added | varocarbas | @MarkAtRamp51 Don't misunderstand me: thanks. So far this is the most valuable information. The final goal of my question is knowing why VB.NET and not C#? but knowing what might be the exact reason will certainly be helpful. As said, I will share any relevant information (perhaps tomorrow, because now is a bit late). | |
| Feb 22, 2014 at 20:41 | comment | added | Mark At Ramp51 | Right, but it demonstrates a performance improvement by removing branches with binary arithmetic, which is a universal concept. However it certainly doesn't speak to language differences. Also, i didn't intend to answer your question, or I would have posted an answer instead of a comment. | |
| Feb 22, 2014 at 20:39 | comment | added | varocarbas | @MarkAtRamp51 This seems to point more in the right direction. Unfortunately your link is for a different language, what avoids to give an accurate answer to the question: why C# & VB.NET behave differently here? In any case, I will take a look at this link and share any relevant information. | |
| Feb 22, 2014 at 20:28 | comment | added | Mark At Ramp51 | I'm not an expert here and I didn't download your code. So this is just an idea. The performance can from version 1 of the binary search and version 2 could be partly due to less code branching in version 2. Another thing is that the recursive function requires, pushing and popping new frames on the stack. This thread on stack overflow on branch prediction may be somewhat related: stackoverflow.com/questions/11227809/… | |
| Feb 22, 2014 at 20:26 | answer | added | ChrisW | timeline score: 5 | |
| Feb 22, 2014 at 20:13 | history | edited | varocarbas | CC BY-SA 3.0 |
Clarification.
|
| Feb 22, 2014 at 20:07 | history | edited | varocarbas | CC BY-SA 3.0 |
Clarification.
|
| Feb 22, 2014 at 19:39 | answer | added | Comintern | timeline score: 5 | |
| Feb 22, 2014 at 18:31 | history | edited | varocarbas | CC BY-SA 3.0 |
I prefer VB.NET arrays like this.
|
| Feb 22, 2014 at 18:21 | comment | added | varocarbas | @Comintern Thanks. Note that there was a small error in my original post. The wrong timings are 800-900; not 7000. | |
| Feb 22, 2014 at 18:19 | history | edited | varocarbas | CC BY-SA 3.0 |
Some updates...
|
| Feb 22, 2014 at 18:07 | review | Close votes | |||
| Feb 22, 2014 at 21:45 | |||||
| Feb 22, 2014 at 18:01 | comment | added | varocarbas | @Comintern As a pure speculative approach, sounds reasonable. But what I find more difficult to understand is the fact the problem only occurs under specific conditions (recursion). In the optimised version (with loops) the VB.NET is as quick as the C# one (even, quicker, at some points). | |
| Feb 22, 2014 at 17:58 | comment | added | Comintern | Pure speculation: I'm guessing it has something to do with compiler optimization, and you could verify by examining the CLR that each generates. Microsoft had experience in writing optimizing compilers for C syntax, but I doubt they ever spent much effort in optimizations for VB syntax. | |
| Feb 22, 2014 at 17:57 | review | First posts | |||
| Feb 22, 2014 at 18:18 | |||||
| Feb 22, 2014 at 17:53 | history | edited | varocarbas | CC BY-SA 3.0 |
Asking the question.
|
| Feb 22, 2014 at 17:40 | history | asked | varocarbas | CC BY-SA 3.0 |