Hi Toro's Sieve test
BlitzMax Forums/BlitzMax Programming/Hi Toro's Sieve test
| ||
Hi,
' Ported from another Basic for benchmarking purposes...
strict
local x,Iter,Count,i,prime,k
'Global x,Iter,Count,i,prime,k
Const ITERATIONS = 10000
Local Flags [8191]
Print "SIEVE OF ERATOSTHENES - " + ITERATIONS + " iterations"
X = MilliSecs ()
For Iter = 1 To ITERATIONS
Count = 0
For I = 0 To 8190
Flags[I] = 1
Next
For I = 0 To 8190
If Flags[I]=1 Then
Prime = I + I
Prime = Prime + 3
K = I + Prime
While K <= 8190
Flags[K] = 0
K = K + Prime
Wend
Count = Count + 1
EndIf
Next
Next
X = MilliSecs () - X
Print "1000 iterations took "+(X/1000.0)+" seconds."
Print "Primes: "+Count
End
Changing local x,Iter,Count,i,prime,k to GLOBAL literally CRIPPLES the speed, can you explain why? it's important for us to understand what is fast and why. |
| ||
| Does this even compile? You have strict turned on, you define "prime" and then use "Prime" in the main loop. Same with "i", "k", etc. Is this piece of code the one you meant to post? |
| ||
| Variables aren't case-sensitive in BlitzMax, so i = I regardless of Strict or non-Strict. As to what causes the slowdown, I guess only Mark could say... |
| ||
| Yes it is a direct copy of the code, with strict added to see how globals affect performance. |
| ||
| Hi James :) I'd love to get to the bottom of this as I am doing the test across several machines and compilers. So far, Blitzmax is indeed comparable - but it's very touchy about what you do! small changes result in drastic peformance differences. The above code approaches the MSVC++ version in speed until you use globals. With most of us coming from Blitz3D, you can understand why we are concerned. Here are the speed test results: Blitz3D 2.58 seconds Blitzmax 0.95 seconds MSVC++ 0.71 seconds 0.7 vs 0.9 isn't bad!... but making it GLOBAL results in *worse than Blitz3D performance* - 2.6 ! |
| ||
| Variables aren't case-sensitive in BlitzMax, so i = I regardless of Strict or non-Strict. *sigh* KindOfStrict |
| ||
| S&M with feather whips. |
| ||
| *sigh* My sentiments exactly. :o> KindOfStrict |
| ||
| You're right. The difference is slight on debug builds, but it doubles the execution time on release builds. Looking at the .s code generated, you can see that when locals are used all the variables are kept in the processor registers. When globals are used, the variables have to be pulled in and pushed out of main memory each time. Chances are that an intelligent C compiler would realise that you can fit all of the variables in processor registers and optimise accordingly. If you create a few more local and global variables in the C test, it might have to start storing them in RAM too. |
| ||
| Perhaps global enforces storage in ram? Where are we regarding cache friendly code in Blitzmax? |
| ||
| (rant) If you want "strict" to complain if you change capitalizations -- but not treat i and I as distinct variables -- you have my blessing. Case sensitivity in programming languages is nutty. It adds *nothing* to programming style or clarity to be able to differentiate variables based on capitalization. It's like arguing that if(a=b){..} is a great construct in C because it occasionally saves you a line of code, and frequently causes hard to find bugs. |
| ||
| Case sensitivity in programming languages is nutty. It adds *nothing* to programming style or clarity to be able to differentiate variables based on capitalization. That is, without a doubt, the silliest thing I've read in weeks. Thank you! |
| ||
| That is, without a doubt, the silliest thing I've read in weeks. I could return the compliment, but I think you are misunderstanding me. So you think it's good to have a language where thisVariable and ThisVariable and thisvariable are treated as separate variables and encourage coders to write code like this? (I am not saying you shouldn't be allowed to mix case in your code, quite the contrary. I am saying that you shouldn't be penalised for doing so by occasionally creating bugs caused by miscapitalization, e.g. declaring i and I and then not realising you have two different variables.) This is definitely not an uncontroversial view... it pretty much defines the difference between C-based languages and Pascal-based and BASIC-based languages (and shows where I stand). Certainly, C-style languages are ascendent, but so are a lot of dumb things. |
| ||
| So you think it's good to have a language where thisVariable and ThisVariable and thisvariable are treated as separate variables and encourage coders to write code like this? It would be caught by the compiler and throw an error. You would be forced to write it as it was declared.Case sensitivity is also a unix thing isn't it? Personally I haven't the energy to always remember if it the I was upper or lowercase, so it's beneficial for me the way things are. Perhaps a Strict and "Stricter" mode could be included for people like Warren. But, please end your arguments now so the original intent of the thread is preserved :) |
| ||
| So you think it's good to have a language where thisVariable and ThisVariable and thisvariable are treated as separate variables and encourage coders to write code like this? My position is that a language should enforce case sensitivity and programmers should be intelligent enough not to do that. If you declared a variable as "ThisVariable" and then tried to use it as "thisvariable", you made a mistake. Fix it and compile again... |
| ||
| I think it is very sad that people spend their evenings discussing things like variable case sensitivity. BASIC is not case-sensitive. The 'Max language is a variant of BASIC (see the press release). Therefore it is not going to be case sensitive. EoF. @skunk The only person who can reliably explain what is going on here is Mark himself - I suggest you email him. |
| ||
| Then don't include a "strict" option that isn't strict. I wanted a steak, not hamburger molded into a steak-like shape. |
| ||
| Tested the sieve code on PureBasic. Check the results (in milliseconds):
Interations PureBasic BMaxBeta
10000 2243 m/sec 953 m/sec
15000 3354 m/sec 1899 m/sec
20000 4547 m/sec 3767 m/sec
Go MAX! NB: Using globals in max makes the results slower than pb. PB Source: |
| ||
| WarrenM: So either you're saying: 1) STRICT should enforce syntactic rules that do not exist (i.e. prevent people from writing legal, unambiguous code). This is not so much STRICT as BIZARRE. 2) Or that BMax should be case-sensitive, and STRICT should correctly enforce this, but that programmers should be "intelligent" enough to name their variables as if it were case-insensitive. This is STRICT and BIZARRE. There are many good programming practices that STRICT does not enforce, e.g. tidy coding, meaningful variable names, and consistent indentation. It may be good programming practice to consistently capitalize variable names, but it's also good practice to do a lot of other things. Perhaps STRICT should also require users to submit to a urine test before compiling? |
| ||
| 3) Blitz should be case sensitive and "strict" should enforce that. Enforced casing leads to more readable code. WouLDn'T yOu AGreE? |
| ||
| I do agree that casing leads to more readable code, but I still don't think it should be 'forced'. However, it would certainly be nice to have an IDE that auto-capitalized previously defined variables and functions, as is already done with keywords. |
| ||
| Could you please take the case sensitivity to another thread as it is rather off topic. I would like to see the original point of globals being slower than locals looked at, as it's an intriguing thing. |
| ||
| Erm, I thought someone already covered that? Registers vs memory fetches ... |
| ||
| Mark was nice enough to reply to my email and cleared this issue up nicely. He says there's room for optimisation in the compiler and confirms the memory fetch. He urges that we should use locals just about everywhere. Warren, would you know about this if I didn't bring it up? I think you should be more open minded about my insistence to learn. I am only trying to get the best we can from this new language. |
| ||
| So, memory fetches then? Great. |
| ||
| Pull your socks up and act like a man. |
| ||
| Warren, in fairness you are trolling a little here, and it's not helpful or useful. |
| ||
| Hi, Locals will ALWAYS be faster no matter how much I tweak the backend - a read/write to a CPU register will always be faster than a read/write to memory. I think this is mentioned in the language reference in the 'variables' section. |
| ||
| Ok, Quick tinker and I've got the global version from 2.25 down to 1.62! |
| ||
| Cool. Imagine what he could do if he tried for more than just a quick tinker? =] Why was Blitz3D differant? I was under the impression in B3D globals were always just as fast as locals. I made everything I possibly could a global... |
| ||
| I'd always been taught that you should never use globals unless you absolutely had to... and you should never HAVE to. :) |
| ||
| <whines> But they're so cool. =] |
| ||
| Why was Blitz3D differant? I was under the impression in B3D globals were always just as fast as locals. I made everything I possibly could a global... Before Max, Blitz stored its locals on the stack - ie: also in memory. BlitzMax sometimes has to resort to using the stack if there aren't enough free cpu registers, but appears to do a reasonably good job of avoiding this. |
| ||
| I see. Jolly good to know. |
| ||
| case sensitive sucks, whats the damn point? if its only gonna tell you to make a letter lowercase or whatever, there is no reason to have it. |
| ||
| yeah... what he said! |
| ||
| I AgREe. WHat'S tHe DifFERenCe? |
| ||
| And tonight on Fox, xTreme Examples III. My problem with it is although I can be fairly certain of maintaing a set casing..umm standard, I can't make everyone else use the same. So when using other people's libs(Which we all do, if we're more interested in getting a game done than coding every little bit ourselfs) I have to memorize their style. And then the next guy's...and then the next... |
| ||
| My position is that a language should enforce case sensitivity and programmers should be intelligent enough not to do that. Enforced casing leads to more readable code. WouLDn'T yOu AGreE? So you think that you can trust programmers not to have two variables with the same name but different capitalisation, but you can't trust programmers not to occasionally suffer a stroke while writing out variable names and stab randomly at the caps lock key? |
| ||
| The purpose of a "strict" compiler is to enforce rules. Every major language in existence today enforces case sensitivity. That BlitzMax doesn't, is a real shame. |
| ||
| JustAnotherPureBasicEditor(?) handles it the right way imo, as it uses the function/variable/constants definition as the casing, and whenever you use the reference in code it's automatically converted to the same case, word for word as the original def..So whatever casing you use, it reverts to the original's. |
| ||
| The purpose of a "strict" compiler is to enforce rules. Every major language in existence today enforces case sensitivity. i really can't understand why you're so bothered about this at all - ok, so the compiler doesn't throw an error if you try to use "blah" instead of "Blah" but it also doesn't matter if you use "blah" instead of "Blah", so what you lose on the swings, you make up on the roundaboutsThat BlitzMax doesn't, is a real shame. JustAnotherPureBasicEditor(?) handles it the right way imo, as it uses the function/variable/constants definition as the casing, and whenever you use the reference in code it's automatically converted to the same case, word for word as the original def..So whatever casing you use, it reverts to the original's. that would be an ideal solution really |
| ||
| It just bugs me that we finally got a "strict" keyword, and it's neutered. I wanted something other than what I got. Allow me my pouting... |
| ||
| Sounds like programming language peer pressure to me. "Come on, man - you'll never be a major language if you don't take a toke off this here case sensitivity like the big boys. You wanna spend the rest of your life sucking your thumb and alternating caps with all the other Basics...?" Heh. Sorry. I'll stop. |
| ||
| Close only counts in horseshoes and hand grenades. And Blitz, apparently... |
| ||
| JustAnotherPureBasicEditor(?) handles it the right way imo, as it uses the function/variable/constants definition as the casing, and whenever you use the reference in code it's automatically converted to the same case, word for word as the original def..So whatever casing you use, it reverts to the original's. That's the way VB has handled it forever... That's definitely the ideal solution. The compiler doesn't enforce it, but the editor you use DOES. |
| ||
| That'd be fine. Anyone know of a good source code editor for Mac? :) |
| ||
| JustAnotherPureBasicEditor(?) handles it the right way imo, as it uses the function/variable/constants definition as the casing, and whenever you use the reference in code it's automatically converted to the same case, word for word as the original def..So whatever casing you use, it reverts to the original's. I think I'll be getting the first IDE that does this. |
| ||
| I do not understand why JimBs results do not increase linearly with the number of iterations - one would for sure expect the results (of course scaled by the speed of the language/compiler/machnie) be like the ones using PureBasic. Extrapolating the results I'd guess at 25000 iterations PureBasic would be as fast as BMax and at 30000 outperforms it. @JimB maybe you can validate that without much effort? |
| ||
| Well spotted, Nelvin. That's a bit worrying, whatever case you type it in. |
| ||
| That is weird...but it's not happening here. My times are roughly: 5000=.4 10000=.9 15000=1.2 20000=1.6 25000=2.1 ie: roughly linear. |
| ||
| gotta wonder if maybe his machine doesn't have other things going on................... |
| ||
| @JimB maybe you can validate that without much effort? Sure thing. I entered a value of 1899 above which I just realised is the number of primes.Anyhow, here's another run with more test results:
Interations PureBasic BMax Beta
5000 1131 m/sec 477 m/sec
10000 2344 m/sec 942 m/sec
15000 3385 m/sec 2869 m/sec
20000 4476 m/sec 3793 m/sec
25000 5678 m/sec 4833 m/sec
30000 6799 m/sec 5690 m/sec
The modified BMAX code I used (to show m/secs) |
| ||
| Did the test on my machine and the results are as expected (e.g. linear) so everything's ok. I just noticed the distribution and thought I mention it cause sometimes strange things/bugs happen ;-) |
| ||
| JustAnotherPureBasicEditor(?) handles it the right way imo, as it uses the function/variable/constants definition as the casing, and whenever you use the reference in code it's automatically converted to the same case, word for word as the original def..So whatever casing you use, it reverts to the original's. That's how Protean does it too. |
| ||
Here's a quick analysis of the JimB timing data:iter ms ms/iter =================== 5 477 95 10 942 94 15 2869 191 20 3793 190 25 4833 193 30 5690 190So the first two tests run at full speed and the rest at half speed. This suggests a small primary cache, sufficient only for the first two. Celeron? |
| ||
| @WarrenM 1) Good source code editors on the Mac: Well, there's BBEdit (and BBEdit Lite, which you may find around although it's no longer being supported). http://barebones.com/ There's also CodeWarrior of course. And Project Builder. SubEthaEdit (formerly Hydra). http://www.codingmonkeys.de/subethaedit/ And tons and tons of others. Pretty much all your standard UNIX editors work just fine in the terminal (vi, emacs, et al are there). If you want to knock up your own Blitz IDE there's RealBasic ($99) with which you could put together an IDE in very short order (something I keep planning to do in a spare week...) 2) Enforced Case There's nothing to stop you using insane casing in C, you just are forced to be consistent. And how does treating thisvariable, Thisvariable, thisVariable, and ThisVariable to coexist in the same scope as distinct variables make code more readable? As I said, if you want STRICT to complain about inconsistencies in case or even to make every instance of an identifier consistent automatically (so if you declare thisVariable and then refer to thisvariable, the second will become like the first), I agree. But case sensitivity is dumb, and you haven't managed a single coherent argument in its favor. |
| ||
| @Floyd the algorithm does only need some small fixed code as well as a small fixed amount of memory, so cachesize should not affect the results at all. Even less at thousands of iterations even for the first test. I guess it might be just some other tasks running on the machine but only about every second - maybe repeating the test a hundert times for each number of iterations and taking the average would give the expected results. |
| ||
| Yeah, I didn't study the code very closely. I was thinking the test got 'bigger' when it really is just repeated more times. That slowdown of almost exactly 2X sure is suspicious. It's what made me think the explanation must be a matter of primary cache versus secondary ( half speed ) cache. |
| ||
| Could it be a memory issue? Flushmem? |
| ||
| As I said, if you want STRICT to complain about inconsistencies in case or even to make every instance of an identifier consistent automatically (so if you declare thisVariable and then refer to thisvariable, the second will become like the first), I agree. But case sensitivity is dumb, and you haven't managed a single coherent argument in its favor. Look, we're past this now, alright? If I have to explain why case sensivity in a language is a good thing, I'm obviously talking to someone who won't understand. There's a reason why all the heavy hitter languages enforce case (Java, C++, C#, etc). |
| ||
| I think it's a terrible idea. Two variables differentiated only by case is a recipe for bugs. And taking the 'you're obviously not clever enough to understand' line is obnoxious and self-defeating. |
| ||
| No programmer in his right mind would have two variables that differed only by case. Why are people claiming that this is what I'm advocating? I simply want to be told when I type in a variable/function name wrong. And yes, getting the case wrong is a syntax error. In every other language I've ever used, that is... And I'm not saying "you're not clever enough", I'm saying "you're not experienced enough". IMO, of course. |
| ||
| And I'm not saying "you're not clever enough", I'm saying "you're not experienced enough". IMO, of course. then teach us oh wise one - explain why it matters even the tiniest amount if you get the case of a variable wrong? unless you're entering some kind of "prettiest code" competition, i can't see any reason at all why i should care about the non-difference between "myvar" and "myVar" |
| ||
| You must not use our easy game-making BASIC language until you have mastered ten much harder languages! |
| ||
| You know what? You guys are right. I concede. It doesn't matter in the least and, obviously, every other language I've ever used is doing the wrong thing. |
| ||
| I'm saying "you're not experienced enough". You'd be wrong there. |
| ||
| It's amazing the amount of people who used to argue against Option Explicit being implemented (including one memorable guy who had the nerve to tell us that we needed to learn how to type, complete with a typo in his post). Having an option to throw up an error if you use a different case for a variable is an excellent idea. I think that Strict needs to be expanded, eg Strict Declarations, Strict Case etc - it will vary from programmer to programmer just how strict he wants to be. I don't think this is nearly as urgently needed as Option Explicit was back in the Blitz3D days of course, but it would be a nice option. |
| ||
| You'd be wrong there. I love the internet. |
| ||
| I can understand the desire to maintain some sort of naming style but I think it would be very odd for a non case specific language to report an error where there isn't one. The proposed super-strict mode wouldn't help prevent a single bug. Perhaps this is a feature for an IDE? |
| ||
| A) I see where you are coming from Warren... It should be a compiler switch I think. Complain or don't complain. But I still think the editor should enforce the case in the way that VB handles it as well. In that way, you won't need to worry about whether you typed it right. The editor "fixes" it for you. B) Just for sheets and grins I ran the sieve on my laptop and got a linear progression as well... Also did a little converting over to IBasic Pro and tested there as well. Was a little surprised (maybe I'm doing something wrong)... Just checked Powerbasic 7 too btw... The results were:
Interations IBasic Pro BMax Beta PowerBasic7
5000 3074 m/sec 585 m/sec 1735 m/sec
10000 6159 m/sec 1103 m/sec 3265 m/sec
15000 9204 m/sec 1899 m/sec 4914 m/sec
20000 12408 m/sec 2207 m/sec 6557 m/sec
25000 15342 m/sec 2744 m/sec 8164 m/sec
|
| ||
| Kanati The IDE doing it is fine, but I'd rather have the compiler doing it. I wanted a "strict" option but I got something else and I'm pissy about it. That's all. |
| ||
| Warrenm is a plonker. |
| ||
| @KANATI in PB7 demo please use dim as register |
| ||
| John If only. |
| ||
| I wasn't talking about you. Obviously. |
| ||
I can think of nothing worse that someone being able to write:ReallyStrict Local human = 1 Local hUman = 2 Local huMan = 3 Local humAn = 4 Local Human = 5 Local HUman = 6 Local HUMan = 7 Local HUMAn = 8 Local HUMAN = 9 Local hUMan = Human-hUman+(Human*huMan)/HUMAn If hUMan < (HUMAN *((HUMAn*((HUMan/HUman)+Human)/humAn)*(huMan*hUman))*human ) Then Print hUMan Else Print HUMAn and it compiling. *EDIT* (except of course trying to understand it at a later date). |
| ||
| In that case a word test can be run on each keyword as it's entered, only flagging an error if it's over 30% different case wise. Meaning single case differences would be ignored, but messy stuff like the above wouldn't get past the compile stage. StrictOrElse |
| ||
| 29% I can understand, but 30% is crazy talk. |
| ||
| Then obviously, we settle at 29.5%. A good comprimise is when both parties walk away unhappy. |
| ||
| I wasn't talking about you. Obviously. If only. |
| ||
| @KANATI in PB7 demo please use dim as register You are right. Thanks for that catch. Unfortunately it didn't make any difference in the speed. If you can optimize that routine, by all means be my guest. I definitely don't want to hamstring a language because I didn't optimize it correctly. |
| ||
| I think it's funny that Max at 25000 was still faster than IBasic at 5000 ;] |
   |