A better concept would be to work more in back-end approaches, like a more robust protocol than http
the only real problem I can see with HTTP is the way SSL is handled... which is none at all... HTTPS is merely HTTP in a secure tunnel, and because of that you can't for example have different certificates for virtual hosts running on the same server:port
but I don't see how this affects the *robustness* of HTTP (which is by the way the task of TCP), and I really don't think a whole new protocol would be needed to address this problem, something like SMTP STARTTLS could just be added to the current spec...
So your gripe is that Intel doesn't go out of their way to make sure that AMD's processors do what you want them to do?
Actually the fact is more that Intel does go out of their way to make sure that AMD processors do *not* do what you want them to do (or at least do it slower than expected)
Basically Intel-generated code checks to see if the processor performs certain optimizations by asking the processor what kind it is. Once the feature set of the processor is verified by that simple processor identification test, then the optimized code is run. If it can't be known for sure what a processor will do, wouldn't you *want* them to fall back to more compatible (albeit slower) code?
Let me explain something simple about x86 processors capabilities... There's an instruction in the x86 set called CPUID which does report various infos about the processor... one of them is a 96-bit representation of the actual brand (GenuineIntel, AuthenticAMD, CyrixInstead,...), plus the processor family/part/model number. CPUID also reports the actual capabilities of the processor (MMX/3dnow/SSE/SSE2/SSE3/...). What intel apparently does in their compiler is check the processor brand as reported by CPUID (enabling optimizations if brand == "GenuineIntel") and ignore the capabilities flags.
I mean, they're just making sure that the compiled code will actually work for the widest possible set of target platforms. Surely you don't expect Intel to validate its optimizations against AMD processors.
No I don't, but I expect AMD to validate its processors against the Intel specs, and that's exactly what they do. Just look at another comment above: when a guy hacked an intel-optimized binary to disable the cpu check, it worked (with the same speed improvements) on an AMD chip.
This is OSS took to the extreme. One for all and all for one doesn't apply when people are at risk. If you don't release a fix ASAP then you're knowingly risking the security of peoples computers. Like it or not this is a ridiclous idea from the ground up.
In this case it is a bit more complicated because releasing early patches is putting the distro-using people at risk. The fact is inherent to OSS, when a fix is released you just have to diff the source code to easily find the vulnerability of the old version and exploit it. So in this case I think this expose people to more risk than just a reasonable delay for everyone during which the vulnerability is not disclosed anyway.
So why CGI did not choose to cache native processes? a native process could be blocked at some port, then the web server would wake the process up by sending the request to the process through an IPC mechanism. Therefore the cost of launching the request would be minimized, since the process would already be running. A shared memory queue would be the fastest communication mechanism, I think.
that's exactly what FastCGI servers do, using unix or tcp sockets...
The assholes at the head of the current french governement decided the exact same thing...
the french national (and publicly funded) Meteo France web site now asks you to pay if you want to know something else than the *current* weather... They did the change a few days ago but it seems that nobody noticed here:(
this is not IMHO the kind of ideas the US should rip from the french...
"We want to alert you to the fact that many of you are risking complete loss of access to the USC computer system and both disciplinary and legal action," wrote USC dean of libraries Jerry Campbell and vice president of student affairs Michael Jackson in the e-mail.
The die sizes I quoted are all for a.25u process. According to AMD, the K7 die is less than 100sqmm at 0.18u.
I agree that the K6-III gets a real boost from its onchip L2, but remember that the K7 has 128Kb of L1, and this should be enough to compensate the "slow" half speed L2.
For the FPU, you're right, I should not draw conclusions from the tech docs, but the K7's FPU is something AMD seems really proud of...
If theese numbers are true, I really wonder why AMD hired all theese Alpha designers, and what they've been doing for the past 2 years...
Oh, another "weird" thing is that the tested K7 is supposed to run its L2 at 1/3 core speed. I thought that AMD demonstrated both 500Mhz and 600Mhz K7s with half speed cache (but I may be wrong)...
Yep... I don't trust theese numbers for some obvious reasons...
Ok, so a K7 is slower at WinStone than a P3 at the same frequency ?? This would be VERY SURPRISING given that even the K6-III WS scores are significantly higher than a P3 at same clock speed. This would mean that the K7 is outperformed by a K6-III and I just can't belive this.
Let's compare the CPUs die sizes also :
K6-III : 91 sqmm Pee!!! : about 120 sqmm K7 : about 185 sqmm
K6-III 91 sqmm includes 64Kb L1 and 256Kb L2, K7 just have 128Kb L1 on die...
So, if you got my point, the K7 is more than double the silicon size of the K6, so what do you think they put in... Delay loops ??
Another strange thing is that the K7 system uses and AMD chipset and DRDRAM. ALI is one of the supposed K7 chipset manufacturers... For people who don't know, ALI stands for Acer Labs Inc. so why the hell an Acer engineer is not using an ALI based test system ??! Moreover, the AMD Irongate chipset is not supposed (but don't quote me on this) to support DRDRAM.
The FPU numbers are quite funny too... I read some K7 FPU tech docs (well, the few that are available), and there's absolutely no way that the K7 performs worse than a P3. K7 has 3 fully pipelined FP units, P3 has 2 semi-pipelined units, and P3 has more latency on FMUL, FDIV, etc...
I won't trust any benchmark numbers unless they come from a reliable source, and the register, obviously, is not one (but we already knew it:)
Median filter 3x3 at 415 cycles/pixel... Are you talking about Microsoft optimized code here ???
It can be done in less than 15 cycles with 3DNow (I don't know for KNI and MMX doesn't interest me)
And I guess your 1.23 cycles/pixel doesn't include the memory writes.
It's very easy to hype with hard numbers like this... Did you know that a K6-2 with 3DNow has 4x the peak FP performance of a Pentium 2 ? In real world and with well optimized software, You'll see that the K6-2 is just almost as fast as the P2 (with a few exceptions where it's a bit faster).
Remember, Apple hype is... well.. it's Apple hype!
Do you remember their claims about the iMac 40% faster than a P2/400 ?? I'm still laughing...
I just installed Windows with my ass !!
on
Stop:Quickie Time
·
· Score: 1
Install begin at 10:12, first BSoD at 10:46 The tricky part was... ahem... you know... the mouse thing
There's no need to alter the kernel to run linux on the P3.
The KNI registers save/restore on context switch is only required when the P3 is in KNI mode, and AFAIK, the 2.2 x86 kernel is _not_ written for KNI mode.
That means that NO linux software will be able to use KNI until the kernel supports it.
It takes _any_ audio in (mp3, mic, line in, cd or mixed) so IMHO They're doing it the right way...
Anyway, even if it was just a mp3 broadcasting engine, the decoding&encoding would be needed because you don't want to stream a 128kbps file to modem users and it must be encoded to a lower bitrate.
Slashdot Mirror
This is no memory conrtoller, it is a PC BIOS chip like the one found on most 1999 motherboards ...
A better concept would be to work more in back-end approaches, like a more robust protocol than http
... which is none at all ... HTTPS is merely HTTP in a secure tunnel, and because of that you can't for example have different certificates for virtual hosts running on the same server:port
...
the only real problem I can see with HTTP is the way SSL is handled
but I don't see how this affects the *robustness* of HTTP (which is by the way the task of TCP), and I really don't think a whole new protocol would be needed to address this problem, something like SMTP STARTTLS could just be added to the current spec
Every time i'm going to the netherlands I'm certain I'm gonna stumble upon ATMs in various stages of crash / reboot / BSOD ...
:)
I don't know guys, maybe you should make a special case in your local drug laws concerning the people who code the damn things
So your gripe is that Intel doesn't go out of their way to make sure that AMD's processors do what you want them to do?
... There's an instruction in the x86 set called CPUID which does report various infos about the processor ... one of them is a 96-bit representation of the actual brand (GenuineIntel, AuthenticAMD, CyrixInstead, ...), plus the processor family/part/model number. CPUID also reports the actual capabilities of the processor (MMX/3dnow/SSE/SSE2/SSE3/...). What intel apparently does in their compiler is check the processor brand as reported by CPUID (enabling optimizations if brand == "GenuineIntel") and ignore the capabilities flags.
Actually the fact is more that Intel does go out of their way to make sure that AMD processors do *not* do what you want them to do (or at least do it slower than expected)
Basically Intel-generated code checks to see if the processor performs certain optimizations by asking the processor what kind it is. Once the feature set of the processor is verified by that simple processor identification test, then the optimized code is run. If it can't be known for sure what a processor will do, wouldn't you *want* them to fall back to more compatible (albeit slower) code?
Let me explain something simple about x86 processors capabilities
I mean, they're just making sure that the compiled code will actually work for the widest possible set of target platforms. Surely you don't expect Intel to validate its optimizations against AMD processors.
No I don't, but I expect AMD to validate its processors against the Intel specs, and that's exactly what they do. Just look at another comment above: when a guy hacked an intel-optimized binary to disable the cpu check, it worked (with the same speed improvements) on an AMD chip.
This is OSS took to the extreme. One for all and all for one doesn't apply when people are at risk. If you don't release a fix ASAP then you're knowingly risking the security of peoples computers. Like it or not this is a ridiclous idea from the ground up.
In this case it is a bit more complicated because releasing early patches is putting the distro-using people at risk. The fact is inherent to OSS, when a fix is released you just have to diff the source code to easily find the vulnerability of the old version and exploit it. So in this case I think this expose people to more risk than just a reasonable delay for everyone during which the vulnerability is not disclosed anyway.
there seem to be a double standard concerning reverse engineering ...
...
when it's done on some closed source / restrictive license source control software, it's immoral.
but when we're talking about microsoft office files, it's completely okay, and more, the immoral one here is microsoft
is there something i've missed here ??
So why CGI did not choose to cache native processes? a native process could be blocked at some port, then the web server would wake the process up by sending the request to the process through an IPC mechanism. Therefore the cost of launching the request would be minimized, since the process would already be running. A shared memory queue would be the fastest communication mechanism, I think.
that's exactly what FastCGI servers do, using unix or tcp sockets
they tested 32 bit apps on a 32 bit OS, the 64 bit capabilities of the athlons were not used
The assholes at the head of the current french governement decided the exact same thing ...
... They did the change a few days ago but it seems that nobody noticed here :(
...
the french national (and publicly funded) Meteo France web site now asks you to pay if you want to know something else than the *current* weather
this is not IMHO the kind of ideas the US should rip from the french
"We want to alert you to the fact that many of you are risking complete loss of access to the USC computer system and both disciplinary and legal action," wrote USC dean of libraries Jerry Campbell and vice president of student affairs Michael Jackson in the e-mail.
...
this could explain that
Do you usualy talk about quake as a "2D-projection -of-conceptual-3D-images game" ?
The die sizes I quoted are all for a .25u process. According to AMD, the K7 die is less than 100sqmm at 0.18u.
...
...
...
I agree that the K6-III gets a real boost from its onchip L2, but remember that the K7 has 128Kb of L1, and this should be enough to compensate the "slow" half speed L2.
For the FPU, you're right, I should not draw conclusions from the tech docs, but the K7's FPU is something AMD seems really proud of
If theese numbers are true, I really wonder why AMD hired all theese Alpha designers, and what they've been doing for the past 2 years
Oh, another "weird" thing is that the tested K7 is supposed to run its L2 at 1/3 core speed. I thought that AMD demonstrated both 500Mhz and 600Mhz K7s with half speed cache (but I may be wrong)
Yep ... I don't trust theese numbers for some obvious reasons ...
...
... Delay loops ??
... For people who don't know, ALI stands for Acer Labs Inc. so why the hell an Acer engineer is not using an ALI based test system ??! Moreover, the AMD Irongate chipset is not supposed (but don't quote me on this) to support DRDRAM.
... I read some K7 FPU tech docs (well, the few that are available), and there's absolutely no way that the K7 performs worse than a P3. K7 has 3 fully pipelined FP units, P3 has 2 semi-pipelined units, and P3 has more latency on FMUL, FDIV, etc ...
:)
Ok, so a K7 is slower at WinStone than a P3 at the same frequency ?? This would be VERY SURPRISING given that even the K6-III WS scores are significantly higher than a P3 at same clock speed. This would mean that the K7 is outperformed by a K6-III and I just can't belive this.
Let's compare the CPUs die sizes also :
K6-III : 91 sqmm
Pee!!! : about 120 sqmm
K7 : about 185 sqmm
K6-III 91 sqmm includes 64Kb L1 and 256Kb L2, K7 just have 128Kb L1 on die
So, if you got my point, the K7 is more than double the silicon size of the K6, so what do you think they put in
Another strange thing is that the K7 system uses and AMD chipset and DRDRAM. ALI is one of the supposed K7 chipset manufacturers
The FPU numbers are quite funny too
I won't trust any benchmark numbers unless they come from a reliable source, and the register, obviously, is not one (but we already knew it
Why ?
Can you tell us why the *HELL* it's useless if it's not open ?!!
I read enough people saying "This is not new, everyone can track you using your MAC address".
...
1/ Not everyone is using an ethernet card
2/ I can change the MAC address on mine
Now try to run a computer without a CPU, or try to change the P3 serial ID
The P3 PSN _IS_ an issue unless you are successful with one (or both) of theese solutions.
(notext)
Quite funny ... IMHO it's made up, but it WOULD be fun if it happened :)
...
The rest is just some "Linux rulez" dumb advocacy.
Flame if you want, it's just my opinion
Median filter 3x3 at 415 cycles/pixel ... Are you talking about Microsoft optimized code here ???
... Did you know that a K6-2 with 3DNow has 4x the peak FP performance of a Pentium 2 ? In real world and with well optimized software, You'll see that the K6-2 is just almost as fast as the P2 (with a few exceptions where it's a bit faster).
... well .. it's Apple hype!
...
It can be done in less than 15 cycles with 3DNow (I don't know for KNI and MMX doesn't interest me)
And I guess your 1.23 cycles/pixel doesn't include the memory writes.
It's very easy to hype with hard numbers like this
Remember, Apple hype is
Do you remember their claims about the iMac 40% faster than a P2/400 ?? I'm still laughing
Install begin at 10:12, first BSoD at 10:46 ... ahem ... you know ... the mouse thing
The tricky part was
There's no need to alter the kernel to run linux on the P3.
The KNI registers save/restore on context switch is only required when the P3 is in KNI mode, and AFAIK, the 2.2 x86 kernel is _not_ written for KNI mode.
That means that NO linux software will be able to use KNI until the kernel supports it.
Wow !!
...
There must be some kind of magic here
Can you tell us how you do to keep your CPU temp below the room temp without using active cooling ??
Did you turn the computer ON before ?
Btw, my K6-2/300 is about 25C overclocked to 600Mhz and powered OFF !!
Mac fanatics are soooooo funy sometimes =)
K7 is by no means Super7 compliant. It uses the alpha EV6 bus protocol and needs a new chipset.
I think we'll see a "Socket A" soon !
Shoutcast is not an mp3->raw->mp3 converter !
...
It takes _any_ audio in (mp3, mic, line in, cd or mixed) so IMHO They're doing it the right way
Anyway, even if it was just a mp3 broadcasting engine, the decoding&encoding would be needed because you don't want to stream a 128kbps file to modem users and it must be encoded to a lower bitrate.