of course you are right to a large degree. global memory bandwidth is the cause of the day and given coherency, its not trivial to architect around. the parent may have been a little terse, but as you point out, overall throughput doesn't go up if all the cores are too starved to issue.
however the memory latency picture isn't changing very much, and the most compelling method to hide it for general purpose machines is through thread parallelism (ignore vectors for a moment, its kind of a special case of the same thing).
this is what makes the multicore picture interesting. assuming a workload that can exploit it, you can really turn the scale knob pretty far up. unfortunately the whole affair pivots on being able to get past the crappy heavyweight thread-and-lock model the software people have grown so fond of. and the software community isn't particularily light on its feet.
do you think this is a UI related issue, or maybe that your company doesn't do a good job of balancing short term feature needs with long term product development goals?
how likely is it that someone in sales rammed these things through at the last minute in order to keep the customer beleiving that your company is paying attention to them and make his quota?
its likely that everyone in management thinks that the user interface is important, which is why they are paying your salary. but they just dont have it together enough to make sure that you have time to do your job, and that product developments are planned and executed correctly.
actually the inverse problem is much worse. if you need to change the work items, or the schedule, thats what you have technical managers for.
the best (worst) program managers gleefully tick off all their boxes when told, and are honestly suprised that 6 months after the scheduled date the project still isn't complete.
(i like osx, but as a desktop, with that out of the way)
he's right. with threads you now have to deal with the problems of mutating shared state. you also get some lovely resource mangement problems and a scheduling headache.
moreso, and this is what people dont seem to understand, is that you've factored your code implicitly based on the scheduling paradigm. somewhere someone is assuming things about what thread they are running in and in which ways they might be reentrant.
dealing with all this turns out to be hard. it has nothing to do with which generation you are from.
and what have you gained from all this? the ability to consider doing more than one thing at once in some time averaged way. thats great, but it turns out that there are easier ways.
threading is now a useful hardware concept (it was very frustrating when people insisted on eating threads just to run on a uniprocessor). but its still a lousy software concept.
messages are pretty good. software transactional memory is quite cute. continuations are a great tool for writing scheduling-independent code. if you have to suffer threads, then lock-free (misnomer) data structures can be helpful if you dont have hot spots.
(yes, i've worked on operating systems for machines with tens of thousands of hardware threads. have you?)
its pretty much a cluster. the seastar is a message passing engine. its distributed memory and the OS doesn't share any state (except for a library that does filesystem indirection)
if you make an mp3 player, you need to be able to write before you play.
now, with an actuarial model, we need to apply certain modifications to the input stream. how likely is it that the medium was left on the dash of a car in the hot sun and should be stretched.
how likely that your little sister was bouncing around and hit the player thus causing a permanent scratch. or maybe you were being a little too physical and careless yourself.
or some junkie broke into your car and took all the tapes to spread out on the sidewalk and try to sell to passers by
perhaps format x comes out and you need to repurchase all your old favorites
if the world moves beyond you and leaves you behind, the least you can demand is legislation to set things back all proper.
i actually talked to them about this work. apparently there are 150 seperate protocols including CIFS, and tens of thousands of pages of documentation, which are terribly inadequate given their culture. they were talking about a spec-writing team of 50 to do part of that work in a 6 month period of time. many of the other people involved were the engineers who did the original implementations and are now the only source of information.
they dug themselves a really really big hole. getting out is basically impossible.
there was actually a perfectly good answer to this proposed by deering. geographic addressing. it was unnecessarily denounced as anti-provider and socialist.
you don't. yes i know that bridging clock domains is a major source of instability and engineering headache, but independently clocked functional units and fine-grained async designs already exist, don't they?
i've taken a large linux driver and gotten it running in free with no source changes by defining the linux interfaces as macros and inlines. i think the only thing that didn't just fall out was the bit-sense of PAGE_MASK.
i don't see any reason why you couldn't do the same thing in the other direction.
why is cell phone internet access in the US so terribly useless. its not just the low bandwidth and the tiny screen, its because its packaged as a delivery media for ringtones and crappy games. not just as a pipe.
the value of the internet is that there isn't necessarily some marketing shmuck in tan slacks and a blue shirt sitting between me and what i want to do. its a free-for-all. if those people had been involved from the beginning it would have been worthless.
i know its somewhat offtopic, but the posters mention of 'fairness' really offended me.
education is not a sport. any way that people individually and collectively can understand more and be more creative is a win. the idiots who thought the grading system was the entire point drove me out of teaching university.
and if meth helps, great. although somehow i doubt that in the limit it does.
i think i may be getting a grasp on writing after 20 years. it is quite a bit like programming, there is nothing one can do but practice. write again and again, about everything. i read my first paper the other day and i was appalled. not just about the sentence structure, but the the presentation, the topic, and frankly everything.
the difference about writing is that there is no illusion of correctness based on execution. it is all very subjective. i hated to read my own writing when i was younger. it was embarassing.
engineers can learn to write. 20 papers, that they are forced to evaluate themselves for clarity of exposition. as many reviewers as can be marshalled. make them keep working on the same peice until they are well past the point of vomiting.
they are the same discipline. refactor, polish, test. rinse and repeat.
it is odd. i used to think this was an important area. however, now with everyone converging towards ansynchronous transaction packets spread over lvds pairs it just doesn't matter any more. peers even discover the best rate and width. you may as well run HT or PCI-E to the monitor at this point, anything else is just arbitrary market segmentation.
(it use to be that the rates required to draw a screen and the general purpose bus bandwisth were off by 3 magnitues...they are now on parity. machines have changed, people haven't very much)
don't worry, this will just be a temporary confusion. i'm sure congress will be happy to pass some very broad legislation, and the president will be very happy to sign it. problem solved.
Slashdot Mirror
of course you are right to a large degree. global memory bandwidth
is the cause of the day and given coherency, its not trivial to
architect around. the parent may have been a little terse, but
as you point out, overall throughput doesn't go up if all the
cores are too starved to issue.
however the memory latency picture isn't changing very much, and the
most compelling method to hide it for general purpose machines is through
thread parallelism (ignore vectors for a moment, its kind of a special
case of the same thing).
this is what makes the multicore picture interesting. assuming a workload
that can exploit it, you can really turn the scale knob pretty far up.
unfortunately the whole affair pivots on being able to get past the
crappy heavyweight thread-and-lock model the software people have grown
so fond of. and the software community isn't particularily light on its
feet.
do you think this is a UI related issue, or maybe that your company doesn't do a good job of balancing short term feature needs with long term product development goals?
how likely is it that someone in sales rammed these things through at the last minute in order to keep the customer beleiving that your company is paying attention to them and make his quota?
its likely that everyone in management thinks that the user interface is important, which is why they are paying your salary. but they just dont have it together enough to make sure that you have time to do your job, and that product developments are planned and executed correctly.
just guessing.
yes, filtering is technically correct. sampling is more
connotative. thanks for your insight.
ah, i see, by 'filtering' in this case you really mean 'sampling'
what do people use anisotropic filtering for? is that just
a funny way of saying arbitrary discretized kernel?
actually the inverse problem is much worse. if you need
to change the work items, or the schedule, thats what
you have technical managers for.
the best (worst) program managers gleefully tick off
all their boxes when told, and are honestly suprised that
6 months after the scheduled date the project still
isn't complete.
(i like osx, but as a desktop, with that out of the way)
he's right. with threads you now have to deal with the problems of mutating shared state. you also get some lovely resource mangement problems and a scheduling headache.
moreso, and this is what people dont seem to understand, is that you've factored your code implicitly based on the scheduling paradigm. somewhere someone is assuming things about what thread they are running in and in which ways they might be reentrant.
dealing with all this turns out to be hard. it has nothing to do with which generation you are from.
and what have you gained from all this? the ability to consider doing more than one thing at once in some time averaged way. thats great, but it turns out that there are easier ways.
threading is now a useful hardware concept (it was very frustrating when people insisted on eating threads just to run on a uniprocessor). but its still a lousy software concept.
messages are pretty good. software transactional memory is quite cute. continuations are a great tool for writing scheduling-independent code. if you have to suffer threads, then lock-free (misnomer) data structures can be helpful if you dont have hot spots.
(yes, i've worked on operating systems for machines with tens of thousands of hardware threads. have you?)
its pretty much a cluster. the seastar is a message
passing engine. its distributed memory and the OS
doesn't share any state (except for a library that
does filesystem indirection)
this isn't nearly creative enough.
if you make an mp3 player, you need to be able to write before
you play.
now, with an actuarial model, we need to apply certain modifications
to the input stream. how likely is it that the medium was left on the
dash of a car in the hot sun and should be stretched.
how likely that your little sister was bouncing around and hit the
player thus causing a permanent scratch. or maybe you were being
a little too physical and careless yourself.
or some junkie broke into your car and took all the tapes to spread
out on the sidewalk and try to sell to passers by
perhaps format x comes out and you need to repurchase all your old
favorites
if the world moves beyond you and leaves you behind, the least
you can demand is legislation to set things back all proper.
i actually talked to them about this work. apparently there are 150 seperate
protocols including CIFS, and tens of thousands of pages of documentation,
which are terribly inadequate given their culture. they were talking about
a spec-writing team of 50 to do part of that work in a 6 month period of
time. many of the other people involved were the engineers who did the
original implementations and are now the only source of information.
they dug themselves a really really big hole. getting out is basically
impossible.
there isn't any place for the truth then?
there was actually a perfectly good answer to this proposed by deering.
geographic addressing. it was unnecessarily denounced as anti-provider
and socialist.
you don't. yes i know that bridging clock domains is a major
source of instability and engineering headache, but independently
clocked functional units and fine-grained async designs already
exist, don't they?
the kind of company that would probably generate that much
traffic in the first place.
i've taken a large linux driver and gotten it running in free with no
source changes by defining the linux interfaces as macros and
inlines. i think the only thing that didn't just fall out was
the bit-sense of PAGE_MASK.
i don't see any reason why you couldn't do the same thing in the
other direction.
this is joke, right?
why is cell phone internet access in the US so terribly useless.
its not just the low bandwidth and the tiny screen, its because
its packaged as a delivery media for ringtones and crappy games.
not just as a pipe.
the value of the internet is that there isn't necessarily some
marketing shmuck in tan slacks and a blue shirt sitting between
me and what i want to do. its a free-for-all. if those people
had been involved from the beginning it would have been worthless.
do whatever you like. dont mess with my rfc 791.
i know its somewhat offtopic, but the posters mention of 'fairness' really offended me.
education is not a sport. any way that people individually and collectively can
understand more and be more creative is a win. the idiots who thought the grading
system was the entire point drove me out of teaching university.
and if meth helps, great. although somehow i doubt that in the limit it does.
is that why we did that? huh. must of just slipped my mind.
i'm sure that given this new income, the phone companies will lower
their rates and it will all balance out.
abstraction and state isolation considered harmful
i think i may be getting a grasp on writing after 20 years. it is quite a bit like programming, there is nothing one can do but practice. write again and again, about everything. i read my first paper the other day and i was appalled. not just about the sentence structure, but the the presentation, the topic, and frankly everything.
the difference about writing is that there is no illusion of correctness based on execution. it is all very subjective. i hated to read my own writing when i was younger. it was embarassing.
engineers can learn to write. 20 papers, that they are forced to evaluate themselves for clarity of exposition. as many reviewers as can be marshalled. make them keep working on the same peice until they are well past the point of vomiting.
they are the same discipline. refactor, polish, test. rinse and repeat.
it is odd. i used to think this was an important area. however, now with everyone converging towards ansynchronous transaction packets spread over lvds pairs it just doesn't matter any more. peers even discover the best rate and width. you may as well run HT or PCI-E to the monitor at this point, anything else is just arbitrary market segmentation.
(it use to be that the rates required to draw a screen and the general purpose bus bandwisth were off by 3 magnitues...they are now on parity. machines have changed, people haven't very much)
don't worry, this will just be a temporary confusion. i'm sure congress will be happy to pass some very broad legislation, and the president will be very happy to sign it. problem solved.
you're absolutely right. if you can't find it on el camino, it
obviously not anything anyone would want.