timrowledge
Posts: 1257
Joined: Mon Oct 29, 2012 8:12 pm
Location: Vancouver Island
Contact: Website

Re: Is ARM doomed?

Wed Apr 03, 2019 11:56 pm

jahboater wrote:
Sun Mar 31, 2019 9:22 am
timrowledge wrote:
Sat Mar 30, 2019 7:31 pm
Scratch is an environment for introducing people with no prior experience to the concept of programming a computer.
Scratch is brilliant for that. I used it in exactly that way to demonstrate to someone what programming was about. Brilliant.
Glad you like it - gerbils for courses, as we say.
jahboater wrote:
Sun Mar 31, 2019 9:22 am
timrowledge wrote:
Sat Mar 30, 2019 7:31 pm
Instead of dumping newcomers into a nightmare of stupid text editors and command line with ridiculous incantations
Two different problems. Scratch is not a replacement for these software tools.
Well of course not - except in the early stages.
jahboater wrote:
Sun Mar 31, 2019 9:22 am

People who complain about current software tools should write something better or be quiet. Given how clever the original authors were, I suspect that even the design of such better tools would be a significant challenge.
Been doing that for near 40 years; it's called Smalltalk. It's the only language good enough to be worth critiquing. It's still a long way from good enough despite being decades ahead of any competition.
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

timrowledge
Posts: 1257
Joined: Mon Oct 29, 2012 8:12 pm
Location: Vancouver Island
Contact: Website

Re: Is ARM doomed?

Thu Apr 04, 2019 12:02 am

Heater wrote:
Mon Apr 01, 2019 3:18 am
The IBM 360 used microcode in 1964 to implement its instruction set on a RISC-like processor.
And is therefore, in combination, not a RISC design. Arguably a prime example of CISC.
Exactly. As it happens I knew (and indeed worked with in a minor way) John Cocke, the IBMer that was a key founder of the RISC circus. I had an 801 box (the original proto-powerPC) for a while, when I was an IBM Research Fellow. I preferred the ARM as soon as I got involved with it.
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

Heater
Posts: 12136
Joined: Tue Jul 17, 2012 3:02 pm

Re: Is ARM doomed?

Thu Apr 04, 2019 1:33 am

timrowledge,
... Smalltalk. It's the only language good enough to be worth critiquing.
Wow, that is a bold statement!

I notice Smalltalk accommodates LargeIntegers, that is a good start, you are invited to contribute a solution to the fibo(4784969) challenge here:

viewtopic.php?f=62&t=227343
https://github.com/ZiCog/fibo_4784969

I promise not to do any Smalltalk critiquing unless it proves itself good enough :)

jahboater
Posts: 4182
Joined: Wed Feb 04, 2015 6:38 pm

Re: Is ARM doomed?

Thu Apr 04, 2019 1:49 am

timrowledge,
Did you know that Scratch comes in position 25 here?
https://www.tiobe.com/tiobe-index/
0.549% of programmers are actually using it.
Impressive, and incidentally, much higher than Smalltalk which doesn't come into the top 100 (though it is tracked).

ejolson
Posts: 2867
Joined: Tue Mar 18, 2014 11:47 am

Re: Is ARM doomed?

Thu Apr 04, 2019 2:28 am

jahboater wrote:
Thu Apr 04, 2019 1:49 am
timrowledge,
Did you know that Scratch comes in position 25 here?
https://www.tiobe.com/tiobe-index/
0.549% of programmers are actually using it.
Impressive, and incidentally, much higher than Smalltalk which doesn't come into the top 100 (though it is tracked).
I find it amusing that Visual Basic ranks above JavaScript in TIOBE popularity. I wonder what the ranking would look like if only the doomed ARM programmers were surveyed.

Heater
Posts: 12136
Joined: Tue Jul 17, 2012 3:02 pm

Re: Is ARM doomed?

Thu Apr 04, 2019 3:24 am

Disturbingly VisualBasic .NET has been steadily climbing up the TIOBE index since 2012.

timrowledge
Posts: 1257
Joined: Mon Oct 29, 2012 8:12 pm
Location: Vancouver Island
Contact: Website

Re: Is ARM doomed?

Thu Apr 04, 2019 6:24 pm

jahboater wrote:
Thu Apr 04, 2019 1:49 am
timrowledge,
Did you know that Scratch comes in position 25 here?
https://www.tiobe.com/tiobe-index/
0.549% of programmers are actually using it.
Impressive, and incidentally, much higher than Smalltalk which doesn't come into the top 100 (though it is tracked).
And the point is what, exactly? When did 'popularity' have a lot to do with 'quality' - in any of the senses of those two words? Your metrics are in error.
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

jahboater
Posts: 4182
Joined: Wed Feb 04, 2015 6:38 pm

Re: Is ARM doomed?

Thu Apr 04, 2019 6:31 pm

timrowledge wrote:
Thu Apr 04, 2019 6:24 pm
jahboater wrote:
Thu Apr 04, 2019 1:49 am
timrowledge,
Did you know that Scratch comes in position 25 here?
https://www.tiobe.com/tiobe-index/
0.549% of programmers are actually using it.
Impressive, and incidentally, much higher than Smalltalk which doesn't come into the top 100 (though it is tracked).
And the point is what, exactly? When did 'popularity' have a lot to do with 'quality' - in any of the senses of those two words? Your metrics are in error.
I was impressed that Scratch reached position 25 ahead of many conventional languages (assuming its not something else with the same name). And the more conventional language it was originally written in is behind. I thought Scratch was just for teaching.

TIOBE is about the number of programmers using each language in the world, it says nothing about the quality of the language, or its speed, or the number of lines of code implemented in it.

Having said that, there are obvious benefits in using a popular language. Its easy to find people to help if you have a problem, there will be many support libraries available, high quality compilers or interpreters are readily available, and so on.

Heater
Posts: 12136
Joined: Tue Jul 17, 2012 3:02 pm

Re: Is ARM doomed?

Thu Apr 04, 2019 6:51 pm

TIOBE clearly states that their index is to be taken with a pinch of salt:

"Popular search engines such as Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube and Baidu are used to calculate the ratings. It is important to note that the TIOBE index is not about the best programming language or the language in which most lines of code have been written."

One might argue that the harder it is to do something in a language the more poor schmucks that are paid to use it have to search the web for solutions. The opposite of "popular" or "best". That accounts for the high ranking of Java, Visual Basic .Net, C#, Objective C, and PHP.

Also, nobody is writing real software in Scratch, but what with it's promotion in education here and elsewhere it cranks up the search ratings as kids post questions all over the place.

That is the pinch of salt I take the TIOBE with, and I'm sticking to it. :)

timrowledge
Posts: 1257
Joined: Mon Oct 29, 2012 8:12 pm
Location: Vancouver Island
Contact: Website

Re: Is ARM doomed?

Thu Apr 04, 2019 6:59 pm

Heater wrote:
Thu Apr 04, 2019 1:33 am
timrowledge,
... Smalltalk. It's the only language good enough to be worth critiquing.
Wow, that is a bold statement!
It's pointless to make mealy-mouthed statements. Waste of breath.
Heater wrote:
Thu Apr 04, 2019 1:33 am
I notice Smalltalk accommodates LargeIntegers, that is a good start, you are invited to contribute a solution to the fibo(4784969) challenge here:

viewtopic.php?f=62&t=227343
https://github.com/ZiCog/fibo_4784969

I promise not to do any Smalltalk critiquing unless it proves itself good enough :)
A pretty pointless 'test' there. I suppose it has some value in demonstrating that you can handle large numbers without collapsing into floats when needed. Which Smalltalk has been doing for a very, very, long time. We do actually use it with a very simple-minded implementation as a way of quickly estimating how many message sends per second the system can do - turns out that to tolerable accuracy the result divided by the seconds to run is the number of message sends executed.
The implementation we use for this is hardly optimised, but that's not the point for our test -

Code: Select all

benchFib  "Handy send-heavy benchmark"
	"(result // seconds to run) = approx calls per second"
	" | r t |
	  t := Time millisecondsToRun: [r := 26 benchFib].
	  (r * 1000) // t"
	"138000 on a Mac 8100/100 in 1996. 19,000,000 on a Pi3 in 2018"
	^ self < 2
		ifTrue: [1] 
		ifFalse: [(self-1) benchFib + (self-2) benchFib + 1]
Performance-wise that code sucks. Am I bothered? Guess. There's an awful lot of more important factors in the value of a language.
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

jahboater
Posts: 4182
Joined: Wed Feb 04, 2015 6:38 pm

Re: Is ARM doomed?

Thu Apr 04, 2019 7:01 pm

Heater wrote:
Thu Apr 04, 2019 6:51 pm
One might argue that the harder it is to do something in a language the more poor schmucks that are paid to use it have to search the web for solutions. The opposite of "popular" or "best". That accounts for the high ranking of Java, Visual Basic .Net, C#, Objective C, and PHP.
Yes, also if you look at the number of topics and posts in each section of the "programming languages" part of this forum, there is a clear lead for Python. Although it is likely the most popular language on the Pi, does it just mean that there are more beginners using it and asking more questions, or the language is hard to use - so people ask more questions.

Heater
Posts: 12136
Joined: Tue Jul 17, 2012 3:02 pm

Re: Is ARM doomed?

Thu Apr 04, 2019 8:23 pm

timrowledge,
A pretty pointless 'test' there. I suppose it has some value in demonstrating that you can handle large numbers without collapsing into floats when needed.
Yes, mostly useless. Like many such benchmarks/examples/challenges. Mostly for fun. I learned a few things along the way.

As I have said a few times already: While the fibo(4784969) challenge requires producing a million digit result, big integers are not the main point. The point was to require an algorithm that is not to complex but not too trivial so as to show off how easy it is to write in a language, how easy it is for others to read and understand. It's about expressiveness , comprehensibility, elegance, aesthetics. Performance is a secondary concern.

I think you may have missed a point, collapsing to regular floats for big numbers will not produce the correct result.
Performance-wise that code sucks. Am I bothered? Guess. There's an awful lot of more important factors in the value of a language.
Yes exactly. See above.

Now, about your benchFib example above:

1) Could you explain what all that line noise means? Perhaps it's me but it's unintelligible. If I squint hard I can just about make out a recursive fibo in there.

2) How do I run it? It fails for me:

Code: Select all

$ cat fibo.st
benchFib  "Handy send-heavy benchmark"
        "(result // seconds to run) = approx calls per second"
        " | r t |
          t := Time millisecondsToRun: [r := 26 benchFib].
          (r * 1000) // t"
        "138000 on a Mac 8100/100 in 1996. 19,000,000 on a Pi3 in 2018"
        ^ self < 2
                ifTrue: [1]
                ifFalse: [(self-1) benchFib + (self-2) benchFib + 1]

$ gst fibo.st
Object: nil error: did not understand #<
MessageNotUnderstood(Exception)>>signal (ExcHandling.st:254)
UndefinedObject(Object)>>doesNotUnderstand: #< (SysExcept.st:1448)
UndefinedObject>>executeStatements (fibo.st:7)
$

ejolson
Posts: 2867
Joined: Tue Mar 18, 2014 11:47 am

Re: Is ARM doomed?

Fri Apr 05, 2019 5:12 am

timrowledge wrote:
Thu Apr 04, 2019 6:59 pm
A pretty pointless 'test' there. I suppose it has some value in demonstrating that you can handle large numbers without collapsing into floats when needed.
From a computer science, mathematics and historical point of view Karatsuba multiplication was the first example of a conquer and divide algorithm that performed asymptotically faster than the standard method. It is a common topic in a university-level algorithms class. However, it could be taught much earlier, because unlike other divide and conquer algorithms (such as the fast Fourier transform), Karatsuba multiplication involves only the simple arithmetic learned in grade school. Moreover, in a Goldilocks sort of way the complexity of coding Karatsuba multiplication is just right: slightly more difficult than merge sort but easier than bipartite matching.

Arguably everything on Earth is pointless. Indeed, King Solomon himself, not to be outdone by the three bears, once uttered the timeless wisdom that this too shall pass. Even so, computing the 4784969th Fibonacci number by means of the doubling formula and other identities makes for a pointed, if not eternal, application of Karatsuba's algorithm.

On the other hand, turning this thread into the Fibonacci code seems even more doomed than ARM when there is already another thread that has suffered a similar fate. Maybe we should continue the smalltalk in that other thread.

jahboater
Posts: 4182
Joined: Wed Feb 04, 2015 6:38 pm

Re: Is ARM doomed?

Sat Apr 06, 2019 7:42 am

Heater wrote:
Thu Apr 04, 2019 8:23 pm
Now, about your benchFib example above:

1) Could you explain what all that line noise means? Perhaps it's me but it's unintelligible. If I squint hard I can just about make out a recursive fibo in there.

2) How do I run it? It fails for me:

Code: Select all

$ cat fibo.st
benchFib  "Handy send-heavy benchmark"
        "(result // seconds to run) = approx calls per second"
        " | r t |
          t := Time millisecondsToRun: [r := 26 benchFib].
          (r * 1000) // t"
        "138000 on a Mac 8100/100 in 1996. 19,000,000 on a Pi3 in 2018"
        ^ self < 2
                ifTrue: [1]
                ifFalse: [(self-1) benchFib + (self-2) benchFib + 1]

$ gst fibo.st
Object: nil error: did not understand #<
MessageNotUnderstood(Exception)>>signal (ExcHandling.st:254)
UndefinedObject(Object)>>doesNotUnderstand: #< (SysExcept.st:1448)
UndefinedObject>>executeStatements (fibo.st:7)
$
Is this a difference between Gnu smalltalk and smalltalk-80 ?

There is no # character in the program, so it might be something internal.

A small hello world program runs fine.

19,000,000 messages per second seems quite an overhead for a Raspberry Pi.

Heater
Posts: 12136
Joined: Tue Jul 17, 2012 3:02 pm

Re: Is ARM doomed?

Sat Apr 06, 2019 8:15 am

The error message says the error is on line 7:

Code: Select all

^ self < 2
As far as I can make out the "^" indicates we are about to define our return value.

We then send a "<" message to ourselves. The message contains a "2".

Apparently this message is not understood. Which is hardly surprising as I have not defined a "<" message handler for myself.

A quick google for how to do comparisons in gnusmalltalk gets us nowhere. The gnu smalltalk manual finally mentions conditions and decision making near the end, after 3 or 4 chapters of how to program with objects. It did not help.

This is might be madness too far for me.

jahboater
Posts: 4182
Joined: Wed Feb 04, 2015 6:38 pm

Re: Is ARM doomed?

Sat Apr 06, 2019 8:37 am

There is a handy interactive mode just like Python:

Code: Select all

st> 3 < 4
Object: false error: did not understand #<
MessageNotUnderstood(Exception)>>signal (ExcHandling.st:254)
False(Object)>>doesNotUnderstand: #< (SysExcept.st:1448)
UndefinedObject>>executeStatements (a String:2)
nil
st> 3 + 4
7
st> 3 < 4
true
st> 
Looks like the "<" message gets defined eventually.

Heater
Posts: 12136
Joined: Tue Jul 17, 2012 3:02 pm

Re: Is ARM doomed?

Sat Apr 06, 2019 9:20 am

WTF? I did not get that:

$ gst
GNU Smalltalk ready

Code: Select all

st> 3 < 4
true
st> 3 > 4
false
st> 3 = 4
false
st>
I think I found out why Smalltalk does not even show up on the TIOBE index.

stuartiannaylor

Re: Is ARM doomed?

Sat Apr 06, 2019 10:51 am

I have no idea why the OP gets that idea.

It is interesting though as rather than doomed maybe we should say is it no longer exciting and boring as it emerges into main stream computing.

There seems to be much interest in what a Pi4 will be and personally think its going to be later or Raspberry is going to have to have a think about its relationship with Broadcom as there are some extremely strong chips such as the RK3399 and various others that currently are near impossible to beat.

Back to the OP though and hasn't RISC already been hurdled with Thumb2 and is ongoing.. ?
https://pagefault.blog/2017/05/03/why-a ... -in-yocto/

Is Raspberry doomed? As what are they going to do with the Pi4 as it will need to be approx RK3399 but guess the wait is for the question of process.
28 nm HKMG vs TSMC 16 nm FFC or smaller?

Even with all the speculation of a Pi4 for me personally it is quite boring as have a reasonable idea of what we will get prob 28nm and nothing really spectacular.
Raspberry needs to have a look to see if their partnership with Broadcom impacts on the choice of process as what could be far more exciting is what can they do with the Pi-Zero-2 as for IoT and makers that is an extremely interesting area, that maybe doesn't necessitate what is essentially reasonable 'Chromebook' style computing power.
Do they need to jump process where the Zero format of next gen process is where the excitement is at?

ejolson
Posts: 2867
Joined: Tue Mar 18, 2014 11:47 am

Re: Is ARM doomed?

Sat Apr 06, 2019 3:22 pm

stuartiannaylor wrote:
Sat Apr 06, 2019 10:51 am
I have no idea why the OP gets that idea.
The same research power house that brought us the IEEE 754 floating-point standard with the mathematical discovery of both plus and minus zero have now designed an entire CPU architecture around integer arithmetic without a carry operation. As such, the new RISC-V machines are so well suited for running Scratch in a Smalltalk environment that many others are doomed.

As you have noted there is plenty of doom to go around. If only I could find my Byte magazine

Image

I could read about all the advances that are yet to come.

jahboater
Posts: 4182
Joined: Wed Feb 04, 2015 6:38 pm

Re: Is ARM doomed?

Sat Apr 06, 2019 3:57 pm

:lol:
ejolson wrote:
Sat Apr 06, 2019 3:22 pm
The same research power house that brought us the IEEE 754 floating-point standard with the mathematical discovery of both plus and minus zero
That's just a consequence of sign-magnitude representation.
Thank heavens "x == 0.0" is true for both signs, apart from when "x == x" is always false.
They also complicated infinity with the choice of affine closure or projective closure ...

Heater
Posts: 12136
Joined: Tue Jul 17, 2012 3:02 pm

Re: Is ARM doomed?

Sat Apr 06, 2019 4:39 pm

ejolson,

Wow, can't wait.

I don't recall needing a carry bit since I stopped trying to do 16 bit maths on 8 bit machines, or 32 bit maths on 16 bit machines in assembler.

Until you got me doing the Karatuba Shuffle that is...

Heater
Posts: 12136
Joined: Tue Jul 17, 2012 3:02 pm

Re: Is ARM doomed?

Sat Apr 06, 2019 4:43 pm

x == 0.0 being true sometimes is great and all. But if you are testing floats for equality it will end in tears.

jahboater
Posts: 4182
Joined: Wed Feb 04, 2015 6:38 pm

Re: Is ARM doomed?

Sat Apr 06, 2019 5:15 pm

Heater wrote:
Sat Apr 06, 2019 4:43 pm
x == 0.0 being true sometimes is great and all. But if you are testing floats for equality it will end in tears.
Yes, if x is any type of NaN, then x != x is always true.

Heater
Posts: 12136
Joined: Tue Jul 17, 2012 3:02 pm

Re: Is ARM doomed?

Sat Apr 06, 2019 5:23 pm

That is not what I meant.

The issue is that floats are fluffy things. You may know that some result should be some value or other but due to rounding errors it will not be in floats.

See here:
https://floating-point-gui.de/errors/comparison/
https://www.appmarq.com/public/security ... r-equality

jahboater
Posts: 4182
Joined: Wed Feb 04, 2015 6:38 pm

Re: Is ARM doomed?

Sat Apr 06, 2019 5:34 pm

Heater wrote:
Sat Apr 06, 2019 5:23 pm
That is not what I meant.

The issue is that floats are fluffy things. You may know that some result should be some value or other but due to rounding errors it will not be in floats.

See here:
https://floating-point-gui.de/errors/comparison/
https://www.appmarq.com/public/security ... r-equality
Oh yes of course. It's only safe if x is a representable integer.

I came up with this idea for a "~=" operator for my calculator, it compares to the same precision as the display is set to, so that if it appears equal to the user then ~= returns a match. I still allow == for reals - its the users problem if the fluffyness catches them out!

Do you think this is a daft idea? I would be interested in your opinion as I have never seen it done elsewhere, people always mess with an epsilon value.

Code: Select all

/*
 *  Floating-point fuzzy equality test (~=).
 *  Compare to the same precision as the display.
 */
static inline pure bool
fpequal( const real left, const real right )
{
  if( left == right )  // deal with +/- zero and genuine equality
    return yes;
  string a, b;
  const int len = print_real( a, left );
  return print_real( b, right ) == len && cmp( a, b, len );
}

Return to “Off topic discussion”