I am copying a comment from the talkback section on LinuxToday. This gentleman is really pissed.. Read this:
"I really get sick of all the "SMUG KNOW-IT-ALL" attitude comming from some of the members of the LINUX Community! If you'd do a little research before confirming the opinion of some the folks watching the Linux Commununity (bunch of pimply faced teenagers), you'd know that LINUXONE is doing a Chinese translation of LINUX MANDRAKE Distro for the main-land Chinese market. A huge and very worth-while and possibly very lucritave endeavor. Before you run your mouth, ENGAGE YOUR BRAIN!
Keep in mind: YOU ALWAYS FIND THE MOST STICKS AND STONES UNDER THE TREE WITH BEST APPLES ON IT!
Regards, George"
Looks like they have managed to find some hardcore fans on the first day..this is even more ridiculous...
I have written applications using ColdFusion, PHP3, ASP and now Java servlets. Once you fully appreciate the power of servlets; I've never looked back.
PHP3 suffers from the lack of session management-I know there is an add-on to handle that; and I have not checked out Zend (PHP4) in detail, so that might have changed. PHP4 supposedly comes with built-in database connection pooling, it sounds great.
My work with ColdFusion got me a new car, but I've never liked ColdFusion. Yes, CF is probably the easiest server-side scripting solution. But I have never been satisfied with its performance; which may have more to do with NT than CF. CF database connectivity functions are rather simplistic and do not give you much flexibility, IMHO. You can only do so much with s.It might be good enough for use with an ultra-simple database like Access; but once you start using a more complicated database like Oracle or MS SQL Server, you will need more complicated database access interfaces like MS ADO or excellent JDBC. But then, you can of course use ADO with CF, too. By the way, you really don't want to get caught running Access as a database if your site gets/.'ed, or otherwise accessed very heavily. Things will get very ugly. Very ugly.
In my opinion, servlets are the way to go. Download Jserv and Apache, or one of a number of servlet engines for IIS, if you have to run on IIS & Windows NT. Get the O'Reilly servlet book, and start experimenting. You get built-in session management, excellent database connectivity with JDBC, access to all those free Java code around, and a lot of other goodies too numerous to count. When Enterprise JavaBeans become more popular, you will have a very good distributed object technology in hand, too.
I kind of like ASP, but I think Slashdot is not the right place to confess this, so I will stop. It's a pity it runs on NT only-there are a bunch of ASP solutions for other platforms as well (Chili ASP comes to mind), but frankly I'm not sure if you still have access to COM on those platforms. Almost everything that's useful with ASP are COM objects.
In a nutshell:
-If most of your work involves simple database query pages and simple dynamic pages that have to be done quickly, I don't think any of the server side scripting languages will make any differences. ASP, PHP and CF should be equally fine. You probably will not be dealing with fancy features like session management or database connection pooling with these anyway.
-If you need to do more serious applications which will experience high traffic, and complicated database operations, consider servlets, or COM objects with ASP, if you definitely have to use NT. If you use COM and ASP, consider writing the objects using ATL for the highest performance-in terms of performance, it is only second to ISAPI DLLs with IIS. However you will find it very easy to write COM objects in VB as well.
Moving to a real application server like open source Enhydra,Locomotive or IBM WebSphere will be even better in the longer term. They have some pretty impressive infrastructure for use with servlets, and they are very robust, too.
There's no valid analogy between the bandwidth from the CD-ROM drive to the computer and the bandwidth of the network. The CD-ROM drive is used to read actual data for the game functions, like textures, bitmaps and sound samples. The network does not transfer this kind of data in most cases, it is highly optimized data traffic to inform other game clients of the player's current position, etc.
This network traffic is highly optimized to minimize the latency which affects the gameplay negatively, whereas some latency and delay is tolerable, and inevitable during the initialization phase where the game is loading its data from the CD-ROM drive or whatever local storage it is using.
If the game was being played from a shared network directory mounted over the network connection, then your analogy would have been relevant. In this case, it is not.
You don't "pay off your startup capital". It does not work like school loans. A venture capitalist ("VC" in startup lingo) invests in your company by giving you some amount of cash to help you start your company, in return for a percentage of your company. You are then responsible for growing your company, increasing your revenues and profits(if any, Internet start-ups rarely have profits), raising some more money from VCs or individual investors as you go(these are called "rounds of financing"). Eventually if you are successful, you are either acquired by another company or have your IPO and sell the shares of the company in the stock market. Some people immediately get rich, at least on paper. This is how the start-up world works.
Of course they will sell ads. They have to. It is a Good Thing since the cash infusion will let them grow and give better service. Plus as the inventors of that nifty search technology, they deserve to be rich, too.
And AltiVec instructions are not Cray FP type instructions. The only similarity is that they are both SIMD (single instruction stream, multiple data) instructions. Some Cray FP instructions operated on vector data, which is primarily what made them so useful for crunching scientific data very fast. AltiVec instructions are merely Motorola's effort for not missing the SIMD extensions train. Almost all leading architectures have SIMD extensions now for increasing performance in multimedia applications, so Motorola did not want to be left behind, and came up with AltiVec, which is better than most of other companies extensions because it has some instructions traditionally exclusively encountered in the DSP domain...Otherwise it is just a SIMD extension, much like MMX and SSE for Intel, 3DNow! by AMD, VIS by Sun, MVI by Alpha, MIPSV(MDMX) by MIPS, etc..
No, RTL has nothing to do with computer architecture whatsoever. RTL stands for "register transfer level" and is used to refer to a level of abstraction in the description of digital hardware. An RTL description is the description of the internal workings of a digital system using some kind of hardware description language like Verilog or VHDL, or some other notation; that clearly defines the registers, or the state elements, and transitions between them. In case of chip designs, an RTL description of a digital system is usually the input to a logic synthesis system to create the chip.
You probably ran an RTL simulation of a processor. There is no such thing as "RTL instructions".
We have been using Oracle8 on our production systems for about seven months now. It's rock solid, and we have never came across any major problems. IMHO, Oracle is the way to go; you get extensive documentation and design tools, talent is easy to find, there are lots of high-quality books on the market(O'Reilly Oracle series). If you run into a problem, help is readily available from the friendly gurus at various online communities of very high caliber(RevealNet comes to mind)
Oracle is also hard-core on Java, and although we haven't tried Oracle8i, I believe being able to write stored procedures in Java is a major plus (other RDBMS vendors offer this, too. I believe IBM was the first with DB2)
I believe in Oracle and its commitment to Linux, but a potential problem is the rapid changes in Linux kernel and libraries. Lots of Linux people are used to using the latest kernel and system libraries on their systems-this is not a very good practice for your production servers, since obviously big software development companies will not modify their software as often as the Linux kernel. Oracle8 requires a patch to resolve the glibc issue with RedHat6, for example. It is best to stick with a tried and true configuration with these closed-source database solutions, especially when the system is mission critical.
Yes, AMD K6 has a RISC core underneath, and instructions are translated to what AMD calls the "R-ops", if my memory serves me right. AMD K6 has its roots in the NexGen Nx686, which was the successor to Nx586, the first x86 clone on the market which could compete with Pentium's performance.(it was a nice processor, but it flopped for several other reasons) The reason I'm telling this is that Nx586 had an assembler of its own, and theoretically could be programmed using its own RISC assembly language, bypassing the full x86 compatibility layer altogether.
Anything derived from the P6 core (Celeron, Pentium Pro, Pentium II/III) behaves pretty much the same way-x86 instructions are converted to RISC-like shorter ops, and executed by the core. I believe Intel calls these "micro-ops" rather than "R-ops" like AMD does-hence avoiding the "R-word" they don't like to use much...
I agree, but since this is Intel's butter and bread, they are aggressively supporting any company that can come up with creative ways to use all that available horsepower; therefore creating demand. Microsoft, for one, will probably come up with Office 2002 with a 3D-animated Office Assistant paperclip with artificial intelligence and speech recognition..well, you get the picture.
Seriously though, so far game companies have been at the forefront for pushing the performance envelope. During the next two years, broadband, always-on Internet connections will drastically change the computing needs. Increased need for security will lead to use of stronger encryption, people would like to watch streaming videos with larger screen size and better frame rates, and so on.
And don't forget, software people will always manage to find a way of bloating their software with new features that will suck up all available CPU power. Even good old Linux is not the same thing it used to be five years ago. I mean, it was possible to do a lot of work on a 486DX-2/66 with 8MB RAM and trusty twm. Now everyone and his mother seem to run Gnome or KDE for just having a couple of open xterms.
Not really. Those web hosting facilities are usually too damn cold, there are security cameras everywhere, plues the maddening sound of thousands of server fans and disk drives. You really don't want to live there. (I had to spend a night debugging a box there)
Sorry, but this sounds pretty impossible to me. Are you aware of the crudeness of the Enigma cryptographic algorithm vs. modern cryptographic algorithms? I've done some comparative work on this subject for a research paper recently, and just out of curiosity, tested optimized implementations of brute-force attacks against Enigma; although it did not go into the paper since it would have been ridiculous. The Enigma is a joke for modern microprocessors.
IMHO, there absolutely is NO WAY even a 386 can be beaten by the original Turing bombe. This should be some kind of folk tale. But since you mentioned it, can you post here a link or some published article to justify this? Thanks..
FPGAs have been around for a while. It doesn't make any sense to rely on the limited resources and clock speed of an FPGA to implement a CPU to compete with state-of-the-art processors on the market. Sure, it is fun to implement drop-in replacements for 6502 or Z80 in a relatively small Xilinx FPGA; but try coming up with something to compete with Alpha.
The Freedom CPU project was discussed a while ago in the EDN magazine, and almost all professionals agreed it was completely unrealistic. If the Linux hacker community would start hardware design projects; instead of ocerly ambitious projects like Freedom CPU, they should concentrate on simpler, more realistic, and more useful projects: An open-source design for a PDA can be an example, just think about something like Itsy running Linux, based on a commodity processor, with GPL'd design files freely available on the Net. As with Linux distributors, I am sure there would be a lot of enterprising people who would produce low cost kits/finished products based on the design. MIT had a small embedded computer board design based on the Motorola 6811 that they used in their robotics classes; and the design was (perhaps it still is) freely available over the Net. It was immensely popular among hobbyists a couple of years ago. I have been thinking about posting this to Slashdot for discussion for a while now.
This would have been great, but Freedom CPU, IMHO, is totally unrealistic. Of course that's my opinion, and time will tell.
Let's not go into that Freedom CPU thing again. It is a highly dubious project, I remember it being discussed here at some time. If you are waiting for Freedom CPU, good luck.
I thought the question "Who invented the first electronic computer?" was pretty much still an open one. Atanasoff, Zuse and various others come to mind. I understand ENIAC was probably the most influential early electronic computer; and a very important milestone, this is still controversial nevertheless.
It is amazing that historians still could not figure who really was the first. On second thought, I don't expect to, there are a lot of controversies in this field(recent examples: Two engineers from an aerospace company (Grumman, I believe) claim to have invented the microprocesor before Intel, and Russians and Americans are still debating on who invented the first superscalar computer).
So, who invented the first electronic computer really? This can turn into a really interesting discussion...
Of course, as with any computer architecture mentioned here, the quintessential Slashdot rule will still apply to ENIAC, and we shall soon see the obligatory posts about porting Linux to ENIAC and running a Beowulf cluster on reconstructed ENIACs.
Overall, this looks like a great idea. It is much like Cyrix/NatSemi's Web Pad; only it is smaller and runs Linux instead of QNX. If they can offer this at an attractive price, I'm sure a lot of people will buy it. However, the wireless connection needs a bit of clarification-the system contains a DECT phone and I understand it utilizes the DECT system to connect to a base station in the house. DECT is another great European wireless technology standard (don't want to start another GSM vs. CDMA[insert any American(=Qualcomm) digital wireless technology abbreviation here] debate here; but they are pretty good at this stuff); but it is not common in the U.S. From a geek's point of view, the device looks wonderful. To be able to tap into the vast American market, though, they will need to come up with some other means of wireless connectivity, IMHO. Most people will not trash their existing phone system and go get DECT systems just for being able to use this in their home. And remember, this has a very limited range and will only let you access the Internet in or near your house (or wherever the DECT base station is).
Still, given the incredible track record of Nordic people in wireless communications; I believe they should be able to find a way to make this work in the US using a different technology. Until then, I think this is strictly for Europeans. I am not even sure if DECT is permitted by the FCC in the US. Anyone with info on this??
Cache is not something you get to control directly in code.
It can be, in a lot of newer architectures. Prefetching instructions area available in instruction sets of many RISC, and even x86 processors. The main problem is that most optimizing compilers can not do a good job of cache prefetching since there is no corresponding construct in high-level languages, i.e. you do not have a C structure which says "get this memory chunk in the cache". However, for bold people who like to play with assembly language, the instructions are there. Operating systems generally do not like these instructions, though.
Embedded system programmers, particularly those lucky enough to use modern CPUs with cache controllers, can use these tricks.
...read the rest of the cache line. Assuming your code is well optimized for cache performance, the next things you read should already be in the cache.
Of course, you have the assumption that the optimization mentioned here is simply making sure that the current working set fits in the cache line-that's not usually the case with modern software, and you will always have a lot of conflict misses.
IMHO, the previous poster makes a valid point and using the prefetching techniques, it might be possible to get the whole OS into the cache. This might be interesting to play with, but then I'm not sure if it will have any significant advantages-you might be better of loading the application and its working set into the cache rather than the OS. (unless all you do in your application is a bunch of system calls..)
This depends on how you implement the cache, fully associative, set associative or what's the other one again?
Direct mapped. But all of them are essentially set-associative, the only difference is the associativity if you think about what 1-way set associativity and N-way set associativity means (where you have N blocks in the main memory).
Overall, a cache will complete it's lookup in one clock cycle no matter how large it is. Umm, not really. Single cycle access is feasible for the L1 cache for some architectures, but there is no single generalization for that; there are many architectures where cache accesses take anywhere from 2 to 8 clock cycles. Remember they are on a different bus, though.
It all depends on the benchmarks you use and the associativity of the cache, which the designers use to come up with a suitable cache line size. On simulators using RISC instruction sets, 2-4MB caches seem to perform very well in published studies, and particularly Alpha seems to be employing them well. Unfortunately you don't see many studies using the x86 instruction set since no graduate student or professor in his sane mind will try to write an x86 instruction simulator. So all you have is studies based on collected traces; and I remember to have seen several which tried running Windows applications, and found out that these applications will benefit from larger caches immensely. It makes sense given the recent increase in code and working set sizes of available software; and decreasing price of storage which makes having these large working sets feasible.
A cache is not a fix: The cache mechanism relies on the fact that no matter how fast your bus architecture or memory is, there will ALWAYS be a faster memory entity that can be placed closer to the CPU. You might have a 10Gb/s memory bus, but having that kind of technology almost always means you should be able to have an even faster bus if you place it closer to the CPU, simplify the protocol, etc.; and use faster memory.
The current 'bible' of comp. architecture (there are equally good books, but it is the most popular); Hennessy & Patterson's book suggests the following analogy (or similar): When you're working in the library, getting the books that you expect to use from the shelves and putting them on your desk as a "cache" for fast access will be more efficient than walking to the shelves every time you need the books. You suggest that this is a "fix" because you can not walk/run to the shelves fast enough. Then again, even if you can run to the shelves at the speed of sound (or light, for that matter); you will always have a faster access time if you place the books to a place closer than the shelves.
Caches will most likely always be around unless someone comes up with a memory technology where access time is independent of the physical distance from the CPU, and cost is irrelevant (zero). Not very likely to happen in the near future. Actually, we will even see larger caches, check out exciting new architectures like Alpha 21364, Sun MAJC, IBM Power4 etc..
I would not be very impressed with the Yugoslavian education system. How good is your educational system if you teach kids C in 6th grade; or give access to Cray machines in 10th grade for that matter; but fail to provide them with tolerance and humanity that could have prevented disasters like Bosnia and Kosovo? Sorry if this sounds off-topic to you; but the world needs tolerant and sane citizens badly, perhaps even more than the hordes of programmers we will need in the 2000s.
Correct me if I'm wrong, but I think it makes perfect sense to say that it was mainly O'Reilly's focus on Unix and Open Source subjects that helped the company become the popular and respected publisher it is now. O'Reilly's newest catalogs have an increasing number of books featuring Microsoft technologies-and I'm not talking about the "annoyances" series I love most, but books on VB, ASP etc. I, for myself, welcome these additions since market conditions require us to use MS technologies sometimes, although we are true Linux believers at heart. On the other hand, based on my assumption that your "core audience" is mostly Unix/Linux programmer/admins (which might be mistaken, of course); I am curious about the responses that reached you about these latest Microsoft technology-centric O'Reilly titles; and how they are selling. Would you say that O'Reilly plans to become an important publisher of books on MS technologies as well? Finally, thanks for all those great titles you've provided our community. I guess I will stay a loyal O'Reilly customer until the day you run out of weird animals to put on the covers of your books, and start to use pictures of bacteria and virii. (I nominate "Escherischia coli" or the HIV virus for the cover of a possible book about Microsoft SMS)
Look, idiot: The color of your skin does not make you superior or inferior to any other human being living on this planet. That said, I feel obliged to tell you that Turkish people are white. Wait, your local Aryan Nation officer did not tell you that? Oh, how stupid of him. And if you will continue trying to use our language in the titles of your posts, please do not bastardize it..You got it all wrong. Go look it up in a dictionary; and while you're at it; look up the word "OROSPU COCUGU", too..because that's what you exactly are.
It's incredible Rob hasn't moderated this crap down to where it belongs...
Actually, I have been actively developing Ottoman PC for a while now. I believe it's a good idea especially in the US, where ottomans are among the most important "appliances" in life since a significant portion of the people here tend to spend their lives on couches and ottomans watching Jerry Springer and the like.
Slashdot Mirror
I am copying a comment from the talkback section on LinuxToday. This gentleman is really pissed..
Read this:
"I really get sick of all the "SMUG KNOW-IT-ALL" attitude comming from some of the members of the LINUX Community! If you'd do a little research before confirming the opinion of some the folks watching the Linux Commununity (bunch of pimply faced teenagers), you'd know that LINUXONE is doing a Chinese translation of LINUX MANDRAKE Distro for the main-land Chinese market. A huge and very worth-while and possibly very lucritave endeavor. Before you run your mouth, ENGAGE YOUR BRAIN!
Keep in mind: YOU ALWAYS FIND THE MOST STICKS AND STONES UNDER THE TREE WITH BEST APPLES ON IT!
Regards,
George"
Looks like they have managed to find some hardcore fans on the first day..this is even more ridiculous...
I have written applications using ColdFusion, PHP3, ASP and now Java servlets. Once you fully appreciate the power of servlets; I've never looked back.
PHP3 suffers from the lack of session management-I know there is an add-on to handle that; and I have not checked out Zend (PHP4) in detail, so that might have changed. PHP4 supposedly comes with built-in database connection pooling, it sounds great.
My work with ColdFusion got me a new car, but I've never liked ColdFusion. Yes, CF is probably the easiest server-side scripting solution. But I have never been satisfied with its performance; which may have more to do with NT than CF. CF database connectivity functions are rather simplistic and do not give you much flexibility, IMHO. You can only do so much with s.It might be good enough for use with an ultra-simple database like Access; but once you start using a more complicated database like Oracle or MS SQL Server, you will need more complicated database access interfaces like MS ADO or excellent JDBC. But then, you can of course use ADO with CF, too.
By the way, you really don't want to get caught running Access as a database if your site gets
In my opinion, servlets are the way to go. Download Jserv and Apache, or one of a number of servlet engines for IIS, if you have to run on IIS & Windows NT. Get the O'Reilly servlet book, and start experimenting. You get built-in session management, excellent database connectivity with JDBC, access to all those free Java code around, and a lot of other goodies too numerous to count. When Enterprise JavaBeans become more popular, you will have a very good distributed object technology in hand, too.
I kind of like ASP, but I think Slashdot is not the right place to confess this, so I will stop. It's a pity it runs on NT only-there are a bunch of ASP solutions for other platforms as well (Chili ASP comes to mind), but frankly I'm not sure if you still have access to COM on those platforms. Almost everything that's useful with ASP are COM objects.
In a nutshell:
-If most of your work involves simple database query pages and simple dynamic pages that have to be done quickly, I don't think any of the server side scripting languages will make any differences. ASP, PHP and CF should be equally fine. You probably will not be dealing with fancy features like session management or database connection pooling with these anyway.
-If you need to do more serious applications which will experience high traffic, and complicated database operations, consider servlets, or COM objects with ASP, if you definitely have to use NT. If you use COM and ASP, consider writing the objects using ATL for the highest performance-in terms of performance, it is only second to ISAPI DLLs with IIS. However you will find it very easy to write COM objects in VB as well.
Moving to a real application server like open source Enhydra,Locomotive or IBM WebSphere will be even better in the longer term. They have some pretty impressive infrastructure for use with servlets, and they are very robust, too.
There's no valid analogy between the bandwidth from the CD-ROM drive to the computer and the bandwidth of the network. The CD-ROM drive is used to read actual data for the game functions, like textures, bitmaps and sound samples. The network does not transfer this kind of data in most cases, it is highly optimized data traffic to inform other game clients of the player's current position, etc.
This network traffic is highly optimized to minimize the latency which affects the gameplay negatively, whereas some latency and delay is tolerable, and inevitable during the initialization phase where the game is loading its data from the CD-ROM drive or whatever local storage it is using.
If the game was being played from a shared network directory mounted over the network connection, then your analogy would have been relevant. In this case, it is not.
You don't "pay off your startup capital". It does not work like school loans. A venture capitalist ("VC" in startup lingo) invests in your company by giving you some amount of cash to help you start your company, in return for a percentage of your company. You are then responsible for growing your company, increasing your revenues and profits(if any, Internet start-ups rarely have profits), raising some more money from VCs or individual investors as you go(these are called "rounds of financing"). Eventually if you are successful, you are either acquired by another company or have your IPO and sell the shares of the company in the stock market. Some people immediately get rich, at least on paper. This is how the start-up world works.
Of course they will sell ads. They have to. It is a Good Thing since the cash infusion will let them grow and give better service. Plus as the inventors of that nifty search technology, they deserve to be rich, too.
And AltiVec instructions are not Cray FP type instructions. The only similarity is that they are both SIMD (single instruction stream, multiple data) instructions. Some Cray FP instructions operated on vector data, which is primarily what made them so useful for crunching scientific data very fast. AltiVec instructions are merely Motorola's effort for not missing the SIMD extensions train. Almost all leading architectures have SIMD extensions now for increasing performance in multimedia applications, so Motorola did not want to be left behind, and came up with AltiVec, which is better than most of other companies extensions because it has some instructions traditionally exclusively encountered in the DSP domain...Otherwise it is just a SIMD extension, much like MMX and SSE for Intel, 3DNow! by AMD, VIS by Sun, MVI by Alpha, MIPSV(MDMX) by MIPS, etc..
No, RTL has nothing to do with computer architecture whatsoever. RTL stands for "register transfer level" and is used to refer to a level of abstraction in the description of digital hardware. An RTL description is the description of the internal workings of a digital system using some kind of hardware description language like Verilog or VHDL, or some other notation; that clearly defines the registers, or the state elements, and transitions between them. In case of chip designs, an RTL description of a digital system is usually the input to a logic synthesis system to create the chip.
You probably ran an RTL simulation of a processor. There is no such thing as "RTL instructions".
We have been using Oracle8 on our production systems for about seven months now. It's rock solid, and we have never came across any major problems. IMHO, Oracle is the way to go; you get extensive documentation and design tools, talent is easy to find, there are lots of high-quality books on the market(O'Reilly Oracle series). If you run into a problem, help is readily available from the friendly gurus at various online communities of very high caliber(RevealNet comes to mind)
Oracle is also hard-core on Java, and although we haven't tried Oracle8i, I believe being able to write stored procedures in Java is a major plus (other RDBMS vendors offer this, too. I believe IBM was the first with DB2)
I believe in Oracle and its commitment to Linux, but a potential problem is the rapid changes in Linux kernel and libraries. Lots of Linux people are used to using the latest kernel and system libraries on their systems-this is not a very good practice for your production servers, since obviously big software development companies will not modify their software as often as the Linux kernel. Oracle8 requires a patch to resolve the glibc issue with RedHat6, for example. It is best to stick with a tried and true configuration with these closed-source database solutions, especially when the system is mission critical.
Yes, AMD K6 has a RISC core underneath, and instructions are translated to what AMD calls the "R-ops", if my memory serves me right. AMD K6 has its roots in the NexGen Nx686, which was the successor to Nx586, the first x86 clone on the market which could compete with Pentium's performance.(it was a nice processor, but it flopped for several other reasons) The reason I'm telling this is that Nx586 had an assembler of its own, and theoretically could be programmed using its own RISC assembly language, bypassing the full x86 compatibility layer altogether.
Anything derived from the P6 core (Celeron, Pentium Pro, Pentium II/III) behaves pretty much the same way-x86 instructions are converted to RISC-like shorter ops, and executed by the core. I believe Intel calls these "micro-ops" rather than "R-ops" like AMD does-hence avoiding the "R-word" they don't like to use much...
I agree, but since this is Intel's butter and bread, they are aggressively supporting any company that can come up with creative ways to use all that available horsepower; therefore creating demand. Microsoft, for one, will probably come up with Office 2002 with a 3D-animated Office Assistant paperclip with artificial intelligence and speech recognition..well, you get the picture.
Seriously though, so far game companies have been at the forefront for pushing the performance envelope. During the next two years, broadband, always-on Internet connections will drastically change the computing needs. Increased need for security will lead to use of stronger encryption, people would like to watch streaming videos with larger screen size and better frame rates, and so on.
And don't forget, software people will always manage to find a way of bloating their software with new features that will suck up all available CPU power. Even good old Linux is not the same thing it used to be five years ago. I mean, it was possible to do a lot of work on a 486DX-2/66 with 8MB RAM and trusty twm. Now everyone and his mother seem to run Gnome or KDE for just having a couple of open xterms.
Not really. Those web hosting facilities are usually too damn cold, there are security cameras everywhere, plues the maddening sound of thousands of server fans and disk drives. You really don't want to live there. (I had to spend a night debugging a box there)
Sorry, but this sounds pretty impossible to me. Are you aware of the crudeness of the Enigma cryptographic algorithm vs. modern cryptographic algorithms? I've done some comparative work on this subject for a research paper recently, and just out of curiosity, tested optimized implementations of brute-force attacks against Enigma; although it did not go into the paper since it would have been ridiculous. The Enigma is a joke for modern microprocessors.
IMHO, there absolutely is NO WAY even a 386 can be beaten by the original Turing bombe. This should be some kind of folk tale. But since you mentioned it, can you post here a link or some published article to justify this? Thanks..
FPGAs have been around for a while. It doesn't make any sense to rely on the limited resources and clock speed of an FPGA to implement a CPU to compete with state-of-the-art processors on the market. Sure, it is fun to implement drop-in replacements for 6502 or Z80 in a relatively small Xilinx FPGA; but try coming up with something to compete with Alpha.
The Freedom CPU project was discussed a while ago in the EDN magazine, and almost all professionals agreed it was completely unrealistic. If the Linux hacker community would start hardware design projects; instead of ocerly ambitious projects like Freedom CPU, they should concentrate on simpler, more realistic, and more useful projects: An open-source design for a PDA can be an example, just think about something like Itsy running Linux, based on a commodity processor, with GPL'd design files freely available on the Net. As with Linux distributors, I am sure there would be a lot of enterprising people who would produce low cost kits/finished products based on the design. MIT had a small embedded computer board design based on the Motorola 6811 that they used in their robotics classes; and the design was (perhaps it still is) freely available over the Net. It was immensely popular among hobbyists a couple of years ago. I have been thinking about posting this to Slashdot for discussion for a while now.
This would have been great, but Freedom CPU, IMHO, is totally unrealistic. Of course that's my opinion, and time will tell.
Let's not go into that Freedom CPU thing again. It is a highly dubious project, I remember it being discussed here at some time. If you are waiting for Freedom CPU, good luck.
I thought the question "Who invented the first electronic computer?" was pretty much still an open one. Atanasoff, Zuse and various others come to mind. I understand ENIAC was probably the most influential early electronic computer; and a very important milestone, this is still controversial nevertheless.
It is amazing that historians still could not figure who really was the first. On second thought, I don't expect to, there are a lot of controversies in this field(recent examples: Two engineers from an aerospace company (Grumman, I believe) claim to have invented the microprocesor before Intel, and Russians and Americans are still debating on who invented the first superscalar computer).
So, who invented the first electronic computer really? This can turn into a really interesting discussion...
Of course, as with any computer architecture mentioned here, the quintessential Slashdot rule will still apply to ENIAC, and we shall soon see the obligatory posts about porting Linux to ENIAC and running a Beowulf cluster on reconstructed ENIACs.
Overall, this looks like a great idea. It is much like Cyrix/NatSemi's Web Pad; only it is smaller and runs Linux instead of QNX. If they can offer this at an attractive price, I'm sure a lot of people will buy it. However, the wireless connection needs a bit of clarification-the system contains a DECT phone and I understand it utilizes the DECT system to connect to a base station in the house. DECT is another great European wireless technology standard (don't want to start another GSM vs. CDMA[insert any American(=Qualcomm) digital wireless technology abbreviation here] debate here; but they are pretty good at this stuff); but it is not common in the U.S. From a geek's point of view, the device looks wonderful. To be able to tap into the vast American market, though, they will need to come up with some other means of wireless connectivity, IMHO. Most people will not trash their existing phone system and go get DECT systems just for being able to use this in their home. And remember, this has a very limited range and will only let you access the Internet in or near your house (or wherever the DECT base station is).
Still, given the incredible track record of Nordic people in wireless communications; I believe they should be able to find a way to make this work in the US using a different technology. Until then, I think this is strictly for Europeans. I am not even sure if DECT is permitted by the FCC in the US. Anyone with info on this??
Cache is not something you get to control directly in code.
...read the rest of the cache line. Assuming your code is well optimized for cache performance, the next things you read should already be in the cache.
It can be, in a lot of newer architectures. Prefetching instructions area available in instruction sets of many RISC, and even x86 processors. The main problem is that most optimizing compilers can not do a good job of cache prefetching since there is no corresponding construct in high-level languages, i.e. you do not have a C structure which says "get this memory chunk in the cache". However, for bold people who like to play with assembly language, the instructions are there. Operating systems generally do not like these instructions, though.
Embedded system programmers, particularly those lucky enough to use modern CPUs with cache controllers, can use these tricks.
Of course, you have the assumption that the optimization mentioned here is simply making sure that the current working set fits in the cache line-that's not usually the case with modern software, and you will always have a lot of conflict misses.
IMHO, the previous poster makes a valid point and using the prefetching techniques, it might be possible to get the whole OS into the cache. This might be interesting to play with, but then I'm not sure if it will have any significant advantages-you might be better of loading the application and its working set into the cache rather than the OS. (unless all you do in your application is a bunch of system calls..)
This depends on how you implement the cache, fully associative, set associative or what's the other one again?
Direct mapped. But all of them are essentially set-associative, the only difference is the associativity if you think about what 1-way set associativity and N-way set associativity means (where you have N blocks in the main memory).
Overall, a cache will complete it's lookup in one clock cycle no matter how large it is.
Umm, not really. Single cycle access is feasible for the L1 cache for some architectures, but there is no single generalization for that; there are many architectures where cache accesses take anywhere from 2 to 8 clock cycles. Remember they are on a different bus, though.
It all depends on the benchmarks you use and the associativity of the cache, which the designers use to come up with a suitable cache line size. On simulators using RISC instruction sets, 2-4MB caches seem to perform very well in published studies, and particularly Alpha seems to be employing them well. Unfortunately you don't see many studies using the x86 instruction set since no graduate student or professor in his sane mind will try to write an x86 instruction simulator. So all you have is studies based on collected traces; and I remember to have seen several which tried running Windows applications, and found out that these applications will benefit from larger caches immensely. It makes sense given the recent increase in code and working set sizes of available software; and decreasing price of storage which makes having these large working sets feasible.
A cache is not a fix: The cache mechanism relies on the fact that no matter how fast your bus architecture or memory is, there will ALWAYS be a faster memory entity that can be placed closer to the CPU. You might have a 10Gb/s memory bus, but having that kind of technology almost always means you should be able to have an even faster bus if you place it closer to the CPU, simplify the protocol, etc.; and use faster memory.
The current 'bible' of comp. architecture (there are equally good books, but it is the most popular); Hennessy & Patterson's book suggests the following analogy (or similar): When you're working in the library, getting the books that you expect to use from the shelves and putting them on your desk as a "cache" for fast access will be more efficient than walking to the shelves every time you need the books. You suggest that this is a "fix" because you can not walk/run to the shelves fast enough. Then again, even if you can run to the shelves at the speed of sound (or light, for that matter); you will always have a faster access time if you place the books to a place closer than the shelves.
Caches will most likely always be around unless someone comes up with a memory technology where access time is independent of the physical distance from the CPU, and cost is irrelevant (zero). Not very likely to happen in the near future. Actually, we will even see larger caches, check out exciting new architectures like Alpha 21364, Sun MAJC, IBM Power4 etc..
And "definitely", not "definately". This has to be the most common spelling error in English.
Great question..indeed, what happened to GNN? I guess it was there at about the same time as Yahoo if not before?
I would not be very impressed with the Yugoslavian education system. How good is your educational system if you teach kids C in 6th grade; or give access to Cray machines in 10th grade for that matter; but fail to provide them with tolerance and humanity that could have prevented disasters like Bosnia and Kosovo? Sorry if this sounds off-topic to you; but the world needs tolerant and sane citizens badly, perhaps even more than the hordes of programmers we will need in the 2000s.
Correct me if I'm wrong, but I think it makes perfect sense to say that it was mainly O'Reilly's focus on Unix and Open Source subjects that helped the company become the popular and respected publisher it is now. O'Reilly's newest catalogs have an increasing number of books featuring Microsoft technologies-and I'm not talking about the "annoyances" series I love most, but books on VB, ASP etc. I, for myself, welcome these additions since market conditions require us to use MS technologies sometimes, although we are true Linux believers at heart. On the other hand, based on my assumption that your "core audience" is mostly Unix/Linux programmer/admins (which might be mistaken, of course); I am curious about the responses that reached you about these latest Microsoft technology-centric O'Reilly titles; and how they are selling. Would you say that O'Reilly plans to become an important publisher of books on MS technologies as well? Finally, thanks for all those great titles you've provided our community. I guess I will stay a loyal O'Reilly customer until the day you run out of weird animals to put on the covers of your books, and start to use pictures of bacteria and virii. (I nominate "Escherischia coli" or the HIV virus for the cover of a possible book about Microsoft SMS)
Look, idiot: The color of your skin does not make you superior or inferior to any other human being living on this planet. That said, I feel obliged to tell you that Turkish people are white. Wait, your local Aryan Nation officer did not tell you that? Oh, how stupid of him. And if you will continue trying to use our language in the titles of your posts, please do not bastardize it..You got it all wrong. Go look it up in a dictionary; and while you're at it; look up the word "OROSPU COCUGU", too..because that's what you exactly are.
It's incredible Rob hasn't moderated this crap down to where it belongs...
Actually, I have been actively developing Ottoman PC for a while now. I believe it's a good idea especially in the US, where ottomans are among the most important "appliances" in life since a significant portion of the people here tend to spend their lives on couches and ottomans watching Jerry Springer and the like.