doesn't mean it shouldn't be better, which, like it or not, is the subtext of your post. Maybe you don't personally mean that, but the folks opposing progress (billionaires. the ruling class, etc) do.
The folks opposing progress (ruling class) will do whatever they like and we cannot stop them because the ruling class has a vested and directed interest in ensuring that the 99% fight amongst themselves. It's why the ruling class is so heavily trying to push a gender war, or a race-war, or any sort of war for that matter, debunked myths be damned.
The people who run out and warrior their way through the world for whatever cause are the tools that the 1% use. With a (very) vocal minority aggressively fighting any form of egalitarianism or meritocracy they hope to keep the rest of the population's attention away from themselves.
Thus far it's working - this is by far and away the most sophisticated system of bread and circuses ever devised. Arguments about UBI is just another ring in this circus.
What it's doing is listening to audio signals above human hearing range (let's say 22khz) your ears can't hear it but your mic can. Signal360 plays a binary tone @ 22khz through the venue's audio system that the app picks up, decodes and does something like flashing your screen in sync with pregame videos or popping up a promotional offer.
Just how good is this mic? I only ask 'cos the microphones I've seen on cellphones battle to get anything above 5KHz, nevermind 22KHz...
Well, I tend to use an editor based diff, such as gvimdiff which of course respects my tab settings.
Sure it does, but that's only a single tool. Due to fuckery that came from before I was employed, I regularly do things like:
for X in `find . | grep -v \.svn | grep -i "\.[ch]$"`; do grep $SEARCHTERM $X; done
To make things manageable I usually use sed to replace all tabs in the utilities' output with a few spaces.
As for the other tools, sure you can only read 68-78 characters (that's awfully specific)
Well, that's because it's what humans read best at. It's why the default for LaTeX is what it is, and why newspapers are printed in columns, etc.
but the blank ones at the beginning have about as much effect on me as the potentially infinite number of blank characters at the end.
Anyway I do everything from xterm more or less and I still like tab=4
The xterm work is why I can't deal with tabs - a single line output from grep, diff, cut, etc overflow making it hard to visually match the thing you were looking for with the line it occurs on. A large number of tabs could place the search term, for example, three lines below the actual line it was found on. I don't read the output, I scan it.
It would be pretty easy to represent a parse tree as XML.
I'm not sure how old greybeard C programmers would feel about keeping source code in XML.
(actually I'm very sure, and I was tempted to post AC to avoid the pitchforks)
It's been done. That still didn't solve the problem of indentation and alignment:
(defunc f (n) ........(if (eq n 1) ............1 ............(* n (f (- n 1)))))
Use only tabs to indent to the beginning of the indent level. Use spaces for all other alignment,... the rest of us can view it as the gods decreed with tab=4.
And the very first time you ever try to read your own code in a diff, or a grep, or some other automated tool, your code is going to span much more than the comfortable 68-78 characters per line that humans read best at.
Unless you're very very new at this, you'll be reading code much more than you'll be writing it. When reading, you don't really have control over what the tools like grep and others will do.
But that's what I like about tabs. They can be set to display as however many columns each individual wants, rather than requiring everyone to agree on the same number. 4? 3? 8? Pi?
Only for indentation, not for alignment. If you care about writing readable code you'll use spaces.
We never got an e39 535i so I never knew they existed:-) We had the 540i e39, and I guess the market wasn't big enough for both the cars (they must have been very close in characteristics).
The m30 engines were actually quite great. Super smooth revver all the way up to redline. The one I drove for a few months was a much better driver than the 540i it was replaced with. I'd love to buy a new car with those engines.
Finally, what a coincidence - I had an '86 e28 with the 2.7l engine (m20). Very nice torque curve and very low revver. Called the Eta engine, if I recall correctly.
Anyone who knows C should be able to rattle off some problems.
[long list of problems]
You left out "Took the 'const' keyword from C++ and then proceeded to break it." Another niggle of mine with latest standard - stuff that is optional in a compliant compiler.
The 535i e28/e34 never had a V8. Was a silky smooth 3.5l straight 6. The e34 530i was a 3l V8, the generation after had a 530i which was a 3l straight 6.
That is why you design multithreaded programs to avoid bottlenecks. A fair number of applications scale just fine to many hundreds of CPUs.
But yes, if you just aimlessly hack a single-threaded design to use random synchronization primitives, you will lose.
Did you even read anything I wrote? Please tell me - exactly what multi-thread design do you know off that can solve the contention for the 48-53 pieces of copper that goes to the RAM? There's only one memory bus, and every instruction that must be executed travels on it before execution.
On a 8-core machine, a processor will be placed into a wait queue roughly 7 out of 8 times that it needs access. Further, The expected length of time in the queue is (1-(1/8)). This is of course, for an 8-core system. Adding more cores results in the waiting time increasing asymptotically towards infinity.
Sorry, that doesn't sound right. The expected length of time in the queue should be on the order of nt, where n is the number of cores and t is the average time required to process a memory-request. (A better formula would use the average length of the queue instead of n but to first order it still would be roughly linear with n.) So, the time required would increase linearly with the number of cores.
You're right, I worded it incorrectly (it's late, and I've been working 80hrs/week for the last year due to a private project. Forgive me). What I meant to say was "The expected delay when accessing memory is (1-(1/n))", but even that is off by an entire exponent.
The expected delay is (probability of queueing) X ( probable length queue). The probability of queuing is (1-(1/n)):
With 2 processors, you have a 1/2 chance of getting exclusive access, (1-(1/2)) of queuing.
With 3 processors, you have a 1/3 chance of getting exclusive access, (1-(1/3)) of queuing.
With 4 processors, you have a 1/4 chance of getting exclusive access, (1-(1/4)) of queuing.
With n processors, you have a 1/n chance of getting exclusive access, (1-(1/n)) of queuing.
The probable length of the queue is linearly proportional to n, so the expected delay is (1-(1/n) * n). In terms of performance this is O(n^2) - IOW it's piss-poor performance.
Or maybe I'm still doing the numbers wrong - feel free to derive a better statistic for predicting time-in-queue when processors are all using a single address bus. This is the one I got, and some trivial simulation does actually fit this profile.
With a multiuser, multitasking OS you can have 25 different unrelated processes running on something with 25 cores. Or you could have 25 threads in a dataflow arrangement where each is a consumer of what the last just produced. Or you could go over the members of an array or matrix 25 members at a time with the same transformation. Some things are serial, but there are plenty of ways more cores can actually be used.
Nope. You'll generally hit the wall with around 16-20 cores using shared memory. You need distinct processors with dedicated memory to make multi-processing scale beyond 20 or so processors. Those huge servers with 32-cores apiece have their point of dminishing returns/processor after around 20 cores.
First, the reason you aren't going to be doing multithreading/shared-memory on any known computer architectures, read this.
Secondly, let's say you aren't multithreading so you don't run into the problems in the link I posted above. Let's assume you run 25 separate tasks. You still run into the same problem, but at a lower level. The shared-memory is the throttle, because the memory only has a single bus. So you have 1000 cores. Each time an instruction has to be fetched[1] for one of those processors it needs exclusive access to those address lines that go to the memory. The odds of a core getting access to memory is roughly 1/n (n=number of cores/processors).
On a 8-core machine, a processor will be placed into a wait queue roughly 7 out of 8 times that it needs access. Further, The expected length of time in the queue is (1-(1/8)). This is of course, for an 8-core system. Adding more cores results in the waiting time increasing asymptotically towards infinity.
So, no. More cores sharing the same memory is not the answer. More cores with private memory is the answer but we don't have any operating system that can actually take advantage of that.
A project that I am eyeing for next year is putting together a system that can effectively spread out the operating system over multiple physical memorys. While I do not think that this is feasible, it's actually not a bad hobby to tinker with:-)
[1] Even though they'd be fetched in blocks, they still need to be fetched; a single incorrect speculative path will invalidate the entire cache.
"Not now" may mean hundreds of years in the future too. The current state of AI is very far off to do what an average drive has to do. It's more likely that we change roads than the AI catching up (ie, sends out electronic signals that the auto can read).
Certainly - and we can even include a mechanical interlock device so that the car can cannot physically deviate from a lane even if it wanted to. Intersections could be implemented via signalling so that cars will not t-bone each other.
In fact, to make thing efficient, the cars can even narrow the following distance to something lower than the reaction time of humans - say... a metre or so? Actually, just do away with the following distance and have the cars attached to each other. If the linked-cars leave at pre-determined times and arrive at pre-determined times at central locations, that will enable more people to use these self-driving cars.
Good catch - there were presumably a few win9x boxes that made it past the magic time:-) My experience of WinME involved lots of swearing, so yeah, that sounds totally plausible:-)
You keep saying that as if you know better, but they keep calling it a *limited* production car.
A limited production car is a subset of all production cars. As far as classification goes, the term "production car" comes from the rules for various group autoracing - see this for overview - and each group has different rules for allowing cars. Some need production cars with at least 2500 produced per year while others allowed a mere 200/year production run[1].
The classification "production car" for all groups means "a car produced for sale to the public". No more, no less. Even a handcrafted Bentley is considered a production car.
[1] Thus resulting in such rare beauties like the Ferrari 288GTO.
That can't be true - Win95 had a timer bug that locked up the machine if you ran it more than X days
No you remember wrong (or this was fixed by the Release B version in Europe). Win98 however could not survive many days without rebooting.
My memory isn't *all* bad:-) I was referring to this bug, which was only fixed for both Win95 and Win98 in 1999: Microsoft patch from 1999, thus Win95, in 1999, could not run for more than 49.7 days.
Nice informative comment. The mechanism the gun uses is easy enough to fool, though - I used to point the gun at a lightbulb and got every single duck, every single time:-)
Reminds me off a guy that our support staff had to help over the phone on my first workplace. It took them a while to realise that his definition of stopping and starting the computer was powering the screen on and off:)
Or that Windows 95 user who had never turned his computer off since the day he got it, he was utterly impressed that all kinds of stuff began to work after our support staff rebooted it for him...
That can't be true - Win95 had a timer bug that locked up the machine if you ran it more than X days (where X is anything from 16-30 - I don't remember the exact number). Your Win95 user used the computer for less than X days? How new was he?:-)
Don't be silly! Everyone knows that men and women are exactly the same, it's only the environment and society that thinks there's a difference. This study is obviously flawed and should be repeated until the correct result is achieved.
Slashdot Mirror
doesn't mean it shouldn't be better, which, like it or not, is the subtext of your post. Maybe you don't personally mean that, but the folks opposing progress (billionaires. the ruling class, etc) do.
The folks opposing progress (ruling class) will do whatever they like and we cannot stop them because the ruling class has a vested and directed interest in ensuring that the 99% fight amongst themselves. It's why the ruling class is so heavily trying to push a gender war, or a race-war, or any sort of war for that matter, debunked myths be damned.
The people who run out and warrior their way through the world for whatever cause are the tools that the 1% use. With a (very) vocal minority aggressively fighting any form of egalitarianism or meritocracy they hope to keep the rest of the population's attention away from themselves.
Thus far it's working - this is by far and away the most sophisticated system of bread and circuses ever devised. Arguments about UBI is just another ring in this circus.
What it's doing is listening to audio signals above human hearing range (let's say 22khz) your ears can't hear it but your mic can. Signal360 plays a binary tone @ 22khz through the venue's audio system that the app picks up, decodes and does something like flashing your screen in sync with pregame videos or popping up a promotional offer.
Just how good is this mic? I only ask 'cos the microphones I've seen on cellphones battle to get anything above 5KHz, nevermind 22KHz...
Failure is a part of success
Sure, but failure is also a part of failure. Failure leading to success is much, much rarer than failure leading to failure.
Well, I tend to use an editor based diff, such as gvimdiff which of course respects my tab settings.
Sure it does, but that's only a single tool. Due to fuckery that came from before I was employed, I regularly do things like:
To make things manageable I usually use sed to replace all tabs in the utilities' output with a few spaces.
As for the other tools, sure you can only read 68-78 characters (that's awfully specific)
Well, that's because it's what humans read best at. It's why the default for LaTeX is what it is, and why newspapers are printed in columns, etc.
but the blank ones at the beginning have about as much effect on me as the potentially infinite number of blank characters at the end.
Anyway I do everything from xterm more or less and I still like tab=4
The xterm work is why I can't deal with tabs - a single line output from grep, diff, cut, etc overflow making it hard to visually match the thing you were looking for with the line it occurs on. A large number of tabs could place the search term, for example, three lines below the actual line it was found on. I don't read the output, I scan it.
It would be pretty easy to represent a parse tree as XML. I'm not sure how old greybeard C programmers would feel about keeping source code in XML. (actually I'm very sure, and I was tempted to post AC to avoid the pitchforks)
It's been done. That still didn't solve the problem of indentation and alignment:
Use only tabs to indent to the beginning of the indent level. Use spaces for all other alignment,... the rest of us can view it as the gods decreed with tab=4.
And the very first time you ever try to read your own code in a diff, or a grep, or some other automated tool, your code is going to span much more than the comfortable 68-78 characters per line that humans read best at.
Unless you're very very new at this, you'll be reading code much more than you'll be writing it. When reading, you don't really have control over what the tools like grep and others will do.
But that's what I like about tabs. They can be set to display as however many columns each individual wants, rather than requiring everyone to agree on the same number. 4? 3? 8? Pi?
Only for indentation, not for alignment. If you care about writing readable code you'll use spaces.
If god wanted us to use spaces for indentation he wouldn't have made keyboards with tab keys.
TABS!
Here, use an editor that handles both at the same time, in the same file, without confusing the reader:
:set listchars=tab:\ ,trail:
Noobs :-)
That's when it's time to run the code through a formatter an check it in again.
Not if you're programming in Python. In a real language you have the option of the computer doing the formatting work ;-)
(If you don't find that funny, you're probably a Python-only programmer)
The laws governing something are completed before we've even managed to invent it.
We never got an e39 535i so I never knew they existed :-) We had the 540i e39, and I guess the market wasn't big enough for both the cars (they must have been very close in characteristics).
The m30 engines were actually quite great. Super smooth revver all the way up to redline. The one I drove for a few months was a much better driver than the 540i it was replaced with. I'd love to buy a new car with those engines.
Finally, what a coincidence - I had an '86 e28 with the 2.7l engine (m20). Very nice torque curve and very low revver. Called the Eta engine, if I recall correctly.
Anyone who knows C should be able to rattle off some problems.
[long list of problems]
You left out "Took the 'const' keyword from C++ and then proceeded to break it." Another niggle of mine with latest standard - stuff that is optional in a compliant compiler.
The 535i e28/e34 never had a V8. Was a silky smooth 3.5l straight 6. The e34 530i was a 3l V8, the generation after had a 530i which was a 3l straight 6.
Reactos is more important than many may think. If it ever gains proper compatibilty with Windows seven MS can kiss their dominance goodbye.
As we've seen with DOSBox, the ability to run existing games may make many gamers simply decide not to go to win10 and beyond.
While the ReactOS people need more hands, they also need the GPU manufacturers to test the drivers under ReactOS.
Does anybody know if ReactOS can run the exiting Win7 GPU drivers?
That is why you design multithreaded programs to avoid bottlenecks. A fair number of applications scale just fine to many hundreds of CPUs.
But yes, if you just aimlessly hack a single-threaded design to use random synchronization primitives, you will lose.
Did you even read anything I wrote? Please tell me - exactly what multi-thread design do you know off that can solve the contention for the 48-53 pieces of copper that goes to the RAM? There's only one memory bus, and every instruction that must be executed travels on it before execution.
On a 8-core machine, a processor will be placed into a wait queue roughly 7 out of 8 times that it needs access. Further, The expected length of time in the queue is (1-(1/8)). This is of course, for an 8-core system. Adding more cores results in the waiting time increasing asymptotically towards infinity.
Sorry, that doesn't sound right. The expected length of time in the queue should be on the order of nt, where n is the number of cores and t is the average time required to process a memory-request. (A better formula would use the average length of the queue instead of n but to first order it still would be roughly linear with n.) So, the time required would increase linearly with the number of cores.
You're right, I worded it incorrectly (it's late, and I've been working 80hrs/week for the last year due to a private project. Forgive me). What I meant to say was "The expected delay when accessing memory is (1-(1/n))", but even that is off by an entire exponent.
The expected delay is (probability of queueing) X ( probable length queue). The probability of queuing is (1-(1/n)):
With 2 processors, you have a 1/2 chance of getting exclusive access, (1-(1/2)) of queuing.
With 3 processors, you have a 1/3 chance of getting exclusive access, (1-(1/3)) of queuing.
With 4 processors, you have a 1/4 chance of getting exclusive access, (1-(1/4)) of queuing.
With n processors, you have a 1/n chance of getting exclusive access, (1-(1/n)) of queuing.
The probable length of the queue is linearly proportional to n, so the expected delay is (1-(1/n) * n). In terms of performance this is O(n^2) - IOW it's piss-poor performance.
Or maybe I'm still doing the numbers wrong - feel free to derive a better statistic for predicting time-in-queue when processors are all using a single address bus. This is the one I got, and some trivial simulation does actually fit this profile.
With a multiuser, multitasking OS you can have 25 different unrelated processes running on something with 25 cores. Or you could have 25 threads in a dataflow arrangement where each is a consumer of what the last just produced. Or you could go over the members of an array or matrix 25 members at a time with the same transformation. Some things are serial, but there are plenty of ways more cores can actually be used.
Nope. You'll generally hit the wall with around 16-20 cores using shared memory. You need distinct processors with dedicated memory to make multi-processing scale beyond 20 or so processors. Those huge servers with 32-cores apiece have their point of dminishing returns/processor after around 20 cores.
First, the reason you aren't going to be doing multithreading/shared-memory on any known computer architectures, read this.
Secondly, let's say you aren't multithreading so you don't run into the problems in the link I posted above. Let's assume you run 25 separate tasks. You still run into the same problem, but at a lower level. The shared-memory is the throttle, because the memory only has a single bus. So you have 1000 cores. Each time an instruction has to be fetched[1] for one of those processors it needs exclusive access to those address lines that go to the memory. The odds of a core getting access to memory is roughly 1/n (n=number of cores/processors).
On a 8-core machine, a processor will be placed into a wait queue roughly 7 out of 8 times that it needs access. Further, The expected length of time in the queue is (1-(1/8)). This is of course, for an 8-core system. Adding more cores results in the waiting time increasing asymptotically towards infinity.
So, no. More cores sharing the same memory is not the answer. More cores with private memory is the answer but we don't have any operating system that can actually take advantage of that.
A project that I am eyeing for next year is putting together a system that can effectively spread out the operating system over multiple physical memorys. While I do not think that this is feasible, it's actually not a bad hobby to tinker with :-)
[1] Even though they'd be fetched in blocks, they still need to be fetched; a single incorrect speculative path will invalidate the entire cache.
"But at least this new automated-lawsuit system will keep a lot of lawyers employed."
Me, I would rathe see lawyers unemployed. We could use them as compost or for ginning cotton ("...Premium organic hand-ginned cotton...".
My ex-wife is a lawyer. You are significantly overestimating her utility as an unemployed lawyer.
"Not now" may mean hundreds of years in the future too. The current state of AI is very far off to do what an average drive has to do. It's more likely that we change roads than the AI catching up (ie, sends out electronic signals that the auto can read).
Certainly - and we can even include a mechanical interlock device so that the car can cannot physically deviate from a lane even if it wanted to. Intersections could be implemented via signalling so that cars will not t-bone each other.
In fact, to make thing efficient, the cars can even narrow the following distance to something lower than the reaction time of humans - say... a metre or so? Actually, just do away with the following distance and have the cars attached to each other. If the linked-cars leave at pre-determined times and arrive at pre-determined times at central locations, that will enable more people to use these self-driving cars.
Gotta go now - late for my train.
Good catch - there were presumably a few win9x boxes that made it past the magic time :-) My experience of WinME involved lots of swearing, so yeah, that sounds totally plausible :-)
You keep saying that as if you know better, but they keep calling it a *limited* production car.
A limited production car is a subset of all production cars. As far as classification goes, the term "production car" comes from the rules for various group autoracing - see this for overview - and each group has different rules for allowing cars. Some need production cars with at least 2500 produced per year while others allowed a mere 200/year production run[1].
The classification "production car" for all groups means "a car produced for sale to the public". No more, no less. Even a handcrafted Bentley is considered a production car.
[1] Thus resulting in such rare beauties like the Ferrari 288GTO.
That can't be true - Win95 had a timer bug that locked up the machine if you ran it more than X days
No you remember wrong (or this was fixed by the Release B version in Europe). Win98 however could not survive many days without rebooting.
My memory isn't *all* bad :-) I was referring to this bug, which was only fixed for both Win95 and Win98 in 1999: Microsoft patch from 1999, thus Win95, in 1999, could not run for more than 49.7 days.
Nice informative comment. The mechanism the gun uses is easy enough to fool, though - I used to point the gun at a lightbulb and got every single duck, every single time :-)
Reminds me off a guy that our support staff had to help over the phone on my first workplace. It took them a while to realise that his definition of stopping and starting the computer was powering the screen on and off :)
Or that Windows 95 user who had never turned his computer off since the day he got it, he was utterly impressed that all kinds of stuff began to work after our support staff rebooted it for him...
That can't be true - Win95 had a timer bug that locked up the machine if you ran it more than X days (where X is anything from 16-30 - I don't remember the exact number). Your Win95 user used the computer for less than X days? How new was he? :-)
Even marijuana is sexist!!!
Don't be silly! Everyone knows that men and women are exactly the same, it's only the environment and society that thinks there's a difference. This study is obviously flawed and should be repeated until the correct result is achieved.
</sarcasm>