It's true the frame rate increases are marginal over typical refresh rates.
However, if you can render frames quicker, the CPU that would have been used for rendering (blocking on API calls / waiting for things to happen) can now be allocated to something else (AI / sound / loading).
Now it's possible you don't gain all of that since GPU offloading takes place, but any extra free CPU has to be good, right?
I've watched the slashdot audience change from dirty geeks looking for musical visualisation of sorting algorithms into "social media" pro piracy anarchists (yes, I know you call yourselves libertarian).
It used be that intelligent discussion was rewarded. Hell, even the trolls were better.
There's still the occasional nugget of old slashdot, but as another poster pointed out, we're not the demographic anymore.
Their problem was designing their architecture before they had put real constraints on performance (latency).
I can only assume that the designers weren't audio programmers, because the architecture is a mess. (So many layers of mixing, buffering)
Then on top of this messy architecture, you have the problem that none of your user applications run with a high enough priority to get CPU when they need so you get gaps in the playback for shorter latencies.
I mean, pulse audio beats it hands down..... On it's own platform.....
For the moment, I don't see this getting fixed to the levels of satisfaction you can run soft synths and various drum machines in real time.
Someone at google needs to stand up, take ownership of it and _rewrite the audio layer_ from the ground up (maybe start with pulse), and put sound modules _inside_ the realtime sound generation thread.
While I have the utmost respect for Alan this quote is unfortunate.
The "new world" is coming and it's massively multi-core. Now we can call it multi-process or call it multi-thread - we still need a consistent approach to parallel execution that guarantees consistency.
In the case of multi-process, using shared memory means we need a consistent memory model in exactly the same way as multi-threads (think two processes trying to update independantly two 8 bit values next to each other).
IIRC it's because without putting explicit constraints on the memory model (needed for threading), you end up with holes of varying sizes when talking to memory from threads.
It's mostly to do with CPU caching / memory barriers and having a consistent temporal view of data in and out.
If it's not in the language, you end up with each platform/compiler having their own approach to barriers / atomics which makes glueing different bits of code together with different approaches a crap shoot when it comes to consistency.
To each his own. I know I personally am more productive using the IDE and not doing the boring repetitive refactoring by hand (renaming files, recompile, oops, missed one).
I have my eclipse C++ environment setup so that on file save of the.cpp files, eclipse simply calls "make -j 3" and I get nice coloured syntax highlighted problems I can click on to get to the file.
I get all the goodness of clear, documented build (autotools), with the benefits of modern code refactoring and syntax/error highlighting.
Debugging shows similar gains.
Doing these things by hand in emacs (which I do still do for performance critical parts needing SSE) is much more time consuming.
(My main environment is Eclipse supplemented with emacs/gcc/autotools).
The thing with a pure editor / makefile / compiler environment is the lack of refactoring tools.
For example, with eclipse, I can rename a method / class or add parameters / remove them and the IDE with auto-update all classes I have opened in the workspace with the new signature / name.
Sure, it's dangerous, but isn't using sed/awk or perl to do the same thing equally dangerous (gotta write a regexp every time...).
Then there is also the gui for debugging. I can gdb session with the best of them, but remembering the various incantations to walk structures and examine memory is far more time consuming than a few clicky clicks.
These tools alone are worth it, not to mention not waiting for ctags to rebuild.
There's a big difference between what people tell pollsters because they think that's what they *should* say, verses what they actually do or believe
Even assuming what you say is true, it's still a pretty strong reflection on how screwed up your society is that people are coerced into espousing a particular worldview due to pressure.
A process can guarantee that it is allocated CPU time by using one of the kernel's real-time scheduling policies (SCHED_FIFO/SCHED_RR). These are scheduled independently and ahead of any non-realtime processes.
Aside: It isn't a guarantee, because other SCHED_RR/FIFO tasks of equal or higher priority can compete for that CPU.
If the system has been designed properly, it will mostly work fine without having to use the real time scheduler
For almost all cases where a realtime kernel is justified use of a non-realtime kernel is definitely not "mostly good enough".
Figures from Core2Quad, saturating background threads and IO with numCores latency testing threads (latency threads are set to SCHED_FIFO).
Kernel 3.014-rt31 - max scheduling wakeup latency of about.1 milliseconds Kernel 3.3.2 - max scheduling wakeup latency of up to 10 milliseconds, plus some wakeup deadlines missed
That may not be much to you, but that reliability can be the difference between pops and clicks in an audio stream.
Think contracts and what is broken when you don't have a contract whatsoever, just a promise.
To be correct, your experiment must complete erasure in both directions (0 to 1, 1 to 0).
As such, I think you'll find going the other direction is radically more difficult to get energy neutral since you'll be trying to keep thermal bleed from happening whilst flipping your bit.
It's a common misconception that the luddites were against modern technology - in fact, their campaign was about job protection.
They didn't ruin all of the texture factories - just ones where people were losing jobs as a protest against the loss of jobs - not against the (more) modern technology.
Slashdot Mirror
Thanks for writing this. Will use this at some point :-)
It's true the frame rate increases are marginal over typical refresh rates.
However, if you can render frames quicker, the CPU that would have been used for rendering (blocking on API calls / waiting for things to happen) can now be allocated to something else (AI / sound / loading).
Now it's possible you don't gain all of that since GPU offloading takes place, but any extra free CPU has to be good, right?
Cheers, I'll miss you too.
Unfortunately that's just how things go.
I've watched the slashdot audience change from dirty geeks looking for musical visualisation of sorting algorithms into "social media" pro piracy anarchists (yes, I know you call yourselves libertarian).
It used be that intelligent discussion was rewarded. Hell, even the trolls were better.
There's still the occasional nugget of old slashdot, but as another poster pointed out, we're not the demographic anymore.
D
TLDR: I miss my pages being WIDE
iracing does multiple distinct render windows into the world along with bevel compensation.
They probably have the best support out there for this kind of thing.
See this badass setup
Currently limited to 3, though.
Their problem was designing their architecture before they had put real constraints on performance (latency).
I can only assume that the designers weren't audio programmers, because the architecture is a mess. (So many layers of mixing, buffering)
Then on top of this messy architecture, you have the problem that none of your user applications run with a high enough priority to get CPU when they need so you get gaps in the playback for shorter latencies.
I mean, pulse audio beats it hands down..... On it's own platform.....
For the moment, I don't see this getting fixed to the levels of satisfaction you can run soft synths and various drum machines in real time.
Someone at google needs to stand up, take ownership of it and _rewrite the audio layer_ from the ground up (maybe start with pulse), and put sound modules _inside_ the realtime sound generation thread.
Tell you what google, hire me, and I'll do it.
While I have the utmost respect for Alan this quote is unfortunate.
The "new world" is coming and it's massively multi-core. Now we can call it multi-process or call it multi-thread - we still need a consistent approach to parallel execution that guarantees consistency.
In the case of multi-process, using shared memory means we need a consistent memory model in exactly the same way as multi-threads (think two processes trying to update independantly two 8 bit values next to each other).
IIRC it's because without putting explicit constraints on the memory model (needed for threading), you end up with holes of varying sizes when talking to memory from threads.
It's mostly to do with CPU caching / memory barriers and having a consistent temporal view of data in and out.
If it's not in the language, you end up with each platform/compiler having their own approach to barriers / atomics which makes glueing different bits of code together with different approaches a crap shoot when it comes to consistency.
Here's a good place to start
ACTA isn't quite dead yet, it's just "a little sick".
There's the up/down vote on it in the Parliament scheduled for the 6 July, but the recommendation from the international trade committee is "no".
http://www.europarl.europa.eu/news/en/pressroom/content/20120614IPR46889/html/Parliament-should-say-NO-to-ACTA-says-International-Trade-Committee
This may come as a bit of a surprise, but I think you're doing it wrong.
Nowadays there are many easy to install DVD or CD images you can burn that won't involve fecal matter or ejaculate in the slightest.
I'd also suggest diversifying your acquaintances a little, maybe mixing with some normal people.
Glad to see Linux has another devotee!
_Shrug_.
To each his own. I know I personally am more productive using the IDE and not doing the boring repetitive refactoring by hand (renaming files, recompile, oops, missed one).
I have my eclipse C++ environment setup so that on file save of the .cpp files, eclipse simply calls "make -j 3" and I get nice coloured syntax highlighted problems I can click on to get to the file.
I get all the goodness of clear, documented build (autotools), with the benefits of modern code refactoring and syntax/error highlighting.
Debugging shows similar gains.
Doing these things by hand in emacs (which I do still do for performance critical parts needing SSE) is much more time consuming.
Work smarter, not harder .-)
(My main environment is Eclipse supplemented with emacs/gcc/autotools).
The thing with a pure editor / makefile / compiler environment is the lack of refactoring tools.
For example, with eclipse, I can rename a method / class or add parameters / remove them and the IDE with auto-update all classes I have opened in the workspace with the new signature / name.
Sure, it's dangerous, but isn't using sed /awk or perl to do the same thing equally dangerous (gotta write a regexp every time...).
Then there is also the gui for debugging. I can gdb session with the best of them, but remembering the various incantations to walk structures and examine memory is far more time consuming than a few clicky clicks.
These tools alone are worth it, not to mention not waiting for ctags to rebuild.
Bravo Sir, Bravo.
I doff my hat in respect of your newfound awareness. Hold it dear and enjoy life for all it's good and bad songs.
There's hope for the rest of them yet.
You know, you could not watch it....
I don't get why it's so hard not to watch them.
Ah, so we should all be good little sheep and fit in with the pack - got you.
That sounds like a society to be proud of.
</sarcasm> for our U.S. viewers.
I'm sorry, yes, that _is_ screwed up. Advancement occurs through differing viewpoints, not through some boring grey parroting to "fit in".
Getting on with others != turning off your critical thinking skills and shouting "Me too!".
As if peer pressure is something new?
Murder isn't very new either.
I'm sorry, what was your point?
There's a big difference between what people tell pollsters because they think that's what they *should* say, verses what they actually do or believe
Even assuming what you say is true, it's still a pretty strong reflection on how screwed up your society is that people are coerced into espousing a particular worldview due to pressure.
Land of the free indeed.....
I vote for those adorable tiny monkeys!
Only problem is they'd waste that 200 mensa IQ on more accurate and long distance flinging poo devices.
A process can guarantee that it is allocated CPU time by using one of the kernel's real-time scheduling policies (SCHED_FIFO/SCHED_RR). These are scheduled independently and ahead of any non-realtime processes.
Aside: It isn't a guarantee, because other SCHED_RR/FIFO tasks of equal or higher priority can compete for that CPU.
If the system has been designed properly, it will mostly work fine without having to use the real time scheduler
For almost all cases where a realtime kernel is justified use of a non-realtime kernel is definitely not "mostly good enough".
Figures from Core2Quad, saturating background threads and IO with numCores latency testing threads (latency threads are set to SCHED_FIFO).
Kernel 3.014-rt31 - max scheduling wakeup latency of about .1 milliseconds
Kernel 3.3.2 - max scheduling wakeup latency of up to 10 milliseconds, plus some wakeup deadlines missed
That may not be much to you, but that reliability can be the difference between pops and clicks in an audio stream.
Think contracts and what is broken when you don't have a contract whatsoever, just a promise.
I heard you guys don't wear them on the toilet either.
Think of the children!
The real reason why Python will still be slower than Java is because it's a much more dynamic language.
Well, that and the fact you can't use more than one core profitably in python without going out to native code....
Python was actually originally conceived as a language to sit between a *ix shell, and C.
I think you got the asterisk in the wrong place, let me rewrite that for you:
Python was actually originally conceived as a language to s*it between a Unix shell, and C.
Which I confess, it does very well.
Your example only erases in one direction.
To be correct, your experiment must complete erasure in both directions (0 to 1, 1 to 0).
As such, I think you'll find going the other direction is radically more difficult to get energy neutral since you'll be trying to keep thermal bleed from happening whilst flipping your bit.
true democracy is two wolves and a sheep voting on what to have for dinner (usually attributed to Ben Franklin)
It's actually incorrectly attributed to Ben Franklin (see misattributed section).
Think about it - would one of the founders of arguably the most modern basis for democratic rule consider it rule by gunpoint / weight of numbers?
And yes, I've heard the usual "America isn't a Democracy, it's a Republic" etc - but a Republic and a Democracy are not othogonal concepts.
It's a common misconception that the luddites were against modern technology - in fact, their campaign was about job protection.
They didn't ruin all of the texture factories - just ones where people were losing jobs as a protest against the loss of jobs - not against the (more) modern technology.