KickC Benchmark Tests (cf Mad Pascal) ... WIP

[zbyti]

@fenrock But this is another kind of test, different aspect - do what you consider is best! Good luck :]

Edited November 3, 2020 by zbyti

[fenrock]

3 minutes ago, tebe said:

cc65 memset, used by MP

https://github.com/cc65/cc65/blob/153bb295010e2dc75ffd544d7091870ff563338d/libsrc/common/memset.s

Yup, we're getting down to "whose memset function is faster" at this point, not "whose code produces decent sieve" which is what the test should be doing

[zbyti]

2 minutes ago, fenrock said:

Yup, we're getting down to "whose memset function is faster" at this point, not "whose code produces decent sieve" which is what the test should be doing

Yes it was part of the test from the beginning  not complain  

Edited November 3, 2020 by zbyti
;)

[fenrock]

1 minute ago, zbyti said:

@fenrock But this is another kind of test, different aspect - do what you consider is best! Good luck :]

I want to do Floating Point numbers, more to be able to add it as an option for myself, but after that, I'm going to start writing some IO libraries for kickc.

I just got a fujinet and want to write the bindings for it so I/anyone can use kickc for writing network code.

These benchmarks have been an excellent tool for learning, but now I want to do something real  

[zbyti]

Just now, fenrock said:

These benchmarks have been an excellent tool for learning, but now I want to do something real  

I agree!

[fenrock]

Last one for now tweaking sieve tests:

 

 

And the XEX:

suite.xex

 

This is using a hand cranked asm to set the sieve table, reducing score by up to 7.

 

[funkheld]

Eventually in the next couple of weeks I am going to be writing a bunch

of IO libraries for the Atari for kickc and you will be able to load them from there instead.

 

hello , thanks.

greeting

[tebe]

6 hours ago, fenrock said:

I just got a fujinet and want to write the bindings for it so I/anyone can use kickc for writing network code.

https://www.howtogeek.com/697300/a-vintage-atari-is-an-amazing-weather-terminal-in-2020/amp/

 

source code (MP): https://gitlab.com/bocianu/weather

[fenrock]

1 hour ago, tebe said:

https://www.howtogeek.com/697300/a-vintage-atari-is-an-amazing-weather-terminal-in-2020/amp/

 

source code (MP): https://gitlab.com/bocianu/weather

Thanks @tebe  I've been running the same program on my 800XL next to my PC!

 

Going to be digesting these too:

https://github.com/FujiNetWIFI/fujinet-platformio/wiki/A-Simple-NetCat-Program

https://github.com/FujiNetWIFI/fujinet-apps/tree/master/netcat/src

 

[fenrock]

Small update to project.

It's now using the new XeX Kick Assembler plugin (integrated into kickc), which splits segments up correctly in the XeX as separate sections.

 

This has reduced the overall size of the binary to 6,831 bytes, pretty much as low as it can go:

 

$ ataricom bin/suite.xex 
ataricom 0.30-190808
(c) 2008-2019 Matthias Reichl <hias@horus.com>
block    1: 1000-2599 (bytes:  5530, offset:      6)
block    2: 259a-2953 (bytes:   954, offset:   5540)
block    3: 4000-4146 (bytes:   327, offset:   6498)
block    4: 02e0-02e1 (bytes:     2, offset:   6829)
       RUN: 10df

 

Example linking file which is much simpler now:

.plugin "dk.camelot64.kickass.xexplugin.AtariXex"
.file [name="%O", type="bin", segments="File"]

.segmentdef File [segments="Program", modify="XexFormat", _RunAddr=main]
.segmentdef Program [segments="Code, Data, DList"]
.segmentdef Code [start=$1000]
.segmentdef Data [startAfter="Code"]
.segmentdef DList [start=$4000]

Results haven't really changed (since using "pure C" implementation), just organisation of the data/code etc.

 

 

suite.xex

Edited November 27, 2020 by fenrock

[zbyti]

New scores from test branch :]

 

suite.xex

Edited December 1, 2020 by zbyti
typo

[ilmenit]

do I read the arrows up/down correctly, that performance in some cases is much better but in some worse?

Edited December 1, 2020 by ilmenit

[zbyti]

2 minutes ago, ilmenit said:

do I read the arrows up/down correctly, that performance in some cases is much better but in some worse?

Yes, I suspect branch over page boundary. Different code organization slightly different result in some cases.

 

 

suite.xex

[fenrock]

1 hour ago, ilmenit said:

do I read the arrows up/down correctly, that performance in some cases is much better but in some worse?

The up/down arrows mean "The score indicates big number is better if the arrow points up", and opposite for down.

 

They are not relative to the MP versions of the tests, just an indicator if a big number is a good thing, or a bad thing.

 

As @zbyti previously said, wherever the word "frames" is in the name, the test runs for a fixed number of frames, so you want a higher score (e.g. GTIA flames does 250 frames and we count how many times the screen is fully re-rendered in that time, so higher is better).

 

For names without "frames" in it, it's a test that just runs until it completes, e.g. doing an MD5 calculation 5 times on a 512 byte array.

You want to go faster, so score (which is effectively the number of frames to complete it) should be lower.

 

 

[fenrock]

1 hour ago, zbyti said:

New scores from test branch :]

 

suite.xex 12.64 kB · 3 downloads

Is Flames "A" assembly, "P" pascal?

 

[zbyti]

1 minute ago, fenrock said:

Is Flames "A" assembly, "P" pascal?

 

Nop. P means POINTER version A as ARRAY :]

[zbyti]

@fenrock THX for explanatory :] Now I see that I did't understand @ilmenit Q right.

[zbyti]

New mp-test-0 branch and code order:

 

suite.xex

Edited December 5, 2020 by zbyti