Oh, I'm aware of the issues in Open Source and quite a few tech/science fields in general. Hell, in a couple of unix/networking courses I took, our bloody instructor used pinups etc in his presentations, and merely laughed about it. Me and two other guys had a talk with his boss about it, and he got fired within two weeks(The time it took them to find a replacement that could jump in at short notice). Funny thing is, all three of us who complained were mil/ex-mil people, which is an area that is viewed as a hardcore male profession....
The problem is, sexism is always portrayed as a male thing. Which is why I wrote my post about my experience from a female-dominated profession. It's no better there, except that in the public mind, and in academia, it's UNACCEPTABLE to criticize women, while it's open season on men. I encountered that while I studied psychology for example. It was not considered OK to do a follow-up study on a revelation by BRÃ...(BrottsfÃrebyggande RÃ¥det, Crime Prevention Council) which showed that women got on average 20% lower fines/shorter prison terms than men, for the same crime. Meanwhile, a female professor, in public, stated that all men are monsters, and many in academia considered that that was ok.
Less competition in a female-dominated work environment? You are wrong.
There's just as much competition, it just takes other forms, it's less direct. That's one of the great things with the arrival of computer networks and stuff like shared calendars in for example Exchange and other groupware servers..... Secretary dominance fights are less crippling for a company nowadays... Though it still happens, and when it does, it wreaks havoc on entire departments. Same happens in medical care, the sniping, backstabbing and character assassination there is legendary....
Uhm, can't talk for the US, but here in Sweden, it's less hostile for women in the military than in many tech/science fields(And computer/physics/math sciences are the worst), and it's less hostile than for men in quite a few female-dominated professions such as nursing for example, though the military has only grown like that in the last 10 years or so, which coincides with the fact that women aren't automatically made NCO's etc, and the fact that unlike in many other armies in the world, female soldiers are also combatants, same as the men.
Trust me, female-dominated professions are just as bad when it comes to sexism. The nurse profession for example. As a male, it's ok to be a paramedic, or a doctor. But if you even start studying to become a nurse, you're told from the get go that your only purpose as a male is to do the heavy lifts, you get marked down on exams, essays etc merely for being male. As a male, you can be top of your class in actual knowledge, with years of practical experience from warzones, traffic accidents etc, the woman who's afraid of needles, faints at the sight of blood etc will still get a higher grade, and be hired before you when you go looking for a job as a nurse.
Hence, many men drop out of nurse school and study to become doctors instead, which has lead to a rather hilarious policy which has even been used in official proclamations here in Sweden... It goes like this: A study finds that female nurses are heavily overrepresented when it comes to back injuries, due to heavy lifting. As a result of the physical requirements, more men need to be hired for those wards. Meanwhile, female nurses are heavily encouraged to train as lab nurses etc...
I only took those courses for 6 months, then I left, RIGHT before the would-be nurse afraid of needles and blood phobia could leech off of me in the group project where she had been assigned to me by the teacher, without me having any say whatsoever.
Institutional sexism is not limited to men. Women do it just as much.
I had been planning on switching profession from developer to nurse or similar, but I cancelled those plans. I still remain a volunteer paramedic.
Maybe in some european countries, but in Sweden, all phones except the iPhone(unless they've changed that, haven't really paid attention to it) are unlocked, meaning you don't have to pay or even make a phone call to have it unlocked, you just swap SIM and off you go. You're still tied to the contract to pay for the phone, but no need to unlock it.
Point in case, one of my phones is tied to a carriers contract, yet when I go abroad, I just buy a pre-paid SIM in that country and use that to call or surf without roaming charges.
Summing up, european countries aren't the same homogenous market that the US is.
Re:I want to die peacefully in my sleep like my Da
on
How Doctors Die
·
· Score: 2
Few doctors in Sweden swear the Hypocrite oath(the original, strict Hippocratic oath forbids the doctor from engaging in surgery for example), and those who do swear an altered version(that allows for surgery, and also shutting down life support apparatus when it's clear that it will just prolong pain with 0 quality of life).
As a swedish paramedic, I have sworn no such oath, nor would I ever do it.
Also, as a trained paramedic, we always do compressions+breathing, the compressions-only thing is a quick mnemonic taught to people who aren't trained, but they can perhaps manage to save someone.
"Meaning that ICC, or ICC-generated code, will load new microcode for some instructions?
Or that ICC will generate code, for certain processors, that is not valid for the x86 architecture, and might crash or give incorrect data on some processors, but, on other processors, is known (because the developers at Intel know how the microcode works on those processors) to work as desired (presumably even in the face of microcode updates) and known to be faster than the architecturally-correct code?"
Meaning that ICC will generate code that is correct for Intels microcode architecture, but not for AMD's for example. Keep in mind, x86 is now _effectively_ an abstraction layer, with the underlying, ACTUAL ISA being the microcode level, where the implementation differs between the vendors. So for example Intels and AMD's FMADD can look the same on x86-level, and called the same, with the same arguments, but on the microcode level they are completely different.
Compiled and output into a microcode dat file, according to the Intel engineer I talked to.
"Presumably meaning the tools know about the internal implementations, on various processors, of instructions generated from the intrinsics, whether they're microcoded or not. If so, stating it that way might have not have provoked that response."
You have misunderstood exactly what's written on Agner's site.
"1.-Any and all code compiled with the Intel compiler unless patched beforehand not to shall look at the CPUID for Genuine Intel. 2.- If Genuine Intel found run all optimization including the latest SSEs 3.- If not Genuine Intel drop code to slowest code path, X87 mode which ties a boat anchor to the program, to the tune of 40%+."
Point 1 you have completely misunderstood, or you are deliberately stating it erronously. What ACTUALLY happens, is that, in the absence of capability flags, either in the makefiles, or passed on the command line, the compiler will do a CPU check, based on CPUID. As for point 2: That step is actually "Run all optimizations as specified in the DB entry for that CPUID". Point 3: And that was the fallback method for any CPU without an entry in the CPUID database, generic x86, which does not include SSE, MMX etc.
As for the P3 vs P4, at the time, the benchmark programs were typically written in VC6, using MS's compiler, and that included 3DMark, BYTE's own program etc.
With regards to the Atom and the E-series, owning an E-series, the competition between the Atom and the E-series depends entirely on the task, there's no compiler rigging needed to make either one look bad. In some tasks, the higher clocks on the Atoms win out, especially if you can thread it properly. On other tasks, for example strictly sequencial tasks, the E-series win out, due to better IPC, but their clock is heavily limited. I'm currently trying to ditch my E-350, because it's not quite good enough for what I wanted, and it runs hot as hell when decoding movies on the GPU, even with a fan
In terms of using the compilers, unlike you, I've used many of them in my work in both embedded and HPC. In HPC, Intel's compiler has been pretty much standard EVEN FOR AMD CPU's, because it generates the fastest code. Yes, even for Opterons etc. And that's empirical use. PGI is not able to compete with their C and C++ compilers, and their Fortran compiler is also slightly behind.
So come back when you have actually used the compilers, instead of spewing out verbiage proving that all you read is press releases etc.
Yeah, the FSF cultists are in full swing today. Had a post of mine modded down for daring to speak out against GCC-specific extensions, and the fact that FSF fans are hypocrites about standards compliance.
*sighs* Yes, ICC can actually work on microcode level, and yes, CPU's can decode microcode.
How else do you think microcode patches are made for CPU's to work around bugs in the instruction set?
Hint: It's loaded at boot time, from flash RAM, and those patches are made, for example, in ICC. ICC has some optimization tools that can analyze the flow of the microcode in some intrinsics.
As for your incorrect claim about the AMDvsIntel issue, everything hinged on the CPUID check. Anything Intel had a valid entry in the database, anything non-Intel might have been compatible, there just wasn't an entry for it, and was thus treated as generic x86.
Another incorrect point, they weren't convicted, they settled out of court, both with AMD and FTC.
I think you should put your geek card facsimile back into the cereal box you got it from.
The whole thing regarding ICC only doing SOME optimizations for CPU's flagged as Intel was vastly overblown, and there were valid technical reasons to do so, concerning the fact that some of the optimizations regarding intrinsics involve microcode level, which can cause crashes in worst case, or even giving incorrect data only noticed later
Fact remains, ICC was used even for AMD processors despite that, in HPC, because it was better than the competition.
If my very cursory reading of threads.h is correct, it's designed to provide better portability between platforms, without having to use a lot of POSIXisms, for example some embedded stuff that have no use for it, but can make use of threading.
VC and GCC are equally shit at standards compliance *Grumbles*
If either is specified to be used in a project, it means extra work to adapt existing portable code that is strict ISO C to perform well when compiled with either of them.
ICC has quite good ISO C compliance, and the whole thing regarding AMD processors not being optimized for was overexaggerated(and there are some technically valid reasons for it: Some of the intrinsics handling involves microcode level, and Intels and AMD's can look very different. So they had the choice of either treating non-Intel as generic x86, or spend a lot of effort writing code for one of their competitors)
That's because Intel specifically had to introduce the GCCisms(and early on you also needed to patch serious parts of the kernel sources).
It's still bad though, because you have seriously non-standard stuff. The whole situation is just the same as what people have complained about Microsoft for: Implementing non-standard stuff, but instead of ruthless closed-source for-profit, GCC spread theirs with a draconic ideology and religious zealotry. The GCC project in particular has shown itself to play a serious politics game and favouritism, for example in regards to the PPC970 code submitted first from Apple(declined), then by IBM(Accepted without comment, even if significant parts were the code submitted by Apple earlier).
"The big problem is that you can't compile C programs that make use of GCC extensions using Visual C++. "
And being reliant on GCC non-standard stuff is just as stupid as relying on Microsoft non-standard stuff, if you truly believe in standards-compliance, portability and diversity. Truly portable code is code that can be compiled with any compiler for that specific language.
That is one of the reasons why I find so many FSF supporters to be such hypocrits, they blather on about standards compliance, yet they use and abuse GCC extensions etc. The Linux kernel is horribly tainted in that way.
Because THC is dissolved and stored in bodyfat, and can remain for a long time(In at least two cases I know of, there were enough traces left to show up 8 years after they smoked hashish), and can trigger the side-effects of THC, such as paranoia etc... And the psychological strain of the mission is severe enough that you don't want a dopehead who can freak out with paranoia or such.
And yet both the amateur and the professional is right in regards to Clausewitz's statement. For any strategy in the real world, 90-95% of the strategy is logistics. No, they are not separate.
As for Starcraft, it's a bare minimum abstractions tactics, all focusing on micromanagement, which is a deathtrap in real life. People who were good in Brood Wars etc who later went into officer academy or became NCO's turned out to be really bad leaders and tacticians. Many of them have aspergers or OCD, and when faced with an environment where they have to factor in morale, lead times, the fact that micro-management is detrimental etc they couldn't cope with it.
Except that Cogent is the trouble instigator in every single instance. They are like the little trouble maker who runs around poking, kicking, pinching, insulting the larger kid at the playground, yet cries loudly and acts very hurt when he gets slapped in return.
They have meters installed, and yes, they also do have people going around ready to check for abusers in case of electric outages for rows etc. Some of the people involved have more than 10 years experience in running events like Dreamhack etc...
Slashdot Mirror
Oh, I'm aware of the issues in Open Source and quite a few tech/science fields in general. Hell, in a couple of unix/networking courses I took, our bloody instructor used pinups etc in his presentations, and merely laughed about it. Me and two other guys had a talk with his boss about it, and he got fired within two weeks(The time it took them to find a replacement that could jump in at short notice). Funny thing is, all three of us who complained were mil/ex-mil people, which is an area that is viewed as a hardcore male profession....
The problem is, sexism is always portrayed as a male thing. Which is why I wrote my post about my experience from a female-dominated profession. It's no better there, except that in the public mind, and in academia, it's UNACCEPTABLE to criticize women, while it's open season on men. I encountered that while I studied psychology for example. It was not considered OK to do a follow-up study on a revelation by BRÃ...(BrottsfÃrebyggande RÃ¥det, Crime Prevention Council) which showed that women got on average 20% lower fines/shorter prison terms than men, for the same crime. Meanwhile, a female professor, in public, stated that all men are monsters, and many in academia considered that that was ok.
Less competition in a female-dominated work environment? You are wrong.
There's just as much competition, it just takes other forms, it's less direct. That's one of the great things with the arrival of computer networks and stuff like shared calendars in for example Exchange and other groupware servers..... Secretary dominance fights are less crippling for a company nowadays... Though it still happens, and when it does, it wreaks havoc on entire departments. Same happens in medical care, the sniping, backstabbing and character assassination there is legendary....
Uhm, can't talk for the US, but here in Sweden, it's less hostile for women in the military than in many tech/science fields(And computer/physics/math sciences are the worst), and it's less hostile than for men in quite a few female-dominated professions such as nursing for example, though the military has only grown like that in the last 10 years or so, which coincides with the fact that women aren't automatically made NCO's etc, and the fact that unlike in many other armies in the world, female soldiers are also combatants, same as the men.
Trust me, female-dominated professions are just as bad when it comes to sexism. The nurse profession for example. As a male, it's ok to be a paramedic, or a doctor. But if you even start studying to become a nurse, you're told from the get go that your only purpose as a male is to do the heavy lifts, you get marked down on exams, essays etc merely for being male. As a male, you can be top of your class in actual knowledge, with years of practical experience from warzones, traffic accidents etc, the woman who's afraid of needles, faints at the sight of blood etc will still get a higher grade, and be hired before you when you go looking for a job as a nurse.
Hence, many men drop out of nurse school and study to become doctors instead, which has lead to a rather hilarious policy which has even been used in official proclamations here in Sweden... It goes like this: A study finds that female nurses are heavily overrepresented when it comes to back injuries, due to heavy lifting. As a result of the physical requirements, more men need to be hired for those wards. Meanwhile, female nurses are heavily encouraged to train as lab nurses etc...
I only took those courses for 6 months, then I left, RIGHT before the would-be nurse afraid of needles and blood phobia could leech off of me in the group project where she had been assigned to me by the teacher, without me having any say whatsoever.
Institutional sexism is not limited to men. Women do it just as much.
I had been planning on switching profession from developer to nurse or similar, but I cancelled those plans. I still remain a volunteer paramedic.
Maybe in some european countries, but in Sweden, all phones except the iPhone(unless they've changed that, haven't really paid attention to it) are unlocked, meaning you don't have to pay or even make a phone call to have it unlocked, you just swap SIM and off you go. You're still tied to the contract to pay for the phone, but no need to unlock it.
Point in case, one of my phones is tied to a carriers contract, yet when I go abroad, I just buy a pre-paid SIM in that country and use that to call or surf without roaming charges.
Summing up, european countries aren't the same homogenous market that the US is.
Few doctors in Sweden swear the Hypocrite oath(the original, strict Hippocratic oath forbids the doctor from engaging in surgery for example), and those who do swear an altered version(that allows for surgery, and also shutting down life support apparatus when it's clear that it will just prolong pain with 0 quality of life).
As a swedish paramedic, I have sworn no such oath, nor would I ever do it.
Also, as a trained paramedic, we always do compressions+breathing, the compressions-only thing is a quick mnemonic taught to people who aren't trained, but they can perhaps manage to save someone.
"Meaning that ICC, or ICC-generated code, will load new microcode for some instructions?
Or that ICC will generate code, for certain processors, that is not valid for the x86 architecture, and might crash or give incorrect data on some processors, but, on other processors, is known (because the developers at Intel know how the microcode works on those processors) to work as desired (presumably even in the face of microcode updates) and known to be faster than the architecturally-correct code?"
Meaning that ICC will generate code that is correct for Intels microcode architecture, but not for AMD's for example. Keep in mind, x86 is now _effectively_ an abstraction layer, with the underlying, ACTUAL ISA being the microcode level, where the implementation differs between the vendors. So for example Intels and AMD's FMADD can look the same on x86-level, and called the same, with the same arguments, but on the microcode level they are completely different.
""Made in ICC" in what sense?"
Compiled and output into a microcode dat file, according to the Intel engineer I talked to.
"Presumably meaning the tools know about the internal implementations, on various processors, of instructions generated from the intrinsics, whether they're microcoded or not. If so, stating it that way might have not have provoked that response."
It can do both
Question: Do you thus consider the Linux Kernel to be the BIOS? Or Linux utils such as the microcode_ctl tool?
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/5.6_Technical_Notes/microcode_ctl.html
And ICC can do both.
It just doesn't generate microcode with standard flags.
You have misunderstood exactly what's written on Agner's site.
"1.-Any and all code compiled with the Intel compiler unless patched beforehand not to shall look at the CPUID for Genuine Intel. 2.- If Genuine Intel found run all optimization including the latest SSEs 3.- If not Genuine Intel drop code to slowest code path, X87 mode which ties a boat anchor to the program, to the tune of 40%+."
Point 1 you have completely misunderstood, or you are deliberately stating it erronously. What ACTUALLY happens, is that, in the absence of capability flags, either in the makefiles, or passed on the command line, the compiler will do a CPU check, based on CPUID. As for point 2: That step is actually "Run all optimizations as specified in the DB entry for that CPUID". Point 3: And that was the fallback method for any CPU without an entry in the CPUID database, generic x86, which does not include SSE, MMX etc.
As for the P3 vs P4, at the time, the benchmark programs were typically written in VC6, using MS's compiler, and that included 3DMark, BYTE's own program etc.
With regards to the Atom and the E-series, owning an E-series, the competition between the Atom and the E-series depends entirely on the task, there's no compiler rigging needed to make either one look bad. In some tasks, the higher clocks on the Atoms win out, especially if you can thread it properly. On other tasks, for example strictly sequencial tasks, the E-series win out, due to better IPC, but their clock is heavily limited. I'm currently trying to ditch my E-350, because it's not quite good enough for what I wanted, and it runs hot as hell when decoding movies on the GPU, even with a fan
In terms of using the compilers, unlike you, I've used many of them in my work in both embedded and HPC. In HPC, Intel's compiler has been pretty much standard EVEN FOR AMD CPU's, because it generates the fastest code. Yes, even for Opterons etc. And that's empirical use. PGI is not able to compete with their C and C++ compilers, and their Fortran compiler is also slightly behind.
So come back when you have actually used the compilers, instead of spewing out verbiage proving that all you read is press releases etc.
Yeah, the FSF cultists are in full swing today. Had a post of mine modded down for daring to speak out against GCC-specific extensions, and the fact that FSF fans are hypocrites about standards compliance.
*sighs* Yes, ICC can actually work on microcode level, and yes, CPU's can decode microcode.
How else do you think microcode patches are made for CPU's to work around bugs in the instruction set?
Hint: It's loaded at boot time, from flash RAM, and those patches are made, for example, in ICC. ICC has some optimization tools that can analyze the flow of the microcode in some intrinsics.
Hell, a lot of projects have microcode specifications, and both Intel and AMD regularly submit such references to Linux as can be seen here: http://comments.gmane.org/gmane.linux.kernel/1204282
As for your incorrect claim about the AMDvsIntel issue, everything hinged on the CPUID check. Anything Intel had a valid entry in the database, anything non-Intel might have been compatible, there just wasn't an entry for it, and was thus treated as generic x86.
Another incorrect point, they weren't convicted, they settled out of court, both with AMD and FTC.
I think you should put your geek card facsimile back into the cereal box you got it from.
The whole thing regarding ICC only doing SOME optimizations for CPU's flagged as Intel was vastly overblown, and there were valid technical reasons to do so, concerning the fact that some of the optimizations regarding intrinsics involve microcode level, which can cause crashes in worst case, or even giving incorrect data only noticed later
Fact remains, ICC was used even for AMD processors despite that, in HPC, because it was better than the competition.
If my very cursory reading of threads.h is correct, it's designed to provide better portability between platforms, without having to use a lot of POSIXisms, for example some embedded stuff that have no use for it, but can make use of threading.
Patenting is not the same thing as shoddy standards-compliance/developing and extending non-standard stuff.
Also, I did point out Microsofts ruthless for-profit mentality AS OPPOSED to FSF's religious zealotry.
VC and GCC are equally shit at standards compliance *Grumbles*
If either is specified to be used in a project, it means extra work to adapt existing portable code that is strict ISO C to perform well when compiled with either of them.
ICC has quite good ISO C compliance, and the whole thing regarding AMD processors not being optimized for was overexaggerated(and there are some technically valid reasons for it: Some of the intrinsics handling involves microcode level, and Intels and AMD's can look very different. So they had the choice of either treating non-Intel as generic x86, or spend a lot of effort writing code for one of their competitors)
That's because Intel specifically had to introduce the GCCisms(and early on you also needed to patch serious parts of the kernel sources).
It's still bad though, because you have seriously non-standard stuff. The whole situation is just the same as what people have complained about Microsoft for: Implementing non-standard stuff, but instead of ruthless closed-source for-profit, GCC spread theirs with a draconic ideology and religious zealotry. The GCC project in particular has shown itself to play a serious politics game and favouritism, for example in regards to the PPC970 code submitted first from Apple(declined), then by IBM(Accepted without comment, even if significant parts were the code submitted by Apple earlier).
"The big problem is that you can't compile C programs that make use of GCC extensions using Visual C++. "
And being reliant on GCC non-standard stuff is just as stupid as relying on Microsoft non-standard stuff, if you truly believe in standards-compliance, portability and diversity. Truly portable code is code that can be compiled with any compiler for that specific language.
That is one of the reasons why I find so many FSF supporters to be such hypocrits, they blather on about standards compliance, yet they use and abuse GCC extensions etc. The Linux kernel is horribly tainted in that way.
Oh, those bunk science claims again. Fully on par with homeopathy, vegan "sciences" and free energy kooks
Because THC is dissolved and stored in bodyfat, and can remain for a long time(In at least two cases I know of, there were enough traces left to show up 8 years after they smoked hashish), and can trigger the side-effects of THC, such as paranoia etc... And the psychological strain of the mission is severe enough that you don't want a dopehead who can freak out with paranoia or such.
No matter how much you watch kids, they will ALWAYS find that split second they need to put something in their mouth.
The fact that it isn't as terse as, say, Java, is a good thing in terms of maintenance and debugging however, especially long-term.
And yet both the amateur and the professional is right in regards to Clausewitz's statement. For any strategy in the real world, 90-95% of the strategy is logistics. No, they are not separate.
As for Starcraft, it's a bare minimum abstractions tactics, all focusing on micromanagement, which is a deathtrap in real life. People who were good in Brood Wars etc who later went into officer academy or became NCO's turned out to be really bad leaders and tacticians. Many of them have aspergers or OCD, and when faced with an environment where they have to factor in morale, lead times, the fact that micro-management is detrimental etc they couldn't cope with it.
Except that Cogent is the trouble instigator in every single instance. They are like the little trouble maker who runs around poking, kicking, pinching, insulting the larger kid at the playground, yet cries loudly and acts very hurt when he gets slapped in return.
They have meters installed, and yes, they also do have people going around ready to check for abusers in case of electric outages for rows etc. Some of the people involved have more than 10 years experience in running events like Dreamhack etc...