Whenever you post in a public forum, your post is judged by all who read it, even if the judgment is fairly superficial, such as "reading this post (was|was not) worth my time." Of course, judging the relevance and worth of a post is somewhat different than judging the person that's posting.
The point-pool idea doesn't create a currency in the typical sense, since posters cannot exchange this currency directly. The closest thing to such an exchange is the fact that moderation actions on a post will affect someone's pool. I, as a poster, would not be able to exchange points for favors, etc. with other people. And with moderators turning over every few days, it'd be very hard to make a black-market in moderation points.
Given that all of the "currency" comes from and is ultimately controlled by the moderators, and given that the moderators come from a large subset of the posting population, this sounds alot more like a meritocracy with a touch of democratic socialism than the "invisible groping hand" of capitalism.
First, before everyone jumps in and says "Intel will never get there because the compiler will never get there," please don't forget that some shipping devices are already there.
Quite simply, EPIC allows a compiler to tell the hardware ahead of time where it knows parallelism exists, so that the silicon (which is finite) doesn't have to hunt for it. Compared to the rate at which silicon must make scheduling decisions (at 800MHz, that's 1.25 nanoseconds), compiler time seems infinite.
Granted, compiler time is not infinite, but for performance-critical applications, it is quite large. The Texas Instruments TMS320C6000-family of DSPs, for instance, rely on compilers and assembly optimizers in order to eek out that last bit of performance, and as any DSP engineer will likely tell you, its usually worth it. Cycles saved in one loop are cycles that can be spent elsewhere on value-added features, leading to a more valuable product.
This points to the real fundamental problem as I see it, which is that the current VLIW darling in the industry is in the embedded world. Why should that make a difference, you ask? Because the embedded developer is the one most likely to take advantage of the raw capability that an exposed parallelism architecture can provide.
Merced's biggest problem lying ahead is the fact that workstation-class code does not naturally exhibit large amounts of parallelism. While I was attending MICRO-31, I heard someone remark about how most code looks like a series of 5-10 instruction bursts followed by a jump. ICK!!
Embedded programmers generally seem willing to learn whatever it takes to get their product running in the fewest MIPS (so that they can either use cheaper parts or provide more features), and so are often willing to jump through a few hoops to help out the compiler in order to get the parallelism they desire.
Workstation programmers, on the other hand, are interested in the much bigger picture (since their applications are much larger and tend to have larger life expectancies), and so code tends to be human-friendly and not compiler friendly. (Certain heavily-traveled code paths in the Linux kernel being a noteworthy exception.)
The point is that the Merced compiler will ship with alot of amazing compiler transformations, but very few of them will be effective at translating the hopping, skipping, and jumping nature of your typical general-purpose database-ish looking code into highly parallel performance-oozing EPIC instructions, at least straight out of the gate.
Merced will inherently provide big performance wins to the compute-farm customers (your big engineering shops that currently use networks full of Sun or HP workstations to crunch VHDL, Spice, or whatever simulations around the clock), as these applications end up reducing to huge matrix manipulations and numeric crunching galore -- oozing with parallelism. But Merced will be hard pressed to feed up web pages or database queries much faster than any other architecture, unless it's able to massively crank its clock rate due to losing the shackles of the instruction scheduling hardware.
Anyway, those compiler nuts in the crowd might find the following links useful and informative.
VLIW Architectures -- a description of VLIW that's part of a larger presentation about VLIW compiler techniques.
The Trimaran Research Compiler -- HP's research compiler that was supposedly used in development of the architecture that begat Merced.
EE Times -- article which describes the release of Trimaran and includes a diagram showing the relationship of architectures from Superscalar to VLIW/EPIC to TTA.
--Joe
--
EPIC has nothing to do with threaded arch's.
on
Troubles with Merced
·
· Score: 1
EPIC is not a multithreaded architecture. EPIC (which, as everyone knows, stands for Explicitly Parallel Instruction Computing) focuses on Instruction Level Parallelism (known in hardware and compiler circles as ILP for short).
Explicit ILP architectures, such as Very Long Instruction Word (VLIW) architectures, Transport Triggered Architectures (TTA) and the like all focus on finding parallelism within a given single-threaded program. The compiler for such an architecture may divide separate paths of execution into a sort-of thread (for instance, it might execute down the "then" and "else" clauses of an "if" before it knows which it nees, or perhaps down multiple "cases" of a "switch"), but this is not multi-threading in the common, macro sense of the term.
Multithreaded architectures, on the other hand, do focus on running multiple independent threads of execution, typically as if they were multiprocessors. For these CPUs, a given application needs to be constructed as a series of explicit threads (at the process level, not the instruction level), or a compiler needs to simulate this division. Alternately, a number of independent processes need to be available (although since all threads share a common pipeline, running independent processes together can have bad cache effects and cumulative stall effects that generally don't make anyone's day).
It's not service when you're always recompiling...
on
Linux 2.2.5 Released
·
· Score: 1
That's not unsettling, that's service.:)
Usually, I like to see a bit more delay between non-development releases. For instance, my fiancee can't be talked into more than about one kernel compile a month.
I kinda liked the long delays between 2.2.1 and 2.2.2. I'm sure people running production servers also appreciate the stability. Things seem to be accelerating again, but I'm hoping that's just due to the relative timing of vacations....
Was there some sort of brown-paper-bag issue in 2.2.4? I know Linus was about to go on a two-week vacation, so did he release this to fix some real showstoppers?
When I checked LinuxHQ, I didn't even see 2.2.5 mentioned yet, and the changelog at Cutting Edge Linux didn't hint at any real showstoppers. Even Alan Cox's diary didn't mention that 2.2.5 was iminent. A search of the Linux Kernel mailing list archives was similarly unenlightening. (I was looking at http://www.tux.org/hypermail/linux-kernel/latest/... is there a better place?)
So what's the rush? This almost feels like a development kernel patch cycle....
How long have you been using Linux? Do you remember when Mylex generously gave specs for their SCSI controllers? Or when Diamond relented and began to release specs for their video cards? I do. I also recall that these things took place before anyone used the term "Open Source". Linux was chugging along getting better and better, growing in its user base. And you know what? There was no OSI or trademark to appease the suits; there was no group of people who felt their job was to talk up Linux.
I'm here today when companies like Creative Labs are just now waking up to to Linux, through the help of those TLAs you disdain. There are still a large number of mfgrs out there that aren't convinced that Linux is worth their time, and they won't be until it is more 'mainstream'.
One point that's worth remembering is that most of us are more directly exposed to ESR's self-promotion and general promotion of OSS than the people he actually targets. That's because his targets are busy reading generic trade rags such as the Wall Street Journal and are getting bombarded by far more marketing from a wider set of angles than most of us. In contrast, the average hacker gets his news from finely tuned websites and Usenet groups with appropriately configured killfiles, filters, etc..
A great many people I know in the open/free/whatever software world try to isolate themselves from the general marketing thrash 'out there', carefully filtering what they're presented with using kill files, spam blockers, staying away from TV, etc. As a result, ESR represents a much larger blip on our radar screen than the radar screens of corporations at-large. This is a natural side effect of the hackers' desire to control the relevance of information in their lives.
The result is that ESR appears as a tireless self promoter, and the hacker community ends up proving that it's not so tireless in its ability to put up with this seemingly non-hacker behavior. That's why I believe ESR comes across so strongly to everyone in the hacker community -- he's cranked the wattage so the suits can see him at all, but he's overpowering our receivers as he does it because we haven't learned when to tune him out.
Don't let ESRs high-wattage broadcasts regarding OSS overpower you. Just because you're not immersed in Microsoftia all the time doesn't mean the suits he's trying to sway aren't.
I'm an American. I don't catch the British Army reference at all. All I know is a good drink when I sip it.
Heck, even Adam Yauch of the B. Boys pays lip service to the wonderful drink, in A Year And A Day on Paul's Boutique:
I'm fishin' in my boat, and I'm fishin' for trout. Mix the Bass Ale with the Guinness Stout. Fishin' for a line, inside my brain, and lookin' out at the world through my window pane.
Nothing like getting a little inspiration from a tall pint of Guinness. The New Gnu Knew, Very Soon At The Zoo, That Guinness Is Good For You.
Actually, what you quote is Hanlon's Razor. Hanlon is widely believed to be a transmogrification of "Heinlein" (the SF author), as one of his characters made a similar statement, though not word for word.
And now for the real general definition of anti-aliasing, for all you real nerds out there.
Aliasing occurs whenever you sample any signal (whether it be an image for display onscreen, or audio, or whatever) at too low a rate, so that some of the information sampled is above the so-called Nyquist rate.
The Nyquist rate is 1/2 the sampling rate, and it represents the maximum bandwidth you can correctly sample without aliases.
In pictures, aliases usually show up as jaggies, but there are other artifacts, such as beat patterns (ever scan a dithered photo?) and so on that are also due to aliasing.
In audio, such as in over-compressed long-distance phone service, aliases usually sound like high-pitched tones which respond in the reverse direction of the pitch of whomever is speaking.
Anti-aliasing is simply the process of avoiding or removing aliasing artifacts in a particular signal. In the case of 2-D graphics, this is usually performed with some sort of smoothing operation. In 3-D graphics, people go to town with bilinear/trilinear pixel interpolation on textures and mip-mapping to handle changes in the sample rate due to the perspective transform, etc.... In audio, it's usually known as a "low pass filter."
Sure, Unix has work to do to be stable for the next 100 years. I'll buy that. Heck, we'll all complain about the time_t wraparound that occurs in 2038. "Unix... best if used before: Tue Jan 19 03:14:08 2038 UTC". Nonetheless, Unix has had 30 years to mature, and most of its major problems have been solved (and new problems, as discovered, are addressed fairly quickly). And we all have another 39 years to brace for Unix's flavor of Y2K problem.;-)
In contrast, Windows NT is still fairly immature, and is growing new code faster than the old code can be fixed. It already has tons of problems, with new problems being added every day -- even faster than old problems are being fixed. When new problems are found in it, we have to wait for Micros~1 to decide when to fix them -- and usually the decision is a marketing based decision, and nothing more.
So which do you choose? 21st Century Problems, or Problems Today (And Forever)?
snicker
PS. I stole someone's 'Micros~1' joke... I like it.
Most Unixes have a 16-bit PID (which gives you 32767 PIDs if they're signed quantities (leaving negative numbers for error values) or 65535 PIDs if they're unsigned). In any case, 0 is not a valid PID, and 1 is left for the special init process (either by convention or by design, I'm sure it depends on which OS you're dealing with).
This does not mean you can have 32K simultaneous processes. Linux's default process table has been 512 or 1024 processes, from what I recall, and it's configurable with a #define if you want more.
Also, in response to another person's comment -- # of processes does not translate into # of users. In fact, typical implementations of a number of common daemons service multiple users with a single process. I believe most MUDs are implemented this way.
I wish they'd include PRE in the set of allowed tags, but from what I recall some dorkass discovered they could make/. be forty screens wide using obnoxious PRE tags.
Perhaps they could filter everything inside of PRE to 80 or 90 columns?
From what I recall, "buckets" (which contain three instructions apiece) are 128 bits wide. If opcodes are 41 bits wide, I wonder what the other 5 bits are used for, and how.... (128 - (41*3)) == 5.
As for the branch predictor, it sounds somewhat interesting. The new part is the "predict that predictor is wrong." chuckle Talk about second-guessing...
The driblets about predication scheme sound bizarre, but then I'm probably tainted by the TMS320C6000-way of doing things...
Me too... Could be a tag-nesting problem. The problem shows up on the main Ask Slashdot page and on the "reply" page, but not on the "Flat Mode" page, if that helps narrow it down.
It might be worth running the page through a web-lint kind of program to see if a tag is getting dropped or added somewhere.
Heh, which explains why my Linux box can still run binaries I compiled in 1995 under Linux 1.0 (as long as I have a copy of libc4 installed), or binaries meant for several other x86 *nixes...
So much for backward compatibility. Oh, wait, that _IS_ backward compatibility. What were you saying?
Granted, programs which vulcan-mind-meld themselves to kernel specific APIs aren't typically cross-platform or cross-version compatible. (PPP, modules support, net tools, etc.) But applications typically don't have much of a problem.
I don't mind the rhetoric or even the ghastly images that the site provides. (While I feel that the site lacks taste, they're welcome to be as tasteless as they like.) The website attempts to be quite pursuasive, and is fairly effective at arousing negative emotions.
Soliciting and archiving personal information about a group of people is also, in itself, not a problem. Marketing agencies pay big bucks to exchange this sort of information all the time.
So what makes this different?
The answer is that the rhetoric also demands "justice" and collecting of "evidence" for "crimes against humanity." This same rhetoric is the rhetoric used to incite lynchings and other violent mob-mentality behavior.
The result is that the website effectively represents a clear and present danger to the people who are listed on the website. Even one of the site's own maintainers admitted that abortionists listed on the site should be worried.
I'm 'pro-choice', both wrt. abortion and to expression of opinion. (You're free to choose whatever opinions you wish to express.) That also means I believe each person is entitled to their* own opinion, and I respect their right to hold that opinion, and I'll defend their right to express their opinion.
I do not condone the blatant linking of hostility, though, with the private data of abortion-performing doctors by linking these opinions and a call for 'judgment' with explicit names, addresses, phone numbers, schedules, and so forth.
Plans for building a bomb should be legal to possess. Parts for building a bomb should be legal to purchase, at least individually. Placing the two in an easy to purchase kit at the local 7-11 should be illegal.
sigh
--Joe
*Footnote: Before the grammarians jump on me for everyone... their, please bear in mind that once upon a time, they and their served either as plural OR singular gender-neutral pronouns, and thus they served to avoid all the try-to-be-gender-neutral he/she--she/he--sie--whatever bullshit that ultra-politically-correct dorkasses seek to impose on us.
Slashdot Mirror
Whenever you post in a public forum, your post is judged by all who read it, even if the judgment is fairly superficial, such as "reading this post (was|was not) worth my time." Of course, judging the relevance and worth of a post is somewhat different than judging the person that's posting.
The point-pool idea doesn't create a currency in the typical sense, since posters cannot exchange this currency directly. The closest thing to such an exchange is the fact that moderation actions on a post will affect someone's pool. I, as a poster, would not be able to exchange points for favors, etc. with other people. And with moderators turning over every few days, it'd be very hard to make a black-market in moderation points.
Given that all of the "currency" comes from and is ultimately controlled by the moderators, and given that the moderators come from a large subset of the posting population, this sounds alot more like a meritocracy with a touch of democratic socialism than the "invisible groping hand" of capitalism.
--Joe--
First, before everyone jumps in and says "Intel will never get there because the compiler will never get there," please don't forget that some shipping devices are already there.
Quite simply, EPIC allows a compiler to tell the hardware ahead of time where it knows parallelism exists, so that the silicon (which is finite) doesn't have to hunt for it. Compared to the rate at which silicon must make scheduling decisions (at 800MHz, that's 1.25 nanoseconds), compiler time seems infinite.
Granted, compiler time is not infinite, but for performance-critical applications, it is quite large. The Texas Instruments TMS320C6000-family of DSPs, for instance, rely on compilers and assembly optimizers in order to eek out that last bit of performance, and as any DSP engineer will likely tell you, its usually worth it. Cycles saved in one loop are cycles that can be spent elsewhere on value-added features, leading to a more valuable product.
This points to the real fundamental problem as I see it, which is that the current VLIW darling in the industry is in the embedded world. Why should that make a difference, you ask? Because the embedded developer is the one most likely to take advantage of the raw capability that an exposed parallelism architecture can provide.
Merced's biggest problem lying ahead is the fact that workstation-class code does not naturally exhibit large amounts of parallelism. While I was attending MICRO-31, I heard someone remark about how most code looks like a series of 5-10 instruction bursts followed by a jump. ICK!!
Embedded programmers generally seem willing to learn whatever it takes to get their product running in the fewest MIPS (so that they can either use cheaper parts or provide more features), and so are often willing to jump through a few hoops to help out the compiler in order to get the parallelism they desire.
Workstation programmers, on the other hand, are interested in the much bigger picture (since their applications are much larger and tend to have larger life expectancies), and so code tends to be human-friendly and not compiler friendly. (Certain heavily-traveled code paths in the Linux kernel being a noteworthy exception.)
The point is that the Merced compiler will ship with alot of amazing compiler transformations, but very few of them will be effective at translating the hopping, skipping, and jumping nature of your typical general-purpose database-ish looking code into highly parallel performance-oozing EPIC instructions, at least straight out of the gate.
Merced will inherently provide big performance wins to the compute-farm customers (your big engineering shops that currently use networks full of Sun or HP workstations to crunch VHDL, Spice, or whatever simulations around the clock), as these applications end up reducing to huge matrix manipulations and numeric crunching galore -- oozing with parallelism. But Merced will be hard pressed to feed up web pages or database queries much faster than any other architecture, unless it's able to massively crank its clock rate due to losing the shackles of the instruction scheduling hardware.
Anyway, those compiler nuts in the crowd might find the following links useful and informative.
- The Rocket Project -- ILP research at Michigan Tech University
- VLIW Architectures -- a description of VLIW that's part of a larger presentation about VLIW compiler techniques.
- The Trimaran Research Compiler -- HP's research compiler that was supposedly used in development of the architecture that begat Merced.
- EE Times -- article which describes the release of Trimaran and includes a diagram showing the relationship of architectures from Superscalar to VLIW/EPIC to TTA.
--Joe--
EPIC is not a multithreaded architecture. EPIC (which, as everyone knows, stands for Explicitly Parallel Instruction Computing) focuses on Instruction Level Parallelism (known in hardware and compiler circles as ILP for short).
Explicit ILP architectures, such as Very Long Instruction Word (VLIW) architectures, Transport Triggered Architectures (TTA) and the like all focus on finding parallelism within a given single-threaded program. The compiler for such an architecture may divide separate paths of execution into a sort-of thread (for instance, it might execute down the "then" and "else" clauses of an "if" before it knows which it nees, or perhaps down multiple "cases" of a "switch"), but this is not multi-threading in the common, macro sense of the term.
Multithreaded architectures, on the other hand, do focus on running multiple independent threads of execution, typically as if they were multiprocessors. For these CPUs, a given application needs to be constructed as a series of explicit threads (at the process level, not the instruction level), or a compiler needs to simulate this division. Alternately, a number of independent processes need to be available (although since all threads share a common pipeline, running independent processes together can have bad cache effects and cumulative stall effects that generally don't make anyone's day).
--Joe--
(Yes, I'm originally from Michigan...)
--
Usually, I like to see a bit more delay between non-development releases. For instance, my fiancee can't be talked into more than about one kernel compile a month.
I kinda liked the long delays between 2.2.1 and 2.2.2. I'm sure people running production servers also appreciate the stability. Things seem to be accelerating again, but I'm hoping that's just due to the relative timing of vacations....
--Joe--
Was there some sort of brown-paper-bag issue in 2.2.4? I know Linus was about to go on a two-week vacation, so did he release this to fix some real showstoppers?
When I checked LinuxHQ, I didn't even see 2.2.5 mentioned yet, and the changelog at Cutting Edge Linux didn't hint at any real showstoppers. Even Alan Cox's diary didn't mention that 2.2.5 was iminent. A search of the Linux Kernel mailing list archives was similarly unenlightening. (I was looking at http://www.tux.org/hypermail/linux-kernel/latest/ ... is there a better place?)
So what's the rush? This almost feels like a development kernel patch cycle....
--Joe--
I'm here today when companies like Creative Labs are just now waking up to to Linux, through the help of those TLAs you disdain. There are still a large number of mfgrs out there that aren't convinced that Linux is worth their time, and they won't be until it is more 'mainstream'.
One point that's worth remembering is that most of us are more directly exposed to ESR's self-promotion and general promotion of OSS than the people he actually targets. That's because his targets are busy reading generic trade rags such as the Wall Street Journal and are getting bombarded by far more marketing from a wider set of angles than most of us. In contrast, the average hacker gets his news from finely tuned websites and Usenet groups with appropriately configured killfiles, filters, etc..
A great many people I know in the open/free/whatever software world try to isolate themselves from the general marketing thrash 'out there', carefully filtering what they're presented with using kill files, spam blockers, staying away from TV, etc. As a result, ESR represents a much larger blip on our radar screen than the radar screens of corporations at-large. This is a natural side effect of the hackers' desire to control the relevance of information in their lives.
The result is that ESR appears as a tireless self promoter, and the hacker community ends up proving that it's not so tireless in its ability to put up with this seemingly non-hacker behavior. That's why I believe ESR comes across so strongly to everyone in the hacker community -- he's cranked the wattage so the suits can see him at all, but he's overpowering our receivers as he does it because we haven't learned when to tune him out.
Don't let ESRs high-wattage broadcasts regarding OSS overpower you. Just because you're not immersed in Microsoftia all the time doesn't mean the suits he's trying to sway aren't.
--Joe--
For as generally pedantic as I am about spelling, I managed to pull a major brain fart there.
--
I'm an American. I don't catch the
British Army reference at all. All
I know is a good drink when I sip it.
Heck, even Adam Yauch of the B. Boys
pays lip service to the wonderful
drink, in A Year And A Day on
Paul's Boutique:
I'm fishin' in my boat, and I'm
fishin' for trout. Mix the Bass Ale
with the Guinness Stout. Fishin'
for a line, inside my brain, and lookin'
out at the world through my window pane.
Nothing like getting a little inspiration
from a tall pint of Guinness.
The New Gnu Knew, Very Soon At The
Zoo, That Guinness Is Good For You.
--
Actually, what you quote is Hanlon's Razor. Hanlon is widely believed to be a transmogrification of "Heinlein" (the SF author), as one of his characters made a similar statement, though not word for word.
--
Ahh yes, Guiness. The perfect topping for a hard day, or a half-pint of Bass Ale in a black-and-tan.
--
Way to go! Slashdot's really shaping up! I actually am wading back into the comments areas again full steam. Nested mode rocks my world.
--
And now for the real general definition of anti-aliasing, for all you real nerds out there.
Aliasing occurs whenever you sample any signal (whether it be an image for display onscreen, or audio, or whatever) at too low a rate, so that some of the information sampled is above the so-called Nyquist rate.
The Nyquist rate is 1/2 the sampling rate, and it represents the maximum bandwidth you can correctly sample without aliases.
In pictures, aliases usually show up as jaggies, but there are other artifacts, such as beat patterns (ever scan a dithered photo?) and so on that are also due to aliasing.
In audio, such as in over-compressed long-distance phone service, aliases usually sound like high-pitched tones which respond in the reverse direction of the pitch of whomever is speaking.
Anti-aliasing is simply the process of avoiding or removing aliasing artifacts in a particular signal. In the case of 2-D graphics, this is usually performed with some sort of smoothing operation. In 3-D graphics, people go to town with bilinear/trilinear pixel interpolation on textures and mip-mapping to handle changes in the sample rate due to the perspective transform, etc.... In audio, it's usually known as a "low pass filter."
And that, my friends, is what anti-aliasing is.
(Yes, I'm an engineer for a DSP company.)
--
12 Steps. Sounds like something to do with Alcoholics Anonymous. I know... Microsoftics Anonymous!
The first step: Admission.
"Hi, my name is John Doe, and I'm a Microsoft user."
"Hi John!"
--
That just means that your traceroute is prohibited, which is probably a good thing.
--
Sure, Unix has work to do to be stable for the next 100 years. I'll buy that. Heck, we'll all complain about the time_t wraparound that occurs in 2038. "Unix... best if used before: Tue Jan 19 03:14:08 2038 UTC" . Nonetheless, Unix has had 30 years to mature, and most of its major problems have been solved (and new problems, as discovered, are addressed fairly quickly). And we all have another 39 years to brace for Unix's flavor of Y2K problem. ;-)
In contrast, Windows NT is still fairly immature, and is growing new code faster than the old code can be fixed. It already has tons of problems, with new problems being added every day -- even faster than old problems are being fixed. When new problems are found in it, we have to wait for Micros~1 to decide when to fix them -- and usually the decision is a marketing based decision, and nothing more.
So which do you choose? 21st Century Problems, or Problems Today (And Forever)?
snicker
PS. I stole someone's 'Micros~1' joke... I like it.
--
Most Unixes have a 16-bit PID (which gives you 32767 PIDs if they're signed quantities (leaving negative numbers for error values) or 65535 PIDs if they're unsigned). In any case, 0 is not a valid PID, and 1 is left for the special init process (either by convention or by design, I'm sure it depends on which OS you're dealing with).
This does not mean you can have 32K simultaneous processes. Linux's default process table has been 512 or 1024 processes, from what I recall, and it's configurable with a #define if you want more.
Also, in response to another person's comment -- # of processes does not translate into # of users. In fact, typical implementations of a number of common daemons service multiple users with a single process. I believe most MUDs are implemented this way.
--
I wish they'd include PRE in the set of allowed tags, but from what I recall some dorkass discovered they could make /. be forty screens wide using obnoxious PRE tags.
Perhaps they could filter everything inside of PRE to 80 or 90 columns?
--
Today's grammar and punctuation lesson: The apostrophe.
Tiler's -- possessive
Tilers -- plural
This is ironic when you consider how much static prediction Merced relies on compilers to perform.
From what I recall, "buckets" (which contain three instructions apiece) are 128 bits wide. If opcodes are 41 bits wide, I wonder what the other 5 bits are used for, and how.... (128 - (41*3)) == 5.
As for the branch predictor, it sounds somewhat interesting. The new part is the "predict that predictor is wrong." chuckle Talk about second-guessing...
The driblets about predication scheme sound bizarre, but then I'm probably tainted by the TMS320C6000-way of doing things...
Me too... Could be a tag-nesting problem. The problem shows up on the main Ask Slashdot page and on the "reply" page, but not on the "Flat Mode" page, if that helps narrow it down.
It might be worth running the page through a web-lint kind of program to see if a tag is getting dropped or added somewhere.
Heh, which explains why my Linux box can still run binaries I compiled in 1995 under Linux 1.0 (as long as I have a copy of libc4 installed), or binaries meant for several other x86 *nixes...
So much for backward compatibility. Oh, wait, that _IS_ backward compatibility. What were you saying?
Granted, programs which vulcan-mind-meld themselves to kernel specific APIs aren't typically cross-platform or cross-version compatible. (PPP, modules support, net tools, etc.) But applications typically don't have much of a problem.
I don't mind the rhetoric or even the ghastly images that the site provides. (While I feel that the site lacks taste, they're welcome to be as tasteless as they like.) The website attempts to be quite pursuasive, and is fairly effective at arousing negative emotions.
Soliciting and archiving personal information about a group of people is also, in itself, not a problem. Marketing agencies pay big bucks to exchange this sort of information all the time.
So what makes this different?
The answer is that the rhetoric also demands "justice" and collecting of "evidence" for "crimes against humanity." This same rhetoric is the rhetoric used to incite lynchings and other violent mob-mentality behavior.
The result is that the website effectively represents a clear and present danger to the people who are listed on the website. Even one of the site's own maintainers admitted that abortionists listed on the site should be worried.
I'm 'pro-choice', both wrt. abortion and to expression of opinion. (You're free to choose whatever opinions you wish to express.) That also means I believe each person is entitled to their* own opinion, and I respect their right to hold that opinion, and I'll defend their right to express their opinion.
I do not condone the blatant linking of hostility, though, with the private data of abortion-performing doctors by linking these opinions and a call for 'judgment' with explicit names, addresses, phone numbers, schedules, and so forth.
Plans for building a bomb should be legal to possess. Parts for building a bomb should be legal to purchase, at least individually. Placing the two in an easy to purchase kit at the local 7-11 should be illegal.
sigh
--Joe*Footnote: Before the grammarians jump on me for everyone ... their, please bear in mind that once upon a time, they and their served either as plural OR singular gender-neutral pronouns, and thus they served to avoid all the try-to-be-gender-neutral he/she--she/he--sie--whatever bullshit that ultra-politically-correct dorkasses seek to impose on us.
This certainly puts the whole "World Domination" plan in a new light....