Sure, they set the record of 4096 operating CPUs, but the Linux kernel (much like the BSD kernel) has had large locks and serialisation points spread throughout the kernel for a loong time. ISTR that SGI Altix doing a computational workload (little kernel mischief). They got the CPU representation (ie, not a 32 bit bitmask) right and the scheduler working. But I bet you couldn't do 4096 CPUs worth of parallel disk or network IO.
FreeBSD, like Linux, has been recently focusing on modern IO and CPU intensive workloads, rather than the Altix "Demo" from years gone by. So ignore the silly SGI Altix datapoint and look at what people are using it for now.
BSD architecture allows real time interrupts to kernel space. It's just that almost all the drivers these days use ISR threads that are woken up by an interrupt.
There's nothing stopping a carefully written driver doing everything in the ISR.
Really? cddl and gpl software have their own directories. You can build totally functional kernels, completely with the tools given to you by the build system, without:
* any binary blob drivers (and yes, ath(4) doesn't need a binary blob, so you can get wireless support!); * any GPL or CDDL code (so no ZFS and no ext2fs, for example.)
Please re-inform yourself of the reality of FreeBSD's distribution and structure before making such uninformed comments.
.. and you have to back it up... and you have to keep it powered... and you have to keep it cooled... and you have to keep it managed... and it takes up physical space.
There's a valid argument for what you're trying to say, but it's not "2gb flash drive for a dollar". You're missing the whole lifecycle of IT. Please address that?
Really? I have almost all of their PCI/PCIe 802.11n hardware working, stable and supporting 802.11na/802.11ng. I fixed AR9280 support, fixed AR9285 support and added AR9287 support. Once 802.11n support is in the tree I'll move to tidying up the DMA and interrupt path and introduce the changes needed for AR93xx and later series NICs. I have working bluetooth coexistence patches that I haven't yet setup a test bed to validate and I have things stable now on both SMP and UP machines.
The only thing I've broken is TDMA.
A lot of those commits are because I've been (a) fixing issues as they've come up, and (b) I like doing small commits that make it easier to bisect changes.
I think I've done a pretty good job. I'm glad to take constructive criticism. The PR system is ----> That way.:)
.. but the bureaucrat is better equipped to see the bigger picture. There may not be enough boots to go around, but hats may be needed at some point in the future, so why waste production capacity now.
"CHAIN" in BASIC dialects tended to be a "merge in the code into the running state." Ie, it wouldn't delete the current variable set.
It's how you got around RAM limitations - you broke your code up into separate source files, and just "swapped" in bits of BASIC code as you needed them.
Then there's "CHAIN MERGE" (at least on the Amstrad CPC), which merges in code into running state -and- code. So you could say reserve lines 10000-65500 for "chained" code, and just do this:
100 CHAIN MERGE "sub.bas", 10000, DELETE 10000-65000.. which IIRC would do this.
With javascript, plenty of web devs have gotten their boot in the door by looking at what others have done and learnt/ripped from that. If you've bought a web app from someone and it's a little broken, chances are you can fix the (php,python,perl,etc) source, along with the buggy javascript layers they're using to get the job done.
With something like NaCL, why ship the source code? You just ship the binary. Suddenly web development resembles desktop development.
.. err, I think you missed the point with vectorised instructions and interpreted languages.
If your interpreted language has no vector operations, then although your compiled binary interpreter can vectorise, the data operations being given to your interpreter is not vectorised. Think about it for a minute. Your interpreter is just doing while (read VM opcode) (call func[VM opcode]) ; the data isn't in a parallelable/vectorised form; nor will the CPU ever see it that way. The CPU just sees the VM opcode stream.
For JITs this is different. I haven't done much digging here, but again getting vectorised performance out of a JIT requires the underlying data be in the right format.
This is why out of order, parallel instruction execution is a lot "better" for random applications (including interpreters and JITs) - because you're parallelising the instructions themselves, rather than trying to operate on vectored data. Your VM environment and/or application likely doesn't give you the correctly formatted data set.
I tinkered with vectorised instructions in a FORTH style bytecode stream. Where you pass the data list to vectored instructions. This provided a huge speed benefit. Trouble was, it was FORTH.:)
You've fallen for the oldest fallacy in the book - "it's not logically possible, thus it's not possible."
Please read up about AM versus FM and what the "experts" were saying about how FM couldn't possibly work. What changed? Our understanding of communication and information theory.
It's possible some people are sensitive to EM; the fact we haven't established it doesn't at all rule it out as a possibility. It just means we haven't figured out how. What we can say right now is that there's no currently demonstrated link between "health issues" and "EMR". What good scientists should be doing (and are, if they can get funding) is research into why people suffer - looking not only for whether they are or not (ie, if there's a real link), but what other factors (eg psychological) come into play. But you have to be careful - you may end up drawing a conclusion that it's "all psychological" when in fact there may be a slim minority who can detect certain kinds of EM. They're just needles in the haystack of results.
The key thing here is that being right isn't "right". The key thing here is that people believe they're suffering from something, and they've externalised their cause to certain kinds of EMR. Whether they're sensitive or not isn't relevant - the fact they suffer from this is what is relevant. The thing to not do is call them crazy, or loopy, or label them in any way. The key thing to do is to not categorise them all the same.
But it does beg the question - once you've got a working design and engineering, operations, management, etc teams with lots of experience, does the total cost per mission drop when you start doing it in bulk?
Ie, once you've got a better idea of the mission lifespan, and yes assuming that the "getting it to mars" costs aren't coming down soon(ish), why not run 10 of them in parallel, on an "average" 5 year lifespan for each?
I'm sure there's something obvious missing from this, so someone please fill me in. Facts/figures please.
Find out how much of that money ends up in the state economy; find out how much is siphoned off elsewhere; find out how much gets avoided by tax dodges. Then tell the voter in California how much money could be being pumped into the economy if companies were paying company tax.
Slashdot Mirror
Sure, they set the record of 4096 operating CPUs, but the Linux kernel (much like the BSD kernel) has had large locks and serialisation points spread throughout the kernel for a loong time. ISTR that SGI Altix doing a computational workload (little kernel mischief). They got the CPU representation (ie, not a 32 bit bitmask) right and the scheduler working. But I bet you couldn't do 4096 CPUs worth of parallel disk or network IO.
FreeBSD, like Linux, has been recently focusing on modern IO and CPU intensive workloads, rather than the Altix "Demo" from years gone by. So ignore the silly SGI Altix datapoint and look at what people are using it for now.
(Yes, I'm a FreeBSD developer.)
No. memcmp() is designed to be used by sort functions. IIRC: It's supposed to return:
0: identical
+ve: string 2 > string 1
-ve: string 1 > string 2
'bool' doesn't cut it. But yes, their comparison was bogus.
BSD architecture allows real time interrupts to kernel space. It's just that almost all the drivers these days use ISR threads that are woken up by an interrupt.
There's nothing stopping a carefully written driver doing everything in the ISR.
Really? cddl and gpl software have their own directories. You can build totally functional kernels, completely with the tools given to you by the build system, without:
* any binary blob drivers (and yes, ath(4) doesn't need a binary blob, so you can get wireless support!);
* any GPL or CDDL code (so no ZFS and no ext2fs, for example.)
Please re-inform yourself of the reality of FreeBSD's distribution and structure before making such uninformed comments.
-adrian (@freebsd.org)
.. and you have to back it up. .. and you have to keep it powered. .. and you have to keep it cooled. .. and you have to keep it managed. .. and it takes up physical space.
There's a valid argument for what you're trying to say, but it's not "2gb flash drive for a dollar". You're missing the whole lifecycle of IT. Please address that?
http://www.schneier.com/blog/archives/2010/08/hacking_cars_th.html
Just saying.
Really? I have almost all of their PCI/PCIe 802.11n hardware working, stable and supporting 802.11na/802.11ng. I fixed AR9280 support, fixed AR9285 support and added AR9287 support. Once 802.11n support is in the tree I'll move to tidying up the DMA and interrupt path and introduce the changes needed for AR93xx and later series NICs. I have working bluetooth coexistence patches that I haven't yet setup a test bed to validate and I have things stable now on both SMP and UP machines.
The only thing I've broken is TDMA.
A lot of those commits are because I've been (a) fixing issues as they've come up, and (b) I like doing small commits that make it easier to bisect changes.
I think I've done a pretty good job. I'm glad to take constructive criticism. The PR system is ----> That way. :)
I'd like to hope we have more to say than what's on the slides.
.. but the bureaucrat is better equipped to see the bigger picture. There may not be enough boots to go around, but hats may be needed at some point in the future, so why waste production capacity now.
The fact that they don't is orthogonal to this.
.. why isn't this in wikipedia somewhere? Was this ever published?
.. except that relies on your database indexes, and woe be if you have a 1 million line file.
"CHAIN" in BASIC dialects tended to be a "merge in the code into the running state." Ie, it wouldn't delete the current variable set.
It's how you got around RAM limitations - you broke your code up into separate source files, and just "swapped" in bits of BASIC code as you needed them.
Then there's "CHAIN MERGE" (at least on the Amstrad CPC), which merges in code into running state -and- code. So you could say reserve lines 10000-65500 for "chained" code, and just do this:
100 CHAIN MERGE "sub.bas", 10000, DELETE 10000-65000 .. which IIRC would do this.
The wifi support is only as good as the money involved. :-)
Come to FreeBSD / PCBSD - and begin enjoying very fine wines / scotch. It's quite a nice place to be.
The crowd sources Jersey Shore, Do You Think You Can Dance and The Biggest Loser.
Please, try again.
Personally, I think that's a good sign that perhaps we've gone a little _too_ far and what we need are:
* better tools;
* better documentation;
* better frameworks;
* simpler systems.
Do you get access to the source?
With javascript, plenty of web devs have gotten their boot in the door by looking at what others have done and learnt/ripped from that. If you've bought a web app from someone and it's a little broken, chances are you can fix the (php,python,perl,etc) source, along with the buggy javascript layers they're using to get the job done.
With something like NaCL, why ship the source code? You just ship the binary. Suddenly web development resembles desktop development.
.. I should really get me one of these for FreeBSD 11n testing. :)
.. err, I think you missed the point with vectorised instructions and interpreted languages.
If your interpreted language has no vector operations, then although your compiled binary interpreter can vectorise, the data operations being given to your interpreter is not vectorised. Think about it for a minute. Your interpreter is just doing while (read VM opcode) (call func[VM opcode]) ; the data isn't in a parallelable/vectorised form; nor will the CPU ever see it that way. The CPU just sees the VM opcode stream.
For JITs this is different. I haven't done much digging here, but again getting vectorised performance out of a JIT requires the underlying data be in the right format.
This is why out of order, parallel instruction execution is a lot "better" for random applications (including interpreters and JITs) - because you're parallelising the instructions themselves, rather than trying to operate on vectored data. Your VM environment and/or application likely doesn't give you the correctly formatted data set.
I tinkered with vectorised instructions in a FORTH style bytecode stream. Where you pass the data list to vectored instructions. This provided a huge speed benefit. Trouble was, it was FORTH. :)
You've fallen for the oldest fallacy in the book - "it's not logically possible, thus it's not possible."
Please read up about AM versus FM and what the "experts" were saying about how FM couldn't possibly work. What changed? Our understanding of communication and information theory.
It's possible some people are sensitive to EM; the fact we haven't established it doesn't at all rule it out as a possibility. It just means we haven't figured out how. What we can say right now is that there's no currently demonstrated link between "health issues" and "EMR". What good scientists should be doing (and are, if they can get funding) is research into why people suffer - looking not only for whether they are or not (ie, if there's a real link), but what other factors (eg psychological) come into play. But you have to be careful - you may end up drawing a conclusion that it's "all psychological" when in fact there may be a slim minority who can detect certain kinds of EM. They're just needles in the haystack of results.
The key thing here is that being right isn't "right". The key thing here is that people believe they're suffering from something, and they've externalised their cause to certain kinds of EMR. Whether they're sensitive or not isn't relevant - the fact they suffer from this is what is relevant. The thing to not do is call them crazy, or loopy, or label them in any way. The key thing to do is to not categorise them all the same.
Blah, why'd I do that psych degree again..
Course, those with the allergies are dead at an early age; blamed on "poor health and nutrition".
Can't win, can't not play.
So start by putting them in trucks..
But it does beg the question - once you've got a working design and engineering, operations, management, etc teams with lots of experience, does the total cost per mission drop when you start doing it in bulk?
Ie, once you've got a better idea of the mission lifespan, and yes assuming that the "getting it to mars" costs aren't coming down soon(ish), why not run 10 of them in parallel, on an "average" 5 year lifespan for each?
I'm sure there's something obvious missing from this, so someone please fill me in. Facts/figures please.
Find out how much of that money ends up in the state economy; find out how much is siphoned off elsewhere; find out how much gets avoided by tax dodges. Then tell the voter in California how much money could be being pumped into the economy if companies were paying company tax.
Terry works at Apple.