Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #39887 > unrolled thread

Loop optimisation.

Back to article view | Back to comp.lang.javascript

Contents

  Loop optimisation. The Natural Philosopher <tnp@invalid.invalid> - 2021-04-10 18:41 +0100
    Re: Loop optimisation. John G Harris <niam@jghnorth.org.uk.invalid> - 2021-04-10 19:14 +0100
      Re: Loop optimisation. The Natural Philosopher <tnp@invalid.invalid> - 2021-04-11 11:33 +0100
        Re: Loop optimisation. John G Harris <niam@jghnorth.org.uk.invalid> - 2021-04-11 15:03 +0100
          Re: Loop optimisation. "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-04-11 07:38 -0700
            Re: Loop optimisation. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-11 13:36 -0700
            Re: Loop optimisation. John G Harris <niam@jghnorth.org.uk.invalid> - 2021-04-12 18:05 +0100
              Re: Loop optimisation. The Natural Philosopher <tnp@invalid.invalid> - 2021-04-12 23:16 +0100
                Re: Loop optimisation. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-13 05:19 -0700
                  Re: Loop optimisation. "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-04-13 06:21 -0700
          Re: Loop optimisation. The Natural Philosopher <tnp@invalid.invalid> - 2021-04-12 01:36 +0100
            Re: Loop optimisation. John G Harris <niam@jghnorth.org.uk.invalid> - 2021-04-12 18:04 +0100
              Re: Loop optimisation. The Natural Philosopher <tnp@invalid.invalid> - 2021-04-12 23:09 +0100
                Re: Loop optimisation. John G Harris <niam@jghnorth.org.uk.invalid> - 2021-04-13 20:08 +0100
                  Re: Loop optimisation. The Natural Philosopher <tnp@invalid.invalid> - 2021-04-13 21:41 +0100
                    Re: Loop optimisation. John G Harris <niam@jghnorth.org.uk.invalid> - 2021-04-14 18:24 +0100
    Re: Loop optimisation. Kristjan Robam <he12457@hotmail.com> - 2021-04-10 13:36 -0700
      Re: Loop optimisation. The Natural Philosopher <tnp@invalid.invalid> - 2021-04-11 11:34 +0100
    Re: Loop optimisation. "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-04-10 22:22 -0700
      Re: Loop optimisation. The Natural Philosopher <tnp@invalid.invalid> - 2021-04-11 11:36 +0100
      Re: Loop optimisation. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2021-04-14 02:20 +0200
        Re: Loop optimisation. "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-04-14 06:48 -0700
          Re: Loop optimisation. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2021-04-14 17:31 +0200
            Re: Loop optimisation. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2021-04-14 18:00 +0200
              Re: Loop optimisation. The Natural Philosopher <tnp@invalid.invalid> - 2021-04-14 19:25 +0100
              Re: Loop optimisation. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2021-04-14 23:10 +0200
                Re: Loop optimisation. "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-04-17 09:45 -0700
              Re: Loop optimisation. "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-04-17 09:43 -0700
                Re: Loop optimisation. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2021-04-17 21:45 +0200
                  Re: Loop optimisation. Scott Sauyet <scott.sauyet@gmail.com> - 2021-04-18 19:06 -0700
            Re: Loop optimisation. "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-04-17 08:50 -0700

Page 1 of 2  [1] 2  Next page →

#39887 — Loop optimisation.

Does Js do it?

I have some close to real time audio processing code and I want it to 
run floating point on a raspberry Pi - no FP coprocessors so no wasted 
cycles required.

The question is - in C if you do something like

function (int x)
for(somecondition)
	if (x greater than whatever)
		extra blah;
         else completely different blah;
endfor

will one hopes result in two completely different loops being 
established so that conditionl is actually  evaluated outside the loop - 
i.e

function (int x)
if (x greater than whatever)
	for(somecondition)
		extra blah;
	endfor
else
	for(somecondition)
		completely different blah;
	endfor
endif

is what a decent compiler optimised for speed might well do.

Does javascript though?

And of course Javascript makes all numbers floating point...so the 
comparison will be cycle hungry comparing  two floats


-- 
Of what good are dead warriors? … Warriors are those who desire battle 
more than peace. Those who seek battle despite peace. Those who thump 
their spears on the ground and talk of honor. Those who leap high the 
battle dance and dream of glory … The good of dead warriors, Mother, is 
that they are dead.
Sheri S Tepper: The Awakeners.

[toc] | [next] | [standalone]

#39889

On Sat, 10 Apr 2021 18:41:00 +0100, The Natural Philosopher
<tnp@invalid.invalid> wrote:

  <snip>
>is what a decent compiler optimised for speed might well do.
>
>Does javascript though?

ECMA 262 permits any optimisation that ends up giving the specified
result.

If you want an answer you must write to Microsoft, Mozilla, Google,
etc. I predict you won't get an answer from any of them.


>And of course Javascript makes all numbers floating point...so the 
>comparison will be cycle hungry comparing  two floats

In a super-computer floating point operations are very, very, very
fast, so what's the problem?

  John

[toc] | [prev] | [next] | [standalone]

#39895

On 10/04/2021 19:14, John G Harris wrote:
> On Sat, 10 Apr 2021 18:41:00 +0100, The Natural Philosopher
> <tnp@invalid.invalid> wrote:
> 
>    <snip>
>> is what a decent compiler optimised for speed might well do.
>>
>> Does javascript though?
> 
> ECMA 262 permits any optimisation that ends up giving the specified
> result.
> 
> If you want an answer you must write to Microsoft, Mozilla, Google,
> etc. I predict you won't get an answer from any of them.
> 
> 
Actually people have done tests. I looked that up later...

Google chrome optimises, Firefox not so much

>> And of course Javascript makes all numbers floating point...so the
>> comparison will be cycle hungry comparing  two floats
> 
> In a super-computer floating point operations are very, very, very
> fast, so what's the problem?

A Raspberry Pi is not a super computer?

I have a ms or so to run a 256 cycle iteration with quite a lot of FP 
potentially

However my basic audio code seems stutter free on a crap mobile phone 
running firefox, on android, so there is plenty of hope.
> 
>    John
> 


-- 
Of what good are dead warriors? … Warriors are those who desire battle 
more than peace. Those who seek battle despite peace. Those who thump 
their spears on the ground and talk of honor. Those who leap high the 
battle dance and dream of glory … The good of dead warriors, Mother, is 
that they are dead.
Sheri S Tepper: The Awakeners.

[toc] | [prev] | [next] | [standalone]

#39901

On Sun, 11 Apr 2021 11:33:04 +0100, The Natural Philosopher
<tnp@invalid.invalid> wrote:

  <snip>
>I have a ms or so to run a 256 cycle iteration with quite a lot of FP 
>potentially
>
>However my basic audio code seems stutter free on a crap mobile phone 
>running firefox, on android, so there is plenty of hope.

You're doing real time code in a web browser, using a language that
assumes an autonomous garbage collector! You've picked the wrong tools
to do the job. And next year a cart horse will win the Derby.

  John

[toc] | [prev] | [next] | [standalone]

#39902

On Sunday, April 11, 2021 at 9:03:51 AM UTC-5, John G Harris wrote:
> On Sun, 11 Apr 2021 11:33:04 +0100, The Natural Philosopher 
> <t...@invalid.invalid> wrote: 
> 
> <snip>
> >I have a ms or so to run a 256 cycle iteration with quite a lot of FP 
> >potentially 
> > 
> >However my basic audio code seems stutter free on a crap mobile phone 
> >running firefox, on android, so there is plenty of hope.
> You're doing real time code in a web browser, using a language that 
> assumes an autonomous garbage collector! You've picked the wrong tools 
> to do the job. And next year a cart horse will win the Derby. 

JavaScript is fine for this. The Garbage Collector does not run entirely in the same thread [1]. You will *maybe* have a 5ms pause or less. That's assuming there is garbage to be collected in the first place.

"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." -- Donald Knuth

If it starts to become an issue ServiceWorkers exist for running in an additional thread. I doubt it would be needed here.


[1] <https://v8.dev/blog/trash-talk>

[toc] | [prev] | [next] | [standalone]

#39903

söndag 11 april 2021 kl. 16:38:26 UTC+2 skrev Michael Haufe (TNO):
> On Sunday, April 11, 2021 at 9:03:51 AM UTC-5, John G Harris wrote: 
> > On Sun, 11 Apr 2021 11:33:04 +0100, The Natural Philosopher 
> > <t...@invalid.invalid> wrote: 
> > 
> > <snip> 
> > >I have a ms or so to run a 256 cycle iteration with quite a lot of FP 
> > >potentially 
> > > 
> > >However my basic audio code seems stutter free on a crap mobile phone 
> > >running firefox, on android, so there is plenty of hope. 
> > You're doing real time code in a web browser, using a language that 
> > assumes an autonomous garbage collector! You've picked the wrong tools 
> > to do the job. And next year a cart horse will win the Derby.
> JavaScript is fine for this. The Garbage Collector does not run entirely in the same thread [1]. You will *maybe* have a 5ms pause or less. That's assuming there is garbage to be collected in the first place. 
> 
> "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." -- Donald Knuth 
> 
> If it starts to become an issue ServiceWorkers exist for running in an additional thread. I doubt it would be needed here. 
> 
> 
> [1] <https://v8.dev/blog/trash-talk>
Maybe there is no problem for serialise samples of recorded material to play.
But for midinotes it certainly is playing  some 10 -32 scheduled notes every second.

[toc] | [prev] | [next] | [standalone]

#39909

On Sun, 11 Apr 2021 07:38:21 -0700 (PDT), "Michael Haufe (TNO)"
<tno@thenewobjective.com> wrote:

>On Sunday, April 11, 2021 at 9:03:51 AM UTC-5, John G Harris wrote:
>> On Sun, 11 Apr 2021 11:33:04 +0100, The Natural Philosopher 
>> <t...@invalid.invalid> wrote: 
>> 
>> <snip>
>> >I have a ms or so to run a 256 cycle iteration with quite a lot of FP 
>> >potentially 
>> > 
>> >However my basic audio code seems stutter free on a crap mobile phone 
>> >running firefox, on android, so there is plenty of hope.

>> You're doing real time code in a web browser, using a language that 
>> assumes an autonomous garbage collector! You've picked the wrong tools 
>> to do the job. And next year a cart horse will win the Derby. 
>
>JavaScript is fine for this. The Garbage Collector does not run entirely in the same thread [1]. You will *maybe* have a 5ms pause or less. That's assuming there is garbage to be collected in the first place.
>
>"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." -- Donald Knuth

All very true, but I'm talking about chunks of code that have a hard
deadline. If you measure it and it's close to the limit then you can't
afford to have unspecified, unquantified, uncontrollable hiccups. This
is especially so with write once, run everywhere, code.

Of course, if hiccups are acceptable then it's not a problem, nor is
that a reason for complaining about the language.

  John

[toc] | [prev] | [next] | [standalone]

#39914

On 12/04/2021 18:05, John G Harris wrote:
> On Sun, 11 Apr 2021 07:38:21 -0700 (PDT), "Michael Haufe (TNO)" 
> <tno@thenewobjective.com> wrote:
> 
>> On Sunday, April 11, 2021 at 9:03:51 AM UTC-5, John G Harris
>> wrote:
>>> On Sun, 11 Apr 2021 11:33:04 +0100, The Natural Philosopher 
>>> <t...@invalid.invalid> wrote:
>>> 
>>> <snip>
>>>> I have a ms or so to run a 256 cycle iteration with quite a lot
>>>> of FP potentially
>>>> 
>>>> However my basic audio code seems stutter free on a crap mobile
>>>> phone running firefox, on android, so there is plenty of hope.
> 
>>> You're doing real time code in a web browser, using a language
>>> that assumes an autonomous garbage collector! You've picked the
>>> wrong tools to do the job. And next year a cart horse will win
>>> the Derby.
>> 
>> JavaScript is fine for this. The Garbage Collector does not run
>> entirely in the same thread [1]. You will *maybe* have a 5ms pause
>> or less. That's assuming there is garbage to be collected in the
>> first place.
>> 
>> "Programmers waste enormous amounts of time thinking about, or
>> worrying about, the speed of noncritical parts of their programs,
>> and these attempts at efficiency actually have a strong negative
>> impact when debugging and maintenance are considered. We should
>> forget about small efficiencies, say about 97% of the time:
>> premature optimization is the root of all evil. Yet we should not
>> pass up our opportunities in that critical 3%." -- Donald Knuth
> 
> All very true, but I'm talking about chunks of code that have a hard 
> deadline. If you measure it and it's close to the limit then you
> can't afford to have unspecified, unquantified, uncontrollable
> hiccups. This is especially so with write once, run everywhere,
> code.
> 
> Of course, if hiccups are acceptable then it's not a problem, nor is 
> that a reason for complaining about the language.
> 
My complaint is less about JavaScript, than the fashionable approach 
that insists that just because they learnt it and CompSci school every 
API must now consist of objects and classes - mostly ill thought out and 
obscure - that defy clear documentation, and make the job of actually 
using them almost impossible.

Why does Jquery exist? To cover up the shit that is the underlying 
horror of the DOM and the language implementations.



> John
> 


-- 
Renewable energy: Expensive solutions that don't work to a problem that
doesn't exist instituted by self legalising protection rackets that
don't protect,  masquerading as public servants who don't serve the public.

[toc] | [prev] | [next] | [standalone]

#39916

tisdag 13 april 2021 kl. 00:16:21 UTC+2 skrev The Natural Philosopher:
> On 12/04/2021 18:05, John G Harris wrote: 
> > On Sun, 11 Apr 2021 07:38:21 -0700 (PDT), "Michael Haufe (TNO)" 
> > <t...@thenewobjective.com> wrote: 
> > 
> >> On Sunday, April 11, 2021 at 9:03:51 AM UTC-5, John G Harris 
> >> wrote: 
> >>> On Sun, 11 Apr 2021 11:33:04 +0100, The Natural Philosopher 
> >>> <t...@invalid.invalid> wrote: 
> >>> 
> >>> <snip> 
> >>>> I have a ms or so to run a 256 cycle iteration with quite a lot 
> >>>> of FP potentially 
> >>>> 
> >>>> However my basic audio code seems stutter free on a crap mobile 
> >>>> phone running firefox, on android, so there is plenty of hope. 
> > 
> >>> You're doing real time code in a web browser, using a language 
> >>> that assumes an autonomous garbage collector! You've picked the 
> >>> wrong tools to do the job. And next year a cart horse will win 
> >>> the Derby. 
> >> 
> >> JavaScript is fine for this. The Garbage Collector does not run 
> >> entirely in the same thread [1]. You will *maybe* have a 5ms pause 
> >> or less. That's assuming there is garbage to be collected in the 
> >> first place. 
> >> 
> >> "Programmers waste enormous amounts of time thinking about, or 
> >> worrying about, the speed of noncritical parts of their programs, 
> >> and these attempts at efficiency actually have a strong negative 
> >> impact when debugging and maintenance are considered. We should 
> >> forget about small efficiencies, say about 97% of the time: 
> >> premature optimization is the root of all evil. Yet we should not 
> >> pass up our opportunities in that critical 3%." -- Donald Knuth 
> > 
> > All very true, but I'm talking about chunks of code that have a hard 
> > deadline. If you measure it and it's close to the limit then you 
> > can't afford to have unspecified, unquantified, uncontrollable 
> > hiccups. This is especially so with write once, run everywhere, 
> > code. 
> > 
> > Of course, if hiccups are acceptable then it's not a problem, nor is 
> > that a reason for complaining about the language. 
> >
> My complaint is less about JavaScript, than the fashionable approach 
> that insists that just because they learnt it and CompSci school every 
> API must now consist of objects and classes - mostly ill thought out and 
> obscure - that defy clear documentation, and make the job of actually 
> using them almost impossible. 
> 
> Why does Jquery exist? To cover up the shit that is the underlying 
> horror of the DOM and the language implementations. 
> 
> 
> 
> > John 
> > 
> 
> 
> -- 
> Renewable energy: Expensive solutions that don't work to a problem that 
> doesn't exist instituted by self legalising protection rackets that 
> don't protect, masquerading as public servants who don't serve the public.
Try to be a bit philosophical about this it needs to be resolved.
Why is not the latency subtracted?
https://jonasth.github.io/

function STARTPLAY(){
if (keepGoing) {
setTimeout(STARTPLAY,copyEv[playPos]);
REALTIME=performance.now()-browserLoadTIME;
LATENCY=REALTIME-oldPassedTime;
oldPassedTime=schedTime;
schedTime=copyEv[playPos]+schedTime;
copyEv[playPos]=Math.max(0,copyEv[playPos]-LATENCY);
outportarr[outportindex].send(noteMessage[playPos]);
playPos++;
}
}

[toc] | [prev] | [next] | [standalone]

#39917

On Tuesday, April 13, 2021 at 7:19:50 AM UTC-5, jonas.t...@gmail.com wrote:
> Try to be a bit philosophical about this it needs to be resolved. 
> Why is not the latency subtracted? 
> https://jonasth.github.io/ 
> 
> function STARTPLAY(){ 
> if (keepGoing) { 
> setTimeout(STARTPLAY,copyEv[playPos]); 
> REALTIME=performance.now()-browserLoadTIME; 
> LATENCY=REALTIME-oldPassedTime; 
> oldPassedTime=schedTime; 
> schedTime=copyEv[playPos]+schedTime; 
> copyEv[playPos]=Math.max(0,copyEv[playPos]-LATENCY); 
> outportarr[outportindex].send(noteMessage[playPos]); 
> playPos++; 
> } 
> }

Paste the code in the following:

<https://www.jslint.com/>

Fix all of the errors.

Until you do, no one wants to look at it.

[toc] | [prev] | [next] | [standalone]

#39904

On 11/04/2021 15:03, John G Harris wrote:
> On Sun, 11 Apr 2021 11:33:04 +0100, The Natural Philosopher
> <tnp@invalid.invalid> wrote:
> 
>    <snip>
>> I have a ms or so to run a 256 cycle iteration with quite a lot of FP
>> potentially
>>
>> However my basic audio code seems stutter free on a crap mobile phone
>> running firefox, on android, so there is plenty of hope.
> 
> You're doing real time code in a web browser, using a language that
> assumes an autonomous garbage collector! You've picked the wrong tools
> to do the job. And next year a cart horse will win the Derby.
> 
>    John
> 
I don't think you know what you are saying. Browsers already do real 
time streaming audio. The audio worklet interface extends that..well in 
firefox it does. Chrome is broken. There is sufficient buffering 
provided to do quite a lot of processing - about 1 ms default.
As I said it works so far even on a cheap android phone


-- 
Truth welcomes investigation because truth knows investigation will lead 
to converts. It is deception that uses all the other techniques.

[toc] | [prev] | [next] | [standalone]

#39908

On Mon, 12 Apr 2021 01:36:51 +0100, The Natural Philosopher
<tnp@invalid.invalid> wrote:

>On 11/04/2021 15:03, John G Harris wrote:
>> On Sun, 11 Apr 2021 11:33:04 +0100, The Natural Philosopher
>> <tnp@invalid.invalid> wrote:
>> 
>>    <snip>
>>> I have a ms or so to run a 256 cycle iteration with quite a lot of FP
>>> potentially
>>>
>>> However my basic audio code seems stutter free on a crap mobile phone
>>> running firefox, on android, so there is plenty of hope.
>> 
>> You're doing real time code in a web browser, using a language that
>> assumes an autonomous garbage collector! You've picked the wrong tools
>> to do the job. And next year a cart horse will win the Derby.
>> 
>>    John
>> 
>I don't think you know what you are saying. Browsers already do real 
>time streaming audio. The audio worklet interface extends that..well in 
>firefox it does. Chrome is broken. There is sufficient buffering 
>provided to do quite a lot of processing - about 1 ms default.
>As I said it works so far even on a cheap android phone

So you are not complaining about the language after all. Pity you
didn't say that at the beginning.

  John

[toc] | [prev] | [next] | [standalone]

#39913

On 12/04/2021 18:04, John G Harris wrote:
> On Mon, 12 Apr 2021 01:36:51 +0100, The Natural Philosopher
> <tnp@invalid.invalid> wrote:
> 
>> On 11/04/2021 15:03, John G Harris wrote:
>>> On Sun, 11 Apr 2021 11:33:04 +0100, The Natural Philosopher
>>> <tnp@invalid.invalid> wrote:
>>>
>>>     <snip>
>>>> I have a ms or so to run a 256 cycle iteration with quite a lot of FP
>>>> potentially
>>>>
>>>> However my basic audio code seems stutter free on a crap mobile phone
>>>> running firefox, on android, so there is plenty of hope.
>>>
>>> You're doing real time code in a web browser, using a language that
>>> assumes an autonomous garbage collector! You've picked the wrong tools
>>> to do the job. And next year a cart horse will win the Derby.
>>>
>>>     John
>>>
>> I don't think you know what you are saying. Browsers already do real
>> time streaming audio. The audio worklet interface extends that..well in
>> firefox it does. Chrome is broken. There is sufficient buffering
>> provided to do quite a lot of processing - about 1 ms default.
>> As I said it works so far even on a cheap android phone
> 
> So you are not complaining about the language after all. Pity you
> didn't say that at the beginning.
> 
>    John
> 
I m notr complaining about the hardware. Or about the browser as an 
operating system The language - or at least the web APIS written in it, 
are utter shite.

Grace Hopper developed COBOL to make computers accessible to people who 
were not natural hardware boys. They were business analysts. Not coders.
Ever since, 'computer scientists', who are only one step above 
ArtStudents™ when it comes to being wankers of the first order, have 
been making up new languages that are so arcane that they simply 
*prevent* ordinary people trying to use a computer from solving a problem.

How many stock control systems are written in Prolog or Lisp?

After about three weeks, one browser  - and one only -  now works for me 
to start developing the code I wanted to develop.

That three weeks has been spent struggling with lack of documentation, 
examples that simply did not work that were copied one from another 
presumably without checking and layers of obfuscation created by what is 
simply fashion - making everything an object or a method, - that is 
arguably inappropriate for the task in hand. In short I am fighting the 
language - its is not helping me program, it is hindering me from 
programming.
It is just that in the applications I am building its marginally less 
worse than fighting that utter cunt Poettering and PulseAudio™, the 
project he abandoned half finished to wreck everyone's linux by 
inventing something no one wanted or needed - systemd.

"servers will boot faster with systemd"

The last thing I give a flying fuck about in a server is how fast it 
boots,. The aim or a server is to stay up for ten years at a time, and 
if I want it to boot fastger I'll put the OS on an SSD.


I'm too old to spend thousands of pounds on a course that would 
familiarize me with the exact syntax of 'constructors' and 'processors' 
or why you need to create and link 5 'objects' just to intercept an 
audio path, or why this must needs be done in background by an 
asynchronous task...and each one is quirky and requires different syntax 
depending on which browser one is using


JavǎScript, to misquote Tom Lehrer, is like a sewer. What you get out of 
it depends on what you put into it. It bears the stamp of CompSci all 
over it,. Designed to create a privileged class of gurus who understand 
the language, not competent journeyman programmers who can use it  to 
actually get a real world job done.

Bjarn Stroustrup admitted that half the point of C++ was to create more 
jobs for programmers....

Browsers, the DOM and JavaScript have been thrown together in a rush, 
and its is the exact opposite of - say  - php, which one guy designed to 
do a specific job, which it does pretty well - or did till it went 
object oriented.

Programmers today who have been On Courses and Passed Exams in stuff 
never stop to ask the question that some of us who grew up before 
computers existed, cant help but ask 'Is this actually better?'

Never mind a database, how many computerised systems that cost a fortune 
and dont work are better than say the old stock control system, where 
each part had the stock level on a card in a card index, and when the 
stock level got low you made a note on another card  of the part reorder 
level and put it in the pile of 'order some more'

And how much easer that is than catch( 
company.location[A].stockRoom.part[partno]=partsIssued.update.is 
negative)=>company.location.purchasing.part[partno]+=company.location.purchasing.part[partno].reorderLevel.
??

And even that is too esy. Let's construct a 'part deficit object'  that 
'extends class "profit"' and put it in the middle., just to show how 
fucking clever we are...and ensure that no one else will ever be able to 
maintain the code we wrote


-- 
A lie can travel halfway around the world while the truth is putting on 
its shoes.

[toc] | [prev] | [next] | [standalone]

#39924

On Mon, 12 Apr 2021 23:09:50 +0100, The Natural Philosopher
<tnp@invalid.invalid> wrote:

  <snip>
>I m notr complaining about the hardware. Or about the browser as an 
>operating system The language - or at least the web APIS written in it, 
>are utter shite.
>
>Grace Hopper developed COBOL to make computers accessible to people who 
>were not natural hardware boys. They were business analysts. Not coders.

  ADD A TO B GIVING C
The only good thing about COBOL is the data division. It allows you to
describe and operate on a competitor's data format.


>Ever since, 'computer scientists', who are only one step above 
>ArtStudents™ when it comes to being wankers of the first order, have 
>been making up new languages that are so arcane that they simply 
>*prevent* ordinary people trying to use a computer from solving a problem.

Why shouldn't they? They have as much right to invent languages as you
have.


>How many stock control systems are written in Prolog or Lisp?

Businesses don't have to buy and use languages that don't suit them.
Are you saying that Professor Spladinski can force General Motors to
use his super new Curly@ language?


>After about three weeks, one browser  - and one only -  now works for me 
>to start developing the code I wanted to develop.

Are you seeing the browser wars reappearing?


>That three weeks has been spent struggling with lack of documentation, 
>examples that simply did not work that were copied one from another 
>presumably without checking 

A lack of documentation means a commercial producer can't be sued for
things that aren't what's wanted. And writing tech lit in an open
source project is low status, boring, and often done by people with no
experience. You don't always get what you are not paying for.


>and layers of obfuscation created by what is 
>simply fashion - making everything an object or a method, - that is 
>arguably inappropriate for the task in hand. In short I am fighting the 
>language - its is not helping me program, it is hindering me from 
>programming.

You're looking for something different but the rotten world hasn't
done it yet. Get your finger out, world!


>It is just that in the applications I am building its marginally less 
>worse than fighting that utter cunt Poettering and PulseAudio™, the 
>project he abandoned half finished to wreck everyone's linux by 
>inventing something no one wanted or needed - systemd.
>
>"servers will boot faster with systemd"
>
>The last thing I give a flying fuck about in a server is how fast it 
>boots,. The aim or a server is to stay up for ten years at a time, and 
>if I want it to boot fastger I'll put the OS on an SSD.

Another product you don't like, and it doesn't use ECMAScript.


>I'm too old to spend thousands of pounds on a course that would 
>familiarize me with the exact syntax of 'constructors' and 'processors' 
>or why you need to create and link 5 'objects' just to intercept an 
>audio path, or why this must needs be done in background by an 
>asynchronous task

Were you never taught how to pick up a new technology on your own?


>...and each one is quirky and requires different syntax 
>depending on which browser one is using

Browser wars again. If it's a fact of life then you'll just have to
put up with it.


>Jav?Script, to misquote Tom Lehrer, is like a sewer. What you get out of 
>it depends on what you put into it. It bears the stamp of CompSci all 
>over it,. Designed to create a privileged class of gurus who understand 
>the language, not competent journeyman programmers who can use it  to 
>actually get a real world job done.

A language that could be designed and implemented in a couple of
weeks, then released to see if anyone was interested. They were. The
rest is history.

Then the browsers added more and more features, but competent
programmers don't have to use them.


>Bjarn Stroustrup admitted that half the point of C++ was to create more 
>jobs for programmers....

...who now had the tools to tackle even more systems that needed
doing. Discrete simulations; banking software; operating systems.
Things like that. Or maybe he was joking.


>Browsers, the DOM and JavaScript have been thrown together in a rush, 
>and its is the exact opposite of - say  - php, which one guy designed to 
>do a specific job, which it does pretty well - or did till it went 
>object oriented.

"JavaScript" was designed by one bloke and did its job pretty well.


>Programmers today who have been On Courses and Passed Exams in stuff 
>never stop to ask the question that some of us who grew up before 
>computers existed, cant help but ask 'Is this actually better?'
>
>Never mind a database, how many computerised systems that cost a fortune 
>and dont work are better than say the old stock control system, where 
>each part had the stock level on a card in a card index, and when the 
>stock level got low you made a note on another card  of the part reorder 
>level and put it in the pile of 'order some more'
>
>And how much easer that is than catch( 
>company.location[A].stockRoom.part[partno]=partsIssued.update.is 
>negative)=>company.location.purchasing.part[partno]+=company.location.purchasing.part[partno].reorderLevel.
>??

You'll never make CEO. Stock cards are processed by employees.
Employees cost money, and even more money to control them. A computer
sits in the basement and uses a predictable amount of electricity each
year. (Though some basements get flooded, which is inconvenient.)


>And even that is too esy. Let's construct a 'part deficit object'  that 
>'extends class "profit"' and put it in the middle., just to show how 
>fucking clever we are...and ensure that no one else will ever be able to 
>maintain the code we wrote

The company hires journeyman programmers who play games. Serves the
company right.

  John

[toc] | [prev] | [next] | [standalone]

#39925

On 13/04/2021 20:08, John G Harris wrote:
> You'll never make CEO. 

I was. Of two companies.



-- 
Ideas are more powerful than guns. We would not let our enemies have 
guns, why should we let them have ideas?

Josef Stalin

[toc] | [prev] | [next] | [standalone]

#39940

On Tue, 13 Apr 2021 21:41:20 +0100, The Natural Philosopher
<tnp@invalid.invalid> wrote:

>On 13/04/2021 20:08, John G Harris wrote:
>> You'll never make CEO. 
>
>I was. Of two companies.

Did your accounts departments use computers?

  John

[toc] | [prev] | [next] | [standalone]

#39890

Trying to optimize something ?





Kristjan

The Natural Philosopher kirjutas laupäev, 10. aprill 2021 kl 20:41:08 UTC+3:
> Does Js do it? 
> 
> I have some close to real time audio processing code and I want it to 
> run floating point on a raspberry Pi - no FP coprocessors so no wasted 
> cycles required. 
> 
> The question is - in C if you do something like 
> 
> function (int x) 
> for(somecondition) 
> if (x greater than whatever) 
> extra blah; 
> else completely different blah; 
> endfor 
> 
> will one hopes result in two completely different loops being 
> established so that conditionl is actually evaluated outside the loop - 
> i.e 
> 
> function (int x) 
> if (x greater than whatever) 
> for(somecondition) 
> extra blah; 
> endfor 
> else 
> for(somecondition) 
> completely different blah; 
> endfor 
> endif 
> 
> is what a decent compiler optimised for speed might well do. 
> 
> Does javascript though? 
> 
> And of course Javascript makes all numbers floating point...so the 
> comparison will be cycle hungry comparing two floats 
> 
> 
> -- 
> Of what good are dead warriors? … Warriors are those who desire battle 
> more than peace. Those who seek battle despite peace. Those who thump 
> their spears on the ground and talk of honor. Those who leap high the 
> battle dance and dream of glory … The good of dead warriors, Mother, is 
> that they are dead. 
> Sheri S Tepper: The Awakeners.

[toc] | [prev] | [next] | [standalone]

#39896

On 10/04/2021 21:36, Kristjan Robam wrote:
> Trying to optimize something ?
Sure.

Real time audio processing for ultimate use on a Pi running probably 
firefox.


> 
> 
> 
> 
> 
> Kristjan
> 
> The Natural Philosopher kirjutas laupäev, 10. aprill 2021 kl 20:41:08 UTC+3:
>> Does Js do it?
>>
>> I have some close to real time audio processing code and I want it to
>> run floating point on a raspberry Pi - no FP coprocessors so no wasted
>> cycles required.
>>
>> The question is - in C if you do something like
>>
>> function (int x)
>> for(somecondition)
>> if (x greater than whatever)
>> extra blah;
>> else completely different blah;
>> endfor
>>
>> will one hopes result in two completely different loops being
>> established so that conditionl is actually evaluated outside the loop -
>> i.e
>>
>> function (int x)
>> if (x greater than whatever)
>> for(somecondition)
>> extra blah;
>> endfor
>> else
>> for(somecondition)
>> completely different blah;
>> endfor
>> endif
>>
>> is what a decent compiler optimised for speed might well do.
>>
>> Does javascript though?
>>
>> And of course Javascript makes all numbers floating point...so the
>> comparison will be cycle hungry comparing two floats
>>
>>
>> -- 
>> Of what good are dead warriors? … Warriors are those who desire battle
>> more than peace. Those who seek battle despite peace. Those who thump
>> their spears on the ground and talk of honor. Those who leap high the
>> battle dance and dream of glory … The good of dead warriors, Mother, is
>> that they are dead.
>> Sheri S Tepper: The Awakeners.


-- 
Microsoft : the best reason to go to Linux that ever existed.

[toc] | [prev] | [next] | [standalone]

#39892

On Saturday, April 10, 2021 at 12:41:08 PM UTC-5, The Natural Philosopher wrote:
> Does Js do it? 
> 
> I have some close to real time audio processing code and I want it to 
> run floating point on a raspberry Pi - no FP coprocessors so no wasted 
> cycles required. 
> 
> The question is - in C if you do something like 
> 
> function (int x) 
> for(somecondition) 
> if (x greater than whatever) 
> extra blah; 
> else completely different blah; 
> endfor 
> 
> will one hopes result in two completely different loops being 
> established so that conditionl is actually evaluated outside the loop - 
> i.e 
> 
> function (int x) 
> if (x greater than whatever) 
> for(somecondition) 
> extra blah; 
> endfor 
> else 
> for(somecondition) 
> completely different blah; 
> endfor 
> endif 
> 
> is what a decent compiler optimised for speed might well do. 
> 
> Does javascript though? 

Modern JavaScript engines use JIT compilation. Depending on what you are doing it can be faster than the equivalent C code. A couple examples:

<https://www.reddit.com/r/javascript/comments/bnnrnt/javascript_faster_than_c_to_execute_mathematical/>
<https://gist.github.com/spion/3049314>

If you want more details on why that's the case here is one description among many:

<https://hacks.mozilla.org/2017/02/a-crash-course-in-just-in-time-jit-compilers/>

So you may think you're using floats, but in reality it may have converted those to int32 or smaller as well as inlined and compiled to machine code a significant portion of your script.

> And of course Javascript makes all numbers floating point...so the 
> comparison will be cycle hungry comparing two floats 

No, it doesn't. JavaScript has more than just floats and the JIT will find opportunities to utilize smaller number types behind the scenes where possible and appropriate.

[toc] | [prev] | [next] | [standalone]

#39897

On 11/04/2021 06:22, Michael Haufe (TNO) wrote:
> On Saturday, April 10, 2021 at 12:41:08 PM UTC-5, The Natural Philosopher wrote:
>> Does Js do it?
>>
>> I have some close to real time audio processing code and I want it to
>> run floating point on a raspberry Pi - no FP coprocessors so no wasted
>> cycles required.
>>
>> The question is - in C if you do something like
>>
>> function (int x)
>> for(somecondition)
>> if (x greater than whatever)
>> extra blah;
>> else completely different blah;
>> endfor
>>
>> will one hopes result in two completely different loops being
>> established so that conditionl is actually evaluated outside the loop -
>> i.e
>>
>> function (int x)
>> if (x greater than whatever)
>> for(somecondition)
>> extra blah;
>> endfor
>> else
>> for(somecondition)
>> completely different blah;
>> endfor
>> endif
>>
>> is what a decent compiler optimised for speed might well do.
>>
>> Does javascript though?
> 
> Modern JavaScript engines use JIT compilation. Depending on what you are doing it can be faster than the equivalent C code. A couple examples:
> 
> <https://www.reddit.com/r/javascript/comments/bnnrnt/javascript_faster_than_c_to_execute_mathematical/>
> <https://gist.github.com/spion/3049314>
> 
> If you want more details on why that's the case here is one description among many:
> 
> <https://hacks.mozilla.org/2017/02/a-crash-course-in-just-in-time-jit-compilers/>
> 
> So you may think you're using floats, but in reality it may have converted those to int32 or smaller as well as inlined and compiled to machine code a significant portion of your script.
> 
>> And of course Javascript makes all numbers floating point...so the
>> comparison will be cycle hungry comparing two floats
> 
> No, it doesn't. JavaScript has more than just floats and the JIT will find opportunities to utilize smaller number types behind the scenes where possible and appropriate.
> 

That is useful information, thanks.
It seems that 'test and try' is the optimal approach.

So far its no issues at all on Intel hardware as far as I have developed 
it, or android on an ARM ...


-- 
Microsoft : the best reason to go to Linux that ever existed.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web