So, what about strings?

[dmsc]

Hi!

 

Well, I added two "hacks" to FastBasic, included in the attachment, that allows doing this little benchmark:

- You can include strings in DATA bytes, those are included directly in the byte data.

- You can use the function "$" to cast any pointer (integer) to a string, this allows directly reading strings from any position.

 

So, a simple example is:

DATA x() Byte = "Hello", "Atariage"

? x(0)   ' Prints 5, the length of "Hello"
? x(6)   ' Prints 8

s1 = adr(x)

? $(s1)   ' Prints "Hello"
? $(s1+6) ' Pirnts "Atariage"

With this, the following program performs the sort in 24.2 seconds (using the cross-compiler) or 26.5 seconds (with the Atari IDE), both in NTSC with the screen turned on. But, I used Shell sort, this is about twice faster (and simpler) than the "comb sort" in the original.

 

Spoiler

' Array is from 0 to N
n = 891 - 1

' All our data
data x() byte = "SMITH","JOHNSON","WILLIAMS","JONES",
data     byte = "BROWN","DAVIS","MILLER","WILSON","MOORE","TAYLOR",
data     byte = "ANDERSON","THOMAS","JACKSON","WHITE","HARRIS","MARTIN",
data     byte = "THOMPSON","GARCIA","MARTINEZ","ROBINSON","CLARK","RODRIGUEZ",
data     byte = "LEWIS","LEE","WALKER","HALL","ALLEN","YOUNG",
data     byte = "HERNANDEZ","KING","WRIGHT","LOPEZ","HILL","SCOTT",
data     byte = "GREEN","ADAMS","BAKER","GONZALEZ","NELSON","CARTER",
data     byte = "MITCHELL","PEREZ","ROBERTS","TURNER","PHILLIPS","CAMPBELL",
data     byte = "PARKER","EVANS","EDWARDS","COLLINS","STEWART","SANCHEZ",
data     byte = "MORRIS","ROGERS","REED","COOK","MORGAN","BELL",
data     byte = "MURPHY","BAILEY","RIVERA","COOPER","RICHARDSON","COX",
data     byte = "HOWARD","WARD","TORRES","PETERSON","GRAY","RAMIREZ",
data     byte = "JAMES","WATSON","BROOKS","KELLY","SANDERS","PRICE",
data     byte = "BENNETT","WOOD","BARNES","ROSS","HENDERSON","COLEMAN",
data     byte = "JENKINS","PERRY","POWELL","LONG","PATTERSON","HUGHES",
data     byte = "FLORES","WASHINGTON","BUTLER","SIMMONS","FOSTER","GONZALES",
data     byte = "BRYANT","ALEXANDER","RUSSELL","GRIFFIN","DIAZ","HAYES",
data     byte = "MYERS","FORD","HAMILTON","GRAHAM","SULLIVAN","WALLACE",
data     byte = "WOODS","COLE","WEST","JORDAN","OWENS","REYNOLDS",
data     byte = "FISHER","ELLIS","HARRISON","GIBSON","MCDONALD","CRUZ",
data     byte = "MARSHALL","ORTIZ","GOMEZ","MURRAY","FREEMAN","WELLS",
data     byte = "WEBB","SIMPSON","STEVENS","TUCKER","PORTER","HUNTER",
data     byte = "HICKS","CRAWFORD","HENRY","BOYD","MASON","MORALES",
data     byte = "KENNEDY","WARREN","DIXON","RAMOS","REYES","BURNS",
data     byte = "GORDON","SHAW","HOLMES","RICE","ROBERTSON","HUNT",
data     byte = "BLACK","DANIELS","PALMER","MILLS","NICHOLS","GRANT",
data     byte = "KNIGHT","FERGUSON","ROSE","STONE","HAWKINS","DUNN",
data     byte = "PERKINS","HUDSON","SPENCER","GARDNER","STEPHENS","PAYNE",
data     byte = "PIERCE","BERRY","MATTHEWS","ARNOLD","WAGNER","WILLIS",
data     byte = "RAY","WATKINS","OLSON","CARROLL","DUNCAN","SNYDER",
data     byte = "HART","CUNNINGHAM","BRADLEY","LANE","ANDREWS","RUIZ",
data     byte = "HARPER","FOX","RILEY","ARMSTRONG","CARPENTER","WEAVER",
data     byte = "GREENE","LAWRENCE","ELLIOTT","CHAVEZ","SIMS","AUSTIN",
data     byte = "PETERS","KELLEY","FRANKLIN","LAWSON","FIELDS","GUTIERREZ",
data     byte = "RYAN","SCHMIDT","CARR","VASQUEZ","CASTILLO","WHEELER",
data     byte = "CHAPMAN","OLIVER","MONTGOMERY","RICHARDS","WILLIAMSON","JOHNSTON",
data     byte = "BANKS","MEYER","BISHOP","MCCOY","HOWELL","ALVAREZ",
data     byte = "MORRISON","HANSEN","FERNANDEZ","GARZA","HARVEY","LITTLE",
data     byte = "BURTON","STANLEY","NGUYEN","GEORGE","JACOBS","REID",
data     byte = "KIM","FULLER","LYNCH","DEAN","GILBERT","GARRETT",
data     byte = "ROMERO","WELCH","LARSON","FRAZIER","BURKE","HANSON",
data     byte = "DAY","MENDOZA","MORENO","BOWMAN","MEDINA","FOWLER",
data     byte = "BREWER","HOFFMAN","CARLSON","SILVA","PEARSON","HOLLAND",
data     byte = "DOUGLAS","FLEMING","JENSEN","VARGAS","BYRD","DAVIDSON",
data     byte = "HOPKINS","MAY","TERRY","HERRERA","WADE","SOTO",
data     byte = "WALTERS","CURTIS","NEAL","CALDWELL","LOWE","JENNINGS",
data     byte = "BARNETT","GRAVES","JIMENEZ","HORTON","SHELTON","BARRETT",
data     byte = "OBRIEN","CASTRO","SUTTON","GREGORY","MCKINNEY","LUCAS",
data     byte = "MILES","CRAIG","RODRIQUEZ","CHAMBERS","HOLT","LAMBERT",
data     byte = "FLETCHER","WATTS","BATES","HALE","RHODES","PENA",
data     byte = "BECK","NEWMAN","HAYNES","MCDANIEL","MENDEZ","BUSH",
data     byte = "VAUGHN","PARKS","DAWSON","SANTIAGO","NORRIS","HARDY",
data     byte = "LOVE","STEELE","CURRY","POWERS","SCHULTZ","BARKER",
data     byte = "GUZMAN","PAGE","MUNOZ","BALL","KELLER","CHANDLER",
data     byte = "WEBER","LEONARD","WALSH","LYONS","RAMSEY","WOLFE",
data     byte = "SCHNEIDER","MULLINS","BENSON","SHARP","BOWEN","DANIEL",
data     byte = "BARBER","CUMMINGS","HINES","BALDWIN","GRIFFITH","VALDEZ",
data     byte = "HUBBARD","SALAZAR","REEVES","WARNER","STEVENSON","BURGESS",
data     byte = "SANTOS","TATE","CROSS","GARNER","MANN","MACK",
data     byte = "MOSS","THORNTON","DENNIS","MCGEE","FARMER","DELGADO",
data     byte = "AGUILAR","VEGA","GLOVER","MANNING","COHEN","HARMON",
data     byte = "RODGERS","ROBBINS","NEWTON","TODD","BLAIR","HIGGINS",
data     byte = "INGRAM","REESE","CANNON","STRICKLAND","TOWNSEND","POTTER",
data     byte = "GOODWIN","WALTON","ROWE","HAMPTON","ORTEGA","PATTON",
data     byte = "SWANSON","JOSEPH","FRANCIS","GOODMAN","MALDONADO","YATES",
data     byte = "BECKER","ERICKSON","HODGES","RIOS","CONNER","ADKINS",
data     byte = "WEBSTER","NORMAN","MALONE","HAMMOND","FLOWERS","COBB",
data     byte = "MOODY","QUINN","BLAKE","MAXWELL","POPE","FLOYD",
data     byte = "OSBORNE","PAUL","MCCARTHY","GUERRERO","LINDSEY","ESTRADA",
data     byte = "SANDOVAL","GIBBS","TYLER","GROSS","FITZGERALD","STOKES",
data     byte = "DOYLE","SHERMAN","SAUNDERS","WISE","COLON","GILL",
data     byte = "ALVARADO","GREER","PADILLA","SIMON","WATERS","NUNEZ",
data     byte = "BALLARD","SCHWARTZ","MCBRIDE","HOUSTON","CHRISTENSEN","KLEIN",
data     byte = "PRATT","BRIGGS","PARSONS","MCLAUGHLIN","ZIMMERMAN","FRENCH",
data     byte = "BUCHANAN","MORAN","COPELAND","ROY","PITTMAN","BRADY",
data     byte = "MCCORMICK","HOLLOWAY","BROCK","POOLE","FRANK","LOGAN",
data     byte = "OWEN","BASS","MARSH","DRAKE","WONG","JEFFERSON",
data     byte = "PARK","MORTON","ABBOTT","SPARKS","PATRICK","NORTON",
data     byte = "HUFF","CLAYTON","MASSEY","LLOYD","FIGUEROA","CARSON",
data     byte = "BOWERS","ROBERSON","BARTON","TRAN","LAMB","HARRINGTON",
data     byte = "CASEY","BOONE","CORTEZ","CLARKE","MATHIS","SINGLETON",
data     byte = "WILKINS","CAIN","BRYAN","UNDERWOOD","HOGAN","MCKENZIE",
data     byte = "COLLIER","LUNA","PHELPS","MCGUIRE","ALLISON","BRIDGES",
data     byte = "WILKERSON","NASH","SUMMERS","ATKINS","WILCOX","PITTS",
data     byte = "CONLEY","MARQUEZ","BURNETT","RICHARD","COCHRAN","CHASE",
data     byte = "DAVENPORT","HOOD","GATES","CLAY","AYALA","SAWYER",
data     byte = "ROMAN","VAZQUEZ","DICKERSON","HODGE","ACOSTA","FLYNN",
data     byte = "ESPINOZA","NICHOLSON","MONROE","WOLF","MORROW","KIRK",
data     byte = "RANDALL","ANTHONY","WHITAKER","OCONNOR","SKINNER","WARE",
data     byte = "MOLINA","KIRBY","HUFFMAN","BRADFORD","CHARLES","GILMORE",
data     byte = "DOMINGUEZ","ONEAL","BRUCE","LANG","COMBS","KRAMER",
data     byte = "HEATH","HANCOCK","GALLAGHER","GAINES","SHAFFER","SHORT",
data     byte = "WIGGINS","MATHEWS","MCCLAIN","FISCHER","WALL","SMALL",
data     byte = "MELTON","HENSLEY","BOND","DYER","CAMERON","GRIMES",
data     byte = "CONTRERAS","CHRISTIAN","WYATT","BAXTER","SNOW","MOSLEY",
data     byte = "SHEPHERD","LARSEN","HOOVER","BEASLEY","GLENN","PETERSEN",
data     byte = "WHITEHEAD","MEYERS","KEITH","GARRISON","VINCENT","SHIELDS",
data     byte = "HORN","SAVAGE","OLSEN","SCHROEDER","HARTMAN","WOODARD",
data     byte = "MUELLER","KEMP","DELEON","BOOTH","PATEL","CALHOUN",
data     byte = "WILEY","EATON","CLINE","NAVARRO","HARRELL","LESTER",
data     byte = "HUMPHREY","PARRISH","DURAN","HUTCHINSON","HESS","DORSEY",
data     byte = "BULLOCK","ROBLES","BEARD","DALTON","AVILA","VANCE",
data     byte = "RICH","BLACKWELL","YORK","JOHNS","BLANKENSHIP","TREVINO",
data     byte = "SALINAS","CAMPOS","PRUITT","MOSES","CALLAHAN","GOLDEN",
data     byte = "MONTOYA","HARDIN","GUERRA","MCDOWELL","CAREY","STAFFORD",
data     byte = "GALLEGOS","HENSON","WILKINSON","BOOKER","MERRITT","MIRANDA",
data     byte = "ATKINSON","ORR","DECKER","HOBBS","PRESTON","TANNER",
data     byte = "KNOX","PACHECO","STEPHENSON","GLASS","ROJAS","SERRANO",
data     byte = "MARKS","HICKMAN","ENGLISH","SWEENEY","STRONG","PRINCE",
data     byte = "MCCLURE","CONWAY","WALTER","ROTH","MAYNARD","FARRELL",
data     byte = "LOWERY","HURST","NIXON","WEISS","TRUJILLO","ELLISON",
data     byte = "SLOAN","JUAREZ","WINTERS","MCLEAN","RANDOLPH","LEON",
data     byte = "BOYER","VILLARREAL","MCCALL","GENTRY","CARRILLO","KENT",
data     byte = "AYERS","LARA","SHANNON","SEXTON","PACE","HULL",
data     byte = "LEBLANC","BROWNING","VELASQUEZ","LEACH","CHANG","HOUSE",
data     byte = "SELLERS","HERRING","NOBLE","FOLEY","BARTLETT","MERCADO",
data     byte = "LANDRY","DURHAM","WALLS","BARR","MCKEE","BAUER",
data     byte = "RIVERS","EVERETT","BRADSHAW","PUGH","VELEZ","RUSH",
data     byte = "ESTES","DODSON","MORSE","SHEPPARD","WEEKS","CAMACHO",
data     byte = "BEAN","BARRON","LIVINGSTON","MIDDLETON","SPEARS","BRANCH",
data     byte = "BLEVINS","CHEN","KERR","MCCONNELL","HATFIELD","HARDING",
data     byte = "ASHLEY","SOLIS","HERMAN","FROST","GILES","BLACKBURN",
data     byte = "WILLIAM","PENNINGTON","WOODWARD","FINLEY","MCINTOSH","KOCH",
data     byte = "BEST","SOLOMON","MCCULLOUGH","DUDLEY","NOLAN","BLANCHARD",
data     byte = "RIVAS","BRENNAN","MEJIA","KANE","BENTON","JOYCE",
data     byte = "BUCKLEY","HALEY","VALENTINE","MADDOX","RUSSO","MCKNIGHT",
data     byte = "BUCK","MOON","MCMILLAN","CROSBY","BERG","DOTSON",
data     byte = "MAYS","ROACH","CHURCH","CHAN","RICHMOND","MEADOWS",
data     byte = "FAULKNER","ONEILL","KNAPP","KLINE","BARRY","OCHOA",
data     byte = "JACOBSON","GAY","AVERY","HENDRICKS","HORNE","SHEPARD",
data     byte = "HEBERT","CHERRY","CARDENAS","MCINTYRE","WHITNEY","WALLER",
data     byte = "HOLMAN","DONALDSON","CANTU","TERRELL","MORIN","GILLESPIE",
data     byte = "FUENTES","TILLMAN","SANFORD","BENTLEY","PECK","KEY",
data     byte = "SALAS","ROLLINS","GAMBLE","DICKSON","BATTLE","SANTANA",
data     byte = "CABRERA","CERVANTES","HOWE","HINTON","HURLEY","SPENCE",
data     byte = "ZAMORA","YANG","MCNEIL","SUAREZ","CASE","PETTY",
data     byte = "GOULD","MCFARLAND","SAMPSON","CARVER","BRAY","ROSARIO",
data     byte = "MACDONALD","STOUT","HESTER","MELENDEZ","DILLON","FARLEY",
data     byte = "HOPPER","GALLOWAY","POTTS","BERNARD","JOYNER","STEIN",
data     byte = "AGUIRRE","OSBORN","MERCER","BENDER","FRANCO","ROWLAND",
data     byte = "SYKES","BENJAMIN","TRAVIS","PICKETT","CRANE","SEARS",
data     byte = "MAYO","DUNLAP","HAYDEN","WILDER","MCKAY","COFFEY",
data     byte = "MCCARTY","EWING","COOLEY","VAUGHAN","BONNER","COTTON",
data     byte = "HOLDER","STARK","FERRELL","CANTRELL","FULTON","LYNN",
data     byte = "LOTT","CALDERON","ROSA","POLLARD","HOOPER","BURCH",
data     byte = "MULLEN","FRY","RIDDLE","LEVY","DAVID","DUKE",
data     byte = "ODONNELL","GUY","MICHAEL","BRITT","FREDERICK","DAUGHERTY",
data     byte = "BERGER","DILLARD","ALSTON","JARVIS","FRYE","RIGGS",
data     byte = "CHANEY","ODOM","DUFFY","FITZPATRICK","VALENZUELA"

' Create our "pointers" array, reading the data above
dim p(n)

? "Reading data... ";
s = TIME
pos = 0
for i=0 to n
  p(i) = adr(x) + pos
  pos = pos + x(pos) + 1
next
? TIME-s ; " jiffies"

? "Sorting... ";
s = TIME
' Sort - using shell-sort
data gaps() = 701, 301, 132, 57, 23, 10, 4, 1
for g=0 to 7
  gap = gaps(g)
  for i=gap to n
    temp = p(i)
    for j=i to gap step -gap
      if $(p(j - gap)) <= $(temp) then exit
      p(j) = p(j - gap)
    next
    p(j) = temp
  next
next
s = TIME - s

' Check that the array is really sorted
? : ? "Checking: ";
for i=0 to n-1
  if $(p(i)) > $(p(i+1))
    ? "Error at "; $(p(i)) ; " > " ; $(p(i+1))
    exit
  endif
next

' Show results
? : ? "Result:"
for i=0 to n
  ? $(p(i)) ; ",";
next

? : ? "Sorting time: "; s; " jiffies"
? "Press any key"
get k

 

 

I included the source ( SORTING.BAS ) and the compiled program ( SORTING.COM ) in the attached ATR.

 

Have Fun!

 

fastbasic.atr

[JamesD]

I hate to be nit picky, but that isn't doing even close to the same amount of work, so it's an apples and oranges comparison.
But the sort is fast.

*edit*
FWIW, I think it's awesome to be able to define data like that.
 

Edited August 4, 2019 by JamesD

[dmsc]

Hi!

8 minutes ago, JamesD said:

I hate to be nit picky, but that isn't doing even close to the same amount of work, so it's an apples and oranges comparison.
But the sort is fast.

Oh, yes, but that's what happens when the "benchmark" is not completely specified  

 

But note that reported times in the Atari programs above only report the sorting phase, not the reading and printing, so the "time to sort 891 strings" should be comparable.

 

I could have used "comb sort" to make it more comparable, but I really dislike that algorithm, as it is slower than shell sort and does not have a proof of complexity, so you don't know if it will be fast at all with your sequence. And in the way you coded in your first example, it does not warrant that the array will be sorted at all!

 

Also, note how much simpler FastBasic code is compared with other codes posted here! 

 

Have Fun!

 

[jnharmon]

29 minutes ago, dmsc said:

Hi!

Oh, yes, but that's what happens when the "benchmark" is not completely specified  

 

But note that reported times in the Atari programs above only report the sorting phase, not the reading and printing, so the "time to sort 891 strings" should be comparable.

 

I could have used "comb sort" to make it more comparable, but I really dislike that algorithm, as it is slower than shell sort and does not have a proof of complexity, so you don't know if it will be fast at all with your sequence. And in the way you coded in your first example, it does not warrant that the array will be sorted at all!

 

Also, note how much simpler FastBasic code is compared with other codes posted here! 

 

Have Fun!

 

Might be interesting to use a QuickSort routine (if there is enough RAM for the pseudo-stack) to see what affect that has.

[JamesD]

40 minutes ago, dmsc said:

I could have used "comb sort" to make it more comparable, but I really dislike that algorithm, as it is slower than shell sort and does not have a proof of complexity, so you don't know if it will be fast at all with your sequence. And in the way you coded in your first example, it does not warrant that the array will be sorted at all!

 

Worst case performance is the same as quick sort.
Best case and average depend on number of passes.  It might be the same as quick sort... or not. 
 

 

9 minutes ago, jnharmon said:

Might be interesting to use a QuickSort routine (if there is enough RAM for the pseudo-stack) to see what affect that has.

And then you have to do QuickSort on every version.

Why can't we use a machine language sort is the next question.

It's not about getting to the end the fastest, it's about how long it takes to get to the end the same way.

Edited August 4, 2019 by JamesD

[JamesD]

50 minutes ago, dmsc said:

But note that reported times in the Atari programs above only report the sorting phase, not the reading and printing, so the "time to sort 891 strings" should be comparable.

 

Just be aware that when I made the original read through the data twice, checked the results of the sort, and printed the results, it was intentional.
It wasn't just about the sort.  People missed that point from the start.  I wanted a benchmark that wasn't just limited to one thing. 
Ahl's benchmark, prime number generation, etc.. mostly deal with math. 
I just wasn't in the mood to argue.  But the "benchmark" tuning is getting out of hand at this point.

[dmsc]

Hi!

3 minutes ago, JamesD said:

Worst case performance is the same as quick sort.

Yes, but with a higher constant, so it is slower still. And main problem is nobody knows how frequent the worst case is - in qicksort it is known.

3 minutes ago, JamesD said:

Best case and average depend on number of passes.  It might be the same as quick sort... or not. 
I *think* a modification to the gap formula would

Problem is that nobody knows the best gaps, as they seems to depend on the data. And with standard gaps, the performance seems to be quadratic on the number of items. This is a test in my notebook comparing quick, shell and comb sorts, you can see that comb sort is a lot slower:

 

3 minutes ago, JamesD said:

And then you have to do QuickSort on every version.

Problem with quick-sort is that the code is bigger and more complicated. But yes,a good quicksort implementation should be about 50% faster than shell sort on 891 items.

 

3 minutes ago, JamesD said:

Why can't we use a machine language sort is the next question.

It's not about getting to the end the fastest, it's about how long it takes to get to the end the same way.

Yes, I agree. But it is fun to try to optimize the code in slow machines  

 

And also agree about testing more than the sort, but it is simpler to focus in one task only. For example, FastBasic DATA's are optimized to use little memory, as the data is only once in memory - the parser creates the binary data and is directly accessible from the program - this was my intention as FastBasic was created to allow writing simple games with sprite data.

 

 

Have Fun!

 

[JamesD]

FWIW, an inefficient sort is more of a torture test for string functions than an efficient one.
I just don't want to wait on a bubble sort.

[drpeter]

Point of information/debate.  Would we call Fast Basic an interpreted BASIC?

[drpeter]

7 hours ago, dmsc said:

Oh, yes, but that's what happens when the "benchmark" is not completely specified  

So far, attempts to specify the benchmark appear to have have proven one thing only- people feel unfairly constrained by a specified benchmark!  

[drpeter]

7 hours ago, JamesD said:

It's not about getting to the end the fastest, it's about how long it takes to get to the end the same way.

Even that simple statement of intent is open to some interpretation.

 

Many BASIC benchmarks were designed such that 'the same way' included running exactly portable source code without modification on different machines/BASIC implementations.

 

It helps, I think, to define quite carefully at the outset what the purpose of a benchmark is intended to be.  Then to very explicitly define 'the rules' to fulfil that purpose. Then insist that for inclusion in collated benchmarks, those rules, once agreed, are rigorously adhered to.

 

This started from one question: how could a given routine be programmed, if at all, in stock ATARI BASIC without native string array support and has since branched off in all kinds of interesting directions!

[JamesD]

Given the differences between Atari BASIC and MS BASIC, some leeway is required to even get the benchmark to run, but the code should be as close to the same as possible if we want a meaningful speed comparison. 
That concept always seems to get thrown out the window in favor of "look how fast we can do it if we completely change the code!"
So far the fastest way is a modern compiler where the code looks nothing like the original, or a version of BASIC that wasn't available until Dec 1985.
I was hoping for a faster solution that could work on original Atari BASIC so it could compete better with the Apple II series in the early years.
I say early years because the first Applesoft BASIC compiler was released 1981, and the first accelerator board in 1982, so if you want to pull out all the stops, keep in mind that becomes an option on other machines as well.

If you want to "win" a battle, you might want to at least try to limit the time frame from 1978-1980.
If it's not possible, then it's just not possible, but close would certainly go a long way to disprove criticism of Atari BASIC string handling.
 

[_The Doctor__]

the problem is depending on the machine and the BASIC flavor in use, line order, data position within the program, sort direction and type can favor one machine over the other. Each form of BASIC has their own affinities. one program favors this computer or that, this BASIC or that...

benchmarks on most machines are supposed eliminate favoritism of any kind. this is extremely hard to do on older machines. Do we prohibit/inhibit graphics cards from choosing the best method to get the job done for benchmarks today? No we leave it up to each offering to handle the task in whatever way it's engine decided to organize and break down tasks to ultimately push what we want out. In fact we have had different programs to do so because at least in one period of history they had to be! Each card was so different the drivers and even the programs themselves had no choice but to be different to get the same results. All the benchmarks cared about was getting the desired result and how fast. They did not require everything to be the same in the program or drivers/code. Do we say oh no that's not fair! we must prevent the card, it's software, and firmware from making it's own strategy and in essence it's own program to get things done? If we did that very little could have ever been 'benchmarked'

You might be able to apply the 'universal' benchmark' to today's graphics cards and processors as you are using the common interfaces of  whatever OS and graphic convention that they have homogenized into, there are like what 2 or three choices these days? and there are still behind the scenes shenanigans that people argue about for each of those benchmarks for the ATI camp vs nVidea camp vs AMD vs Intel... each time the riot act is pronounced when one claims to be better than the other and how the benchmark is flawed. It's not as bad as it used to be... but it's still going on. As a general rule the benchmarks are great over time though, each camp learns to program to speed things up, each modifies their drivers to do a better job, each works on the firmware and architecture to win the benchmark. This keeps things moving in the right direction. It's all about the end result and how fast, not about how it got there... to most users it just matters that when you go to play unreal tournament infinity.... you get it all as fast and accurate as possible so you see the enemy first and waste them before they ever knew you were there.

My apologies but the only true benchmark is how fast can you get a thing done...

 

You really do have to constrain things to the a year or two in the early days and weed out add on hardware accelerators to do this sort of early benchmarking. There were some industrial accelerator solutions for all them back back int the day that makes none of these machines remotely what they initially were. Each can opened releases another pile of worms wriggling and wiggling there way all over the place..

 

Edited August 4, 2019 by _The Doctor__

[JamesD]

7 hours ago, drpeter said:

Point of information/debate.  Would we call Fast Basic an interpreted BASIC?

Yes, but it's also compiled so it doesn't have to perform any parsing, or evaluate order of operations for math on the fly.
Most time consuming tasks like that are handled at compile time.
While it's not native code, the overhead is significantly lower than with a regular interpreter.

[JamesD]

4 minutes ago, _The Doctor__ said:

the problem is depending on the machine and the BASIC flavor in use, line order, data position within the program, sort direction and type can favor one machine over the other.

Each form of BASIC has their own affinities. one program favors this computer or that, this BASIC or that...

benchmarks on most machines are supposed eliminate favoritism of any kind. this is extremely hard to do on older machines.

Do we prohibit/inhibit graphics cards from choosing the best method to get the job done for benchmarks today? No we leave it up to each offering to handle the task in whatever way it's engine decided to organize and break down tasks to ultimately push what we want out. In fact we have had different programs to do so because at least in one period of history they had to be! Each card was so different the drivers and even the programs themselves had no choice but to be different to get the same results. All the benchmarks cared about was getting the desired result and how fast. They did not require everything to be the same in the program or drivers/code. Do we say oh no that's not fair! we must prevent the card, it's software, and firmware from making it's own strategy and in essence it's own program to get things done? If we did that very little could have ever been 'benchmarked'

You might be able to apply the 'universal' benchmark' to today's graphics cards and processors as you are using the common interfaces of  whatever OS and graphic convention that they have homogenized into, there are like what 2 or three choices these days? and there are still behind the scenes shenanigans that people argue about for each of those benchmarks for the ATI camp vs nVidea camp vs AMD vs Intel... each time the riot act is pronounced when one claims to be better than the other and how the benchmark is flawed. It's not as bad as it used to be... but it's still going on. As a general rule the benchmarks are great over time though, each camp learns to program to speed things up, each modifies their drivers to do a better job, each works on the firmware and architecture to win the benchmark. This keeps things moving in the right direction. It's all about the end result and how fast, not about how it got there... to most users it just matters that when you go to play unreal tournament infinity.... you get it all as fast and accurate as possible so you see the enemy first and waste them before they ever knew you were there.

My apologies but the only true benchmark is how fast can you get a thing done...

 

By all means, show how the code order, or sort order is somehow biased against the Atari.
Alphabetical order is alphabetical order.  How on earth would that be biased? 
If you have some logical explanation of how this isn't brutal on Microsoft BASIC, but intentionally picks on Atari, I'd like to hear it.

Favoritism, fairness?  I didn't even write the benchmark to compare different machines.  I wrote it as a torture test to see if my new string compare worked, and if it was any faster.  I'm pretty sure I didn't try to discriminate against Atari.

Even with graphics cards, you have standard benchmarks that are absolute torture tests, and they run on DirectX no matter which card you have.
So it's not like you have a completely different benchmark for each machine. 
You have different implementations of DirectX targeting different hardware, just like you have different versions of BASIC. 
But the benchmark is the same.
I also think you'll find a lot of criticism over "tuning" drivers for modern benchmarks.
Manufacturers make changes just so they get better numbers on a benchmark, but they offer no performance increase on real games.

FWIW, I won't say you can't turn in better numbers, but don't expect to compare a BASIC compiler from 1985 against uncompiled BASIC from 1979 without getting a not so fast in response.
 

[Faicuai]

The bottom-line of this while discussion is:

 

1. It is quite EASY to deliberately try / make things slower and throw surgical wrenches at X,Y,Z platform and software environments.

2. It is, however, MUCH HARDER to deliberately make things MUCH faster, efficient, less resource-demanding, while still using the same HW-processing resources and clock speed.

 

Whenever anyone comes to me with a benchmark test / concept, I ONLY and automatically think of #2. Any attempt to develop and evolve a discussion around point #1 is already a dead-end street, by definition, and draws little to no interest on me, in general. There are a few exceptions, depending on what are we hunting down, of course.

 

Overall, in the case of the Atari, and when it comes to anything done in CC65 (based on #2 premise), I have found that nothing touches it on CPU-intensive work (respect to its peer group and native HW), except the BBC Micro, or anything based on Z80 running at or beyond 4 Mhz.

 

Edited August 4, 2019 by Faicuai

[Faicuai]

23 hours ago, dmsc said:

Hi!

 

Well, I added two "hacks" to FastBasic, included in the attachment, that allows doing this little benchmark:

- You can include strings in DATA bytes, those are included directly in the byte data.

- You can use the function "$" to cast any pointer (integer) to a string, this allows directly reading strings from any position.

 

So, a simple example is:

DATA x() Byte = "Hello", "Atariage"

? x(0)   ' Prints 5, the length of "Hello"
? x(6)   ' Prints 8

s1 = adr(x)

? $(s1)   ' Prints "Hello"
? $(s1+6) ' Pirnts "Atariage"

With this, the following program performs the sort in 24.2 seconds (using the cross-compiler) or 26.5 seconds (with the Atari IDE), both in NTSC with the screen turned on. But, I used Shell sort, this is about twice faster (and simpler) than the "comb sort" in the original.

 

  Reveal hidden contents

' Array is from 0 to N
n = 891 - 1

' All our data
data x() byte = "SMITH","JOHNSON","WILLIAMS","JONES",
data     byte = "BROWN","DAVIS","MILLER","WILSON","MOORE","TAYLOR",
data     byte = "ANDERSON","THOMAS","JACKSON","WHITE","HARRIS","MARTIN",
data     byte = "THOMPSON","GARCIA","MARTINEZ","ROBINSON","CLARK","RODRIGUEZ",
data     byte = "LEWIS","LEE","WALKER","HALL","ALLEN","YOUNG",
data     byte = "HERNANDEZ","KING","WRIGHT","LOPEZ","HILL","SCOTT",
data     byte = "GREEN","ADAMS","BAKER","GONZALEZ","NELSON","CARTER",
data     byte = "MITCHELL","PEREZ","ROBERTS","TURNER","PHILLIPS","CAMPBELL",
data     byte = "PARKER","EVANS","EDWARDS","COLLINS","STEWART","SANCHEZ",
data     byte = "MORRIS","ROGERS","REED","COOK","MORGAN","BELL",
data     byte = "MURPHY","BAILEY","RIVERA","COOPER","RICHARDSON","COX",
data     byte = "HOWARD","WARD","TORRES","PETERSON","GRAY","RAMIREZ",
data     byte = "JAMES","WATSON","BROOKS","KELLY","SANDERS","PRICE",
data     byte = "BENNETT","WOOD","BARNES","ROSS","HENDERSON","COLEMAN",
data     byte = "JENKINS","PERRY","POWELL","LONG","PATTERSON","HUGHES",
data     byte = "FLORES","WASHINGTON","BUTLER","SIMMONS","FOSTER","GONZALES",
data     byte = "BRYANT","ALEXANDER","RUSSELL","GRIFFIN","DIAZ","HAYES",
data     byte = "MYERS","FORD","HAMILTON","GRAHAM","SULLIVAN","WALLACE",
data     byte = "WOODS","COLE","WEST","JORDAN","OWENS","REYNOLDS",
data     byte = "FISHER","ELLIS","HARRISON","GIBSON","MCDONALD","CRUZ",
data     byte = "MARSHALL","ORTIZ","GOMEZ","MURRAY","FREEMAN","WELLS",
data     byte = "WEBB","SIMPSON","STEVENS","TUCKER","PORTER","HUNTER",
data     byte = "HICKS","CRAWFORD","HENRY","BOYD","MASON","MORALES",
data     byte = "KENNEDY","WARREN","DIXON","RAMOS","REYES","BURNS",
data     byte = "GORDON","SHAW","HOLMES","RICE","ROBERTSON","HUNT",
data     byte = "BLACK","DANIELS","PALMER","MILLS","NICHOLS","GRANT",
data     byte = "KNIGHT","FERGUSON","ROSE","STONE","HAWKINS","DUNN",
data     byte = "PERKINS","HUDSON","SPENCER","GARDNER","STEPHENS","PAYNE",
data     byte = "PIERCE","BERRY","MATTHEWS","ARNOLD","WAGNER","WILLIS",
data     byte = "RAY","WATKINS","OLSON","CARROLL","DUNCAN","SNYDER",
data     byte = "HART","CUNNINGHAM","BRADLEY","LANE","ANDREWS","RUIZ",
data     byte = "HARPER","FOX","RILEY","ARMSTRONG","CARPENTER","WEAVER",
data     byte = "GREENE","LAWRENCE","ELLIOTT","CHAVEZ","SIMS","AUSTIN",
data     byte = "PETERS","KELLEY","FRANKLIN","LAWSON","FIELDS","GUTIERREZ",
data     byte = "RYAN","SCHMIDT","CARR","VASQUEZ","CASTILLO","WHEELER",
data     byte = "CHAPMAN","OLIVER","MONTGOMERY","RICHARDS","WILLIAMSON","JOHNSTON",
data     byte = "BANKS","MEYER","BISHOP","MCCOY","HOWELL","ALVAREZ",
data     byte = "MORRISON","HANSEN","FERNANDEZ","GARZA","HARVEY","LITTLE",
data     byte = "BURTON","STANLEY","NGUYEN","GEORGE","JACOBS","REID",
data     byte = "KIM","FULLER","LYNCH","DEAN","GILBERT","GARRETT",
data     byte = "ROMERO","WELCH","LARSON","FRAZIER","BURKE","HANSON",
data     byte = "DAY","MENDOZA","MORENO","BOWMAN","MEDINA","FOWLER",
data     byte = "BREWER","HOFFMAN","CARLSON","SILVA","PEARSON","HOLLAND",
data     byte = "DOUGLAS","FLEMING","JENSEN","VARGAS","BYRD","DAVIDSON",
data     byte = "HOPKINS","MAY","TERRY","HERRERA","WADE","SOTO",
data     byte = "WALTERS","CURTIS","NEAL","CALDWELL","LOWE","JENNINGS",
data     byte = "BARNETT","GRAVES","JIMENEZ","HORTON","SHELTON","BARRETT",
data     byte = "OBRIEN","CASTRO","SUTTON","GREGORY","MCKINNEY","LUCAS",
data     byte = "MILES","CRAIG","RODRIQUEZ","CHAMBERS","HOLT","LAMBERT",
data     byte = "FLETCHER","WATTS","BATES","HALE","RHODES","PENA",
data     byte = "BECK","NEWMAN","HAYNES","MCDANIEL","MENDEZ","BUSH",
data     byte = "VAUGHN","PARKS","DAWSON","SANTIAGO","NORRIS","HARDY",
data     byte = "LOVE","STEELE","CURRY","POWERS","SCHULTZ","BARKER",
data     byte = "GUZMAN","PAGE","MUNOZ","BALL","KELLER","CHANDLER",
data     byte = "WEBER","LEONARD","WALSH","LYONS","RAMSEY","WOLFE",
data     byte = "SCHNEIDER","MULLINS","BENSON","SHARP","BOWEN","DANIEL",
data     byte = "BARBER","CUMMINGS","HINES","BALDWIN","GRIFFITH","VALDEZ",
data     byte = "HUBBARD","SALAZAR","REEVES","WARNER","STEVENSON","BURGESS",
data     byte = "SANTOS","TATE","CROSS","GARNER","MANN","MACK",
data     byte = "MOSS","THORNTON","DENNIS","MCGEE","FARMER","DELGADO",
data     byte = "AGUILAR","VEGA","GLOVER","MANNING","COHEN","HARMON",
data     byte = "RODGERS","ROBBINS","NEWTON","TODD","BLAIR","HIGGINS",
data     byte = "INGRAM","REESE","CANNON","STRICKLAND","TOWNSEND","POTTER",
data     byte = "GOODWIN","WALTON","ROWE","HAMPTON","ORTEGA","PATTON",
data     byte = "SWANSON","JOSEPH","FRANCIS","GOODMAN","MALDONADO","YATES",
data     byte = "BECKER","ERICKSON","HODGES","RIOS","CONNER","ADKINS",
data     byte = "WEBSTER","NORMAN","MALONE","HAMMOND","FLOWERS","COBB",
data     byte = "MOODY","QUINN","BLAKE","MAXWELL","POPE","FLOYD",
data     byte = "OSBORNE","PAUL","MCCARTHY","GUERRERO","LINDSEY","ESTRADA",
data     byte = "SANDOVAL","GIBBS","TYLER","GROSS","FITZGERALD","STOKES",
data     byte = "DOYLE","SHERMAN","SAUNDERS","WISE","COLON","GILL",
data     byte = "ALVARADO","GREER","PADILLA","SIMON","WATERS","NUNEZ",
data     byte = "BALLARD","SCHWARTZ","MCBRIDE","HOUSTON","CHRISTENSEN","KLEIN",
data     byte = "PRATT","BRIGGS","PARSONS","MCLAUGHLIN","ZIMMERMAN","FRENCH",
data     byte = "BUCHANAN","MORAN","COPELAND","ROY","PITTMAN","BRADY",
data     byte = "MCCORMICK","HOLLOWAY","BROCK","POOLE","FRANK","LOGAN",
data     byte = "OWEN","BASS","MARSH","DRAKE","WONG","JEFFERSON",
data     byte = "PARK","MORTON","ABBOTT","SPARKS","PATRICK","NORTON",
data     byte = "HUFF","CLAYTON","MASSEY","LLOYD","FIGUEROA","CARSON",
data     byte = "BOWERS","ROBERSON","BARTON","TRAN","LAMB","HARRINGTON",
data     byte = "CASEY","BOONE","CORTEZ","CLARKE","MATHIS","SINGLETON",
data     byte = "WILKINS","CAIN","BRYAN","UNDERWOOD","HOGAN","MCKENZIE",
data     byte = "COLLIER","LUNA","PHELPS","MCGUIRE","ALLISON","BRIDGES",
data     byte = "WILKERSON","NASH","SUMMERS","ATKINS","WILCOX","PITTS",
data     byte = "CONLEY","MARQUEZ","BURNETT","RICHARD","COCHRAN","CHASE",
data     byte = "DAVENPORT","HOOD","GATES","CLAY","AYALA","SAWYER",
data     byte = "ROMAN","VAZQUEZ","DICKERSON","HODGE","ACOSTA","FLYNN",
data     byte = "ESPINOZA","NICHOLSON","MONROE","WOLF","MORROW","KIRK",
data     byte = "RANDALL","ANTHONY","WHITAKER","OCONNOR","SKINNER","WARE",
data     byte = "MOLINA","KIRBY","HUFFMAN","BRADFORD","CHARLES","GILMORE",
data     byte = "DOMINGUEZ","ONEAL","BRUCE","LANG","COMBS","KRAMER",
data     byte = "HEATH","HANCOCK","GALLAGHER","GAINES","SHAFFER","SHORT",
data     byte = "WIGGINS","MATHEWS","MCCLAIN","FISCHER","WALL","SMALL",
data     byte = "MELTON","HENSLEY","BOND","DYER","CAMERON","GRIMES",
data     byte = "CONTRERAS","CHRISTIAN","WYATT","BAXTER","SNOW","MOSLEY",
data     byte = "SHEPHERD","LARSEN","HOOVER","BEASLEY","GLENN","PETERSEN",
data     byte = "WHITEHEAD","MEYERS","KEITH","GARRISON","VINCENT","SHIELDS",
data     byte = "HORN","SAVAGE","OLSEN","SCHROEDER","HARTMAN","WOODARD",
data     byte = "MUELLER","KEMP","DELEON","BOOTH","PATEL","CALHOUN",
data     byte = "WILEY","EATON","CLINE","NAVARRO","HARRELL","LESTER",
data     byte = "HUMPHREY","PARRISH","DURAN","HUTCHINSON","HESS","DORSEY",
data     byte = "BULLOCK","ROBLES","BEARD","DALTON","AVILA","VANCE",
data     byte = "RICH","BLACKWELL","YORK","JOHNS","BLANKENSHIP","TREVINO",
data     byte = "SALINAS","CAMPOS","PRUITT","MOSES","CALLAHAN","GOLDEN",
data     byte = "MONTOYA","HARDIN","GUERRA","MCDOWELL","CAREY","STAFFORD",
data     byte = "GALLEGOS","HENSON","WILKINSON","BOOKER","MERRITT","MIRANDA",
data     byte = "ATKINSON","ORR","DECKER","HOBBS","PRESTON","TANNER",
data     byte = "KNOX","PACHECO","STEPHENSON","GLASS","ROJAS","SERRANO",
data     byte = "MARKS","HICKMAN","ENGLISH","SWEENEY","STRONG","PRINCE",
data     byte = "MCCLURE","CONWAY","WALTER","ROTH","MAYNARD","FARRELL",
data     byte = "LOWERY","HURST","NIXON","WEISS","TRUJILLO","ELLISON",
data     byte = "SLOAN","JUAREZ","WINTERS","MCLEAN","RANDOLPH","LEON",
data     byte = "BOYER","VILLARREAL","MCCALL","GENTRY","CARRILLO","KENT",
data     byte = "AYERS","LARA","SHANNON","SEXTON","PACE","HULL",
data     byte = "LEBLANC","BROWNING","VELASQUEZ","LEACH","CHANG","HOUSE",
data     byte = "SELLERS","HERRING","NOBLE","FOLEY","BARTLETT","MERCADO",
data     byte = "LANDRY","DURHAM","WALLS","BARR","MCKEE","BAUER",
data     byte = "RIVERS","EVERETT","BRADSHAW","PUGH","VELEZ","RUSH",
data     byte = "ESTES","DODSON","MORSE","SHEPPARD","WEEKS","CAMACHO",
data     byte = "BEAN","BARRON","LIVINGSTON","MIDDLETON","SPEARS","BRANCH",
data     byte = "BLEVINS","CHEN","KERR","MCCONNELL","HATFIELD","HARDING",
data     byte = "ASHLEY","SOLIS","HERMAN","FROST","GILES","BLACKBURN",
data     byte = "WILLIAM","PENNINGTON","WOODWARD","FINLEY","MCINTOSH","KOCH",
data     byte = "BEST","SOLOMON","MCCULLOUGH","DUDLEY","NOLAN","BLANCHARD",
data     byte = "RIVAS","BRENNAN","MEJIA","KANE","BENTON","JOYCE",
data     byte = "BUCKLEY","HALEY","VALENTINE","MADDOX","RUSSO","MCKNIGHT",
data     byte = "BUCK","MOON","MCMILLAN","CROSBY","BERG","DOTSON",
data     byte = "MAYS","ROACH","CHURCH","CHAN","RICHMOND","MEADOWS",
data     byte = "FAULKNER","ONEILL","KNAPP","KLINE","BARRY","OCHOA",
data     byte = "JACOBSON","GAY","AVERY","HENDRICKS","HORNE","SHEPARD",
data     byte = "HEBERT","CHERRY","CARDENAS","MCINTYRE","WHITNEY","WALLER",
data     byte = "HOLMAN","DONALDSON","CANTU","TERRELL","MORIN","GILLESPIE",
data     byte = "FUENTES","TILLMAN","SANFORD","BENTLEY","PECK","KEY",
data     byte = "SALAS","ROLLINS","GAMBLE","DICKSON","BATTLE","SANTANA",
data     byte = "CABRERA","CERVANTES","HOWE","HINTON","HURLEY","SPENCE",
data     byte = "ZAMORA","YANG","MCNEIL","SUAREZ","CASE","PETTY",
data     byte = "GOULD","MCFARLAND","SAMPSON","CARVER","BRAY","ROSARIO",
data     byte = "MACDONALD","STOUT","HESTER","MELENDEZ","DILLON","FARLEY",
data     byte = "HOPPER","GALLOWAY","POTTS","BERNARD","JOYNER","STEIN",
data     byte = "AGUIRRE","OSBORN","MERCER","BENDER","FRANCO","ROWLAND",
data     byte = "SYKES","BENJAMIN","TRAVIS","PICKETT","CRANE","SEARS",
data     byte = "MAYO","DUNLAP","HAYDEN","WILDER","MCKAY","COFFEY",
data     byte = "MCCARTY","EWING","COOLEY","VAUGHAN","BONNER","COTTON",
data     byte = "HOLDER","STARK","FERRELL","CANTRELL","FULTON","LYNN",
data     byte = "LOTT","CALDERON","ROSA","POLLARD","HOOPER","BURCH",
data     byte = "MULLEN","FRY","RIDDLE","LEVY","DAVID","DUKE",
data     byte = "ODONNELL","GUY","MICHAEL","BRITT","FREDERICK","DAUGHERTY",
data     byte = "BERGER","DILLARD","ALSTON","JARVIS","FRYE","RIGGS",
data     byte = "CHANEY","ODOM","DUFFY","FITZPATRICK","VALENZUELA"

' Create our "pointers" array, reading the data above
dim p(n)

? "Reading data... ";
s = TIME
pos = 0
for i=0 to n
  p(i) = adr(x) + pos
  pos = pos + x(pos) + 1
next
? TIME-s ; " jiffies"

? "Sorting... ";
s = TIME
' Sort - using shell-sort
data gaps() = 701, 301, 132, 57, 23, 10, 4, 1
for g=0 to 7
  gap = gaps(g)
  for i=gap to n
    temp = p(i)
    for j=i to gap step -gap
      if $(p(j - gap)) <= $(temp) then exit
      p(j) = p(j - gap)
    next
    p(j) = temp
  next
next
s = TIME - s

' Check that the array is really sorted
? : ? "Checking: ";
for i=0 to n-1
  if $(p(i)) > $(p(i+1))
    ? "Error at "; $(p(i)) ; " > " ; $(p(i+1))
    exit
  endif
next

' Show results
? : ? "Result:"
for i=0 to n
  ? $(p(i)) ; ",";
next

? : ? "Sorting time: "; s; " jiffies"
? "Press any key"
get k

 

 

I included the source ( SORTING.BAS ) and the compiled program ( SORTING.COM ) in the attached ATR.

 

Have Fun!

 

fastbasic.atr 179.64 kB · 3 downloads

WoOoOoW !

 

Bravo! Those execution timings are unbelievable...

 

The "DESTROYER" of worlds has arrived!! ??

Edited August 4, 2019 by Faicuai

[JamesD]

31 minutes ago, Faicuai said:

The bottom-line of this while discussion is:

 

1. It is quite EASY to deliberately try / make things slower and throw surgical wrenches at X,Y,Z platform and software environments.

2. It is, however, MUCH HARDER to deliberately make things MUCH faster, efficient, less resource-demanding, while still using the same HW-processing resources and clock speed.

 

Whenever anyone comes to me with a benchmark test / concept, I ONLY and automatically think of #2. Any attempt to develop and evolve a discussion around point #1 is already a dead-end street, by definition, and draws little to no interest on me, in general. There are a few exceptions, depending on what are we hunting down, of course.

 

Overall, in the case of the Atari, and when it comes to anything done in CC65 (based on #2 premise), I have found that nothing touches it on CPU-intensive work (respect to its peer group and native HW), except the BBC Micro, or anything based on Z80 running at or beyond 4 Mhz.

 

I've complained about you tuning benchmarks before. 
You tune the benchmark, say look how fast, and the other machines don't have the same optimizations.
#2 is definitely an issue when you don't make the same optimizations for all machines, and I've NEVER seen you make the same optimizations for other platforms..

You've used the CoCo 3 and a 6309 how many times?

*edit* at least I think it was you tuning benchmarks.  I'd have to look.

 

Edited August 4, 2019 by JamesD

[JamesD]

24 minutes ago, Faicuai said:

WoOoOoW !

 

Bravo! Those execution timings are unbelievable...

 

The "DESTROYER" of worlds has arrived!! ??

And it's not reading data, it's just timing the sort, it's not the same sort, compiler vs interpreter...

 

[Faicuai]

23 minutes ago, JamesD said:

I've complained about you tuning benchmarks before. 
You tune the benchmark, say look how fast, and the other machines don't have the same optimizations.
#2 is definitely an issue when you don't make the same optimizations for all machines, and I've NEVER seen you make the same optimizations for other platforms..

You've used the CoCo 3 and a 6309 how many times?

*edit* at least I think it was you tuning benchmarks.  I'd have to look.

 

Wrong!

 

Last time I did a PERFECT, code-to-code, byte-for-byte bench. Between the C64, Apple II and Atari, compiled with CC65, from the same C-source, with for the exact same CPU, with the exact same optimizations, guess what? You cried, too! "Oh!!! But it is 1.79 Mhz vs. X, Y, Z.."

 

Yeah, right... 

 

 

Edited August 4, 2019 by Faicuai

[Faicuai]

24 minutes ago, JamesD said:

And it's not reading data, it's just timing the sort, it's not the same sort, compiler vs interpreter...

 

 

Ok, let me make sure everyone here gets this as clear as possible:

 

ALL (EVERY SINGLE) of these tests are destined to throw REALLY bad timings on the Atari, running Atari Basic (or any other interpreted-level compatible substitute).

 

WHY? Because these tests require, first and foremost, constant, direct indexed access to the data structures involved (for strings, pointers, etc.) And guess what? The access to these data structures require the use of variables on which you must manipulate their values iteratively.... And guess what? ALL of these variables are FLOATS (!!!) NONE are true integers (one or two bytes) as you should for accessing arrays, string content, etc... 

 

Let's not even talk about the handling of strings, themselves, nor the internal run-time status of the interpreter (mostly using floats too!). The above factor alone brings in a HUGE execution penalty to ANY task you may want to carry on the Atari, with Atari Basic's puny 8KB footprint...

 

And the worst? Well... it turns out that we all know this before running any of these stuff, but somehow insist in throwing wrenches at it !

Edited August 4, 2019 by Faicuai

[_The Doctor__]

sigh, you have made my point for me.

as to order of lines vs execution time,

direction of sort...

it's all been covered in magazines and literature of the day, that's for sure. Why would I need to re iterate whats in print and was already proven.

I re read what I posted and don't see in the quoted paragraph where I said you discriminated against the Atari.

You took a statement about the affinity of this basic or that and how a program was written for that basic and then used on all others and can't see how a seasoned programmer of that particular form of basic and how it works wouldn't have advantages in it's native basic and machine?

The complaints I spoke of- you now speak of and pretty much make my point for me again about bench marking bias. You state the performance is what matters on the task, not how they fiddled with the driver to get the benchmark results but that isn't giving a real world result ending up making my point again. In this instance the sort is the task and it's completion is the direct result... there isn't much else to say as it's not like some obfuscated layer in a benchmark of 3d performance at the cost of clarity etc. Looks like you ended end on the same page I did.

Perhaps you were already heated up over some other stuff and only were trying to vent and be contrary because of the moment.

as I stated you end of with folks criticizing the benchmark and the manufacturer for how they got the numbers up.

 

If I remember the practice... you put the DATA to be parsed first within the beginning lines and make sure to get as much in as possible per line

you always make sure to sort from right to left in the list, that also applies to sorting from the end of data to the start...

always pick a mode that gives the cpu the most available cycles for your sort or number crunch. so on and so forth.

As examples of what to do started to be offered, a food fight ensued afterwards.

 

the topic was started by someone else and about something else if I recall anyway...

he wanted to know about approaches to getting the job done... which is what we were doing!

 

Edited August 4, 2019 by _The Doctor__

[drpeter]

7 hours ago, JamesD said:

Yes, but it's also compiled so it doesn't have to perform any parsing, or evaluate order of operations for math on the fly.
Most time consuming tasks like that are handled at compile time.
While it's not native code, the overhead is significantly lower than with a regular interpreter.

So, it compiles from source to an intermediate code, from which as I understand it the original source cannot be readily reconstructed.

Nothing inherently wrong with that, of course, but not to my mind an interpreted BASIC in the usual sense.

I guess one could however argue that BASICs like ATARI BASIC that are pre-tokenised are also, while not going so far as Fast Basic in compiling to an intermediate code, also not exactly like BASICs such as Microsoft, which are only parsed and interpreted at all at runtime.

[JamesD]

19 minutes ago, Faicuai said:

 

Ok, let me make sure everyone here gets this as clear as possible:

 

ALL (EVERY SINGLE) of these tests are destined to throw REALLY bad timings on the Atari, running Atari Basic (or any other interpreted-level compatible substitute).

 

WHY? Because these tests require, first and foremost, constant, direct indexed access to the data structures involved (for strings, pointers, etc.) And guess what? The access to these data structures require the use of variables on which you must manipulate their values iteratively.... And guess what? ALL of these variables are FLOATS (!!!) NONE are true integers (one or two bytes) as you should for accessing arrays, string content, etc... 

 

Let's not even talk about the handling of strings, themselves, nor the internal run-time status of the interpreter (mostly using floats too!). The above factor alone brings in a HUGE execution penalty to ANY task you may want to carry on the Atari, with Atari Basic's puny 8KB footprint...

 

And the worst? Well... it turns out that we all know this before running any of these stuff, but somehow insist in throwing wrenches at it !

As I said, I never designed it to benchmark anything but my own code, I never designed it to pick on the Atari. 
This is pretty standard code for a MS BASIC machine. 
I sorted an index, because it's faster than sorting strings, and it could be sorted according to any field in the data statements. 
If you want to swap strings in Atari BASIC instead, give it a try.  I'm not sure it will be any more "fair".
If you want to use assembly... then you aren't benchmarking the BASIC anymore.
If it doesn't work well on the Atari, it doesn't work well on the Atari.  So what? 

Guess what?  MS BASIC uses floats for everything on the Apple II, C64, CoCo, MC-10, Plus/4, etc... to use integers, it has to convert from floats to INTs for every index.
All addition, subtraction, multiplication, division... floats. 
Adding a constant to a variable?  It has to be converted from ASCII a byte at a time every time the code is executed, and it converts it to... a FLOAT!
There are no integer data types.  Not only that, but there are two types of floats.  Packed, and unpacked, which the interpreter has to convert between as it even processes floats.
Run time status of the interpreter... you are dealing with 16 bit ints for line numbers, a few pointers, and some bytes for are we running, # of nested FOR  loops, etc... but everything else is pretty much... FLOAT.  
I could bitch about a lot of crap in MS BASIC
Every one of these BASICs has a huge amount of overhead that shouldn't be there. 

The MC-10 ROM footprint... 8K for everything.  Standard Color BASIC on the CoCo?  8K for everything.
But the Atari is soooo picked on in it's little 8K ROM space

Part of what benchmarks do is show how one program (in this case an interpreter) is faster than another
The goal of a benchmark isn't to optimize the piss out of it until you win.  I know it's your goal, but that's not benchmarking.
You try to optimize the benchmark, change the benchmark, and then wonder why people say you missed the point. 

You did the same thing with Ahl's benchmark, and I wasn't the only one to point out that's not how a benchmark works.

Your response to Stephen (his post is 128 in that thread)... you said he was wrong because, and posted a picture of a sports car being chased by a cop.
Well, there's a great argument
 

38 minutes ago, Faicuai said:

Wrong!

 

Last time I did a PERFECT, code-to-code, byte-for-byte bench. Between the C64, Apple II and Atari, compiled with CC65, from the same C-source, with for the exact same CPU, with the exact same optimizations, guess what? You cried, too! "Oh!!! But it is 1.79 Mhz vs. X, Y, Z.."

 

Yeah, right... 

 

 

Last time?  I cried too?  What thread was this?  I would have said of course it's faster, same code, higher clock speed.
But then a IIgs, Laser 128EX, and IIc Plus are faster than an Atari because they have a faster clock speed than the Atari.
Same response, of course it's faster, same code, higher clock speed.

But this has nothing to do with benchmarking BASIC.
 

[JamesD]

2 hours ago, _The Doctor__ said:

 

If I remember the practice... you put the DATA to be parsed first within the beginning lines and make sure to get as much in as possible per line

you always make sure to sort from right to left in the list, that also applies to sorting from the end of data to the start...

always pick a mode that gives the cpu the most available cycles for your sort or number crunch. so on and so forth.

As examples of what to do started to be offered, a food fight ensued afterwards.

 

If you want to move the DATA in front of the code, and put more on a line, go for it.
I think the amount of DATA on a line was due to a line length limit, probably on the MC-10.
The DATA follows the code, because under MS BASIC any code that searches for a line # <= the current line number causes the interpreter to look for it  starting from the first line, but if Atari does it differently, that's not going to change the code that should stay the same so I have no problem with it. 

If you want to reverse the loops so they go from the bottom up, using the same core algorithm but in reverse, with the same gaps, that means you are doing the same number of compares, the same number of swaps, and the same number of passes, so I see no problem with that.

I have no problem with changing the graphics mode to make the most cycles available, or even turning off the display.  
I even tried that on the Plus/4 for the sort, and I think I already said I didn't care about that, if you are running a job for a long time or overnight, you might turn off the monitor anyway.

What I have repeatedly said I have a problem with, is switching sort algorithms for one machine, not timing the same things (skipping steps), switching to assembly language... stuff that makes it an apples and oranges comparison, rather than an Apples and Atari's comparison. 

What I did on the last timings, was read the data, sorted the index, checked the results, and printed the results.
If you want to skip any of that, I'd have to time everything over.
I also used the gap calculation in the loop that only used a multiply. 
It makes more passes, but it seemed to be a little faster, and I posted the two versions of the sort, with and without that.


*edit*  The code might not be doing the same number of swaps, but I think it won't matter much here.

Edited August 5, 2019 by JamesD