New HJWasm release

[habran]

"programmer" was not pointed to you but to someone who would write some program to delete his stack

[nidud]

deleted

[jj2007]

I am sure that you would never write this construction in your programs, and you have to admit that

OK, let's declare it a misunderstanding. But now I am curious: Where in my code do I trash the stack that I need later on?

[jj2007]

Ah, finally: Did you RTFM  :lol:

No, I was busy reading the rest of the Internet 8)

Anyway, latest results from my switch testbed:

Code: [Select]

Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz
Assembled with HJWasm32
24 ms   case 260, MB Switch_ table
230 ms  case 260, MB Switch_ chain
455 ms  case 260, Masm32 switch
31 ms   case 260, HJWasm .Switch
6 ms    case 260, AsmC .Switch

24 ms   case 196, MB Switch_ table
178 ms  case 196, MB Switch_ chain
341 ms  case 196, Masm32 switch
38 ms   case 196, HJWasm .Switch
6 ms    case 196, AsmC .Switch

23 ms   case 132, MB Switch_ table
127 ms  case 132, MB Switch_ chain
229 ms  case 132, Masm32 switch
22 ms   case 132, HJWasm .Switch
6 ms    case 132, AsmC .Switch

23 ms   case 68, MB Switch_ table
76 ms   case 68, MB Switch_ chain
120 ms  case 68, Masm32 switch
40 ms   case 68, HJWasm .Switch
7 ms    case 68, AsmC .Switch

23 ms   case 4, MB Switch_ table
24 ms   case 4, MB Switch_ chain
6 ms    case 4, Masm32 switch
38 ms   case 4, HJWasm .Switch
6 ms    case 4, AsmC .Switch

2989    bytes for MbTable
4840    bytes for MbChain
4799    bytes for Masm32
6978    bytes for hjwasm
4208    bytes for asmc
The last AsmC row was added "by hand" because obviously you can't assemble the source with both assemblers at the same time. If you want to build it yourself, open the source in RichMasm and press Ctrl End. The OPT_Assembler rows should speak for themselves. OxPT is a disabled one (RichMasm looks for a case-sensitive OPT_). If two options are active, the last one is valid (I know, I know, modern IDEs have somewhere a project options menu where you can set the assembler if you find the right menu item; RM is very old fashioned, sorry).

[TWell]

DELETED

[jj2007]

64-bit version is faster:

Code: [Select]

OxPT_Assembler hjwasm32msvcrt ; 7.6
OxPT_Assembler hjwasm64msvcrt ; 6.2
OxPT_Assembler AsmC ; 2.5 secs

[TWell]

DELETED

[jj2007]

2.66 secs :t

Here are all my current timings:

Code: [Select]

HJWasmTWell ; 7.8 secs (9 May)
mlv10 ; 7.8 secs
mlv615 ; 7.0 secs - use for release version
JWasm ; 5.5 secs
HJWasm32 ; 3.15
HJWasm64 ; 2.80 secs
HJwasm64poc ; 2.75
hjwasm32gcc3 ; 2.7
hjwasm64gcc ; 6.1
HJWasm64Habran ; 2.55 secs, but it's 32-bit code
hjwasm32msvcrt ; 7.6
hjwasm64msvcrt ; 6.2
hjwasm32msv13 ; 2.65
AsmC ; 2.5 secs (used to be 2.1...)
In practice, I use AsmC for testing, not only because it's fastest but also because it gives direct feedback, i.e. you can see

Code: [Select]

Assembling: C:\Masm32\MasmBasic\libtmpAA.asm
Assembling: C:\Masm32\MasmBasic\libtmpAB.asm
Assembling: C:\Masm32\MasmBasic\libtmpAC.asm
Assembling: C:\Masm32\MasmBasic\libtmpAD.asmwhile it is assembling. JWasm and ML 6.15 do the same, most others let you wait until everything is complete, which is less nice to watch. But that is a very personal preference, of course 8)

Btw it would be nice if Nidud or Habran or both could identify the innermost loop that makes the assembly slow. We are experts here in speeding up C code...

[jj2007]

Btw it would be nice if Nidud or Habran or both could identify the innermost loop that makes the assembly slow. We are experts here in speeding up C code...

Thanks, Tim :t

Code: [Select]

2669 ms, 9459844 time(s): address 004386A0 _SymFind                   004386a0 f   symbols.obj
 2647 ms, 4850279 time(s): address 00420400 _my_fgets                  00420400 f   input.obj
 1383 ms, 10972418 time(s): address 0043A300 _get_id                    0043a300 f   tokenize.obj
 1242 ms, 4800861 time(s): address 0043A6A0 _Tokenize                  0043a6a0 f   tokenize.obj
 1136 ms, 10357549 time(s): address 00434DF0 _FindResWord               00434df0 f   reswords.obj
 1041 ms, 9461863 time(s): address 004384D0 _hashpjw                   004384d0 f   symbols.obj
  921 ms, 16118880 time(s): address 0043A540 _GetToken                  0043a540 f   tokenize.obj


[TWell]

DELETED

[jj2007]

3.0 secs, so far the best 64-bit version (AsmC: 2.5 secs).
But 32-bit version is 10% faster:

Code: [Select]

OxPT_Assembler hjwasm642005DDK ; 3.0
OPT_Assembler hjwasm322005DDK ; 2.7
OxPT_Assembler AsmC ; 2.5 secs
What about _SymFind and _my_fgets? Long and complicated, or is there a chance to give them a boost?

[johnsa]

Hey,

Do we have any clear indication as to why a C project compiled with an 11 year old version of MSVC is so much faster than if compiled with VS2015 ??
Is it purely down to the CRT inclusions being more bloated/less performant?

[TWell]

MS MT CRT fault.
Here are cl v19 compiled version with 2003 DDK libc.lib

Code: [Select]

5.325s        asmc
6.521s        hjwa64-2015clib.exe
7.180s        hjwa32-2015clib.exe


[jj2007]

why a C project compiled with an 11 year old version of MSVC is so much faster than if compiled with VS2015 ??

Compilers develop. We are all running extremely old CPUs, new compilers optimise for the latest CPUs 8)

[habran]

Hi TWell,
There is a new HJWasm on Terraspace built with your tools,thank you :t
as well as improved source on Github
This one you built above doesn't debug on source level in 32 bit