A 80186? That is really weird. As far as I know, the 80186 was only used for embedded applications, and never made it into a general-purpose PC.
It was rare, but it did make into normal PCs. I used a Siemens PC-D during my education. It was a bit slow, had a non-standard keyboard, non-standard graphic controller, an on-board hardware debugger (which defaulted to german keyboard layout) and the BIOS was a bit weird.
Considering how little data is traversed to wager the cost, I can't see how its anywhere near reasonable.
You are right that the cost of and SMS in the network is practically zero. But there are two other factors detemining the price:
The initial cost of the SMS service center / gateway has to be covered. That hardware is not exactly cheap...
The inter-carrier settlement price. If the carriers have agreed on 15 cent when forwarding other carriers' SMS, then you cannot sell SMS for less. Sure, you can send then internally in your network cheaper, but with number portability that pricing would be opaque to the users.
What do other countries such as Asia, Europe and America pay?
Depends, 1.5 - 5.5 eurocents in Denmark. The prices in Denmark have the past few years mostly followed the inter-carrier settlement cost.
Actually IBM z/VM is geared toward virtualization. Everything you run on it is running inside its own VM. The instruction set is also virtualized - it is changed on-the-fly to whatever the CPU supports. That is how old programs from the sixties can still run on modern hardware.
More information at http://www.vm.ibm.com/
But z/VM will not be the "new virtual machine" for desktops because: (a) the virtual instruction set is s390, (b) all I/O is done through "channels", (c) you need big iron to run it.
Have you considered Oracle iFS? Since it is based on an Oracle DB so it should be possible to do a two-way replication. Or possibly make the synchronization policy yourself by database triggers.
I agree - there is a definite risk of the Itanium being squeezed out between the low-end (where performance/price ratio is important) and the high-end (where consultancy, support and application support are important).
They can try various things:
Lower the price
But I don't think that the CPU itself is the most expensive part of an Itanium system.
Improve performance
This is going to be interesting. We still haven't seen how "mature" Itanium and "mature" x86-64 compares. Itanium probably needs another iteration before we can see if you really can just keep on addign execution units to the Itanium architecture.
Rely on integrators/partners/consultancy
Currently they are relying on HP, but I know that HP is essentially technology-agnostic - they frequently sell IBM power systems, Sun SPARC machines, etc. as part of integration projects.
I think that Intel will try all of the above.
What I am really missing in the x86 CPUs is the amount of monitoring counters that are present in Itanium. I cannot remember the exact number but Itanium has about 200 distinct performance counters. That is really helpful when you are tuning an application. I still haven't seen anything like it on other CPUs.
And me? I'm using an Alpha machine because it is slightly obscure:-)
I don't think that Intel will have any problems with keeping Itanium viable. Itanium is not geared toward low-end systems, and in those system the CPU is not everything. It also seems that Intel has lately been using some of HP and Compaq's engineers to make the next generation of Itanium and it got a major speed increase by that. We still haven't seen where Itanium does not scale, whereas we know where the x86 has problems (too few registers, do complicated instruction decoder), so in a couple of years we may see that x86-64 cannot scale better than Itanium and it is a dead end (or we may see the reverse)
It is going to be interesting for the customers that are currently running Alpha and PA-RISC on large servers. If they have to recompile to a new architecture will they jump on the Itanium or the x86-64 wagon?
But using Itanium for a single-CPU system? That does not make sense. You simply get more power using the "low-end" x86.
True. I did not try to run it through a feedback profiler and then rearranging the code to keep the hot code together. That could have been interesting. I have another theory: the compiler could assume 64-bit operations were safe and did them behind my back for copying data. Or maybe the heap manager is vastly more efficient in 64-bit mode than in 32-bit. I remember the watcom compiler doing similar tricks in 16-bit mode with inlining structure-copying by setting up SI and DI registers an doing 32-bit moves if it knew it was safe.
A few years back I did a test with a server which store state information (I will not bore you with the details). I did some performance test on both the 32-bit version and the 64-bit version. Same source code. Same test data. Same configuration. On HP-UX 11.0 PA-RISC with the aCC compiler. The 64-bit version used about 15% more memory than the 32-bit version. But it was also 20% percent faster. That still puzzles me, because the server does not perform any 64-bit operations.
There have been some nice price drops during the past 6 months. Instead of lowering the prices Cybercity chose to double the downstream speed at no cost.
There are numerous possible billing models. You can pay a fixed amount per month; per MB; you can pay directly to the hotspot provider; you can pay via you ISP; The payment can be post-paid or pre-paid. Maybe you want to "top up" the pre-paid account. Maybe the pre-paid account should expire 72 hours after activation. Maybe the hotspot location wants to sponsor your access. It all boils down to 1 thing: Getting money from your pocket. The billing model has to be predictable and transparent. Most end-users do not really grasp the concept of per-MB billing. Per-month models have problems with high-bandwidth users.Pure wireless ISPs have problems with getting the customers in the first place, while the regular ISP (where the users already have an account) may not have the necessary infrastructure to handle roaming users.
I recently spoke with software developer who knew a bit about this. He claimed that the accuracy, even in areas with very good GSM coverage, were not better than 100 meters. He also said that in areas where there were coverage with only 1 or 2 stations the accuracy was about 1km.
Do anyone have supporting or contradicting information?
Thise one is probably older: IDENTIFICATION DIVISION. PROGRAM-ID. HELLO. AUTHOR. ANONYMOUS. ENVIRONMENT DIVISION. DATA DIVISION. PROCEDURE DIVISION. MAINLINE. DISPLAY 'Hello world!'. STOP RUN.
It should be a valid program back in 1959. But I am not sure if the non-capital letters were supported on those old beasts. You may have had to specify the source-computer and the object-computer directives to make it convert the character sets automatically. It is also quite interesting that slashdot is very unfriendly to cobol code. It claims that I am yelling AND that the "postercomment" compression filter is triggered.
The author has reinvented the wheel. Any debug heap that provides a trace can do this, so this is basically an old hat. http://www.cbmamiga.demon.co.uk/mpatrol/mpat rol_83.html provides a very good list of resources for debug heaps.
I prefer documentation over source code. But the microsoft documentation on user/gdi/kernel is incomplete. It covers the trivial cases but leaves out most corner cases. When compared to, say, OS/2 API documentation the microsoft documentation is "thin". IBM knows how to write documentation. An example: GDI paths. (selectclippath, beginpath, closefigure, etc). The documentation tells you how to make a string into the outline and use that as a path. It even has an example for doing this. good. Guess what happens if the font you are using is a bitmap font? The documentation does not tell you. Not even a hint. (answer: the path functions does not fail, they just simply wont work). The API could also be a lot better especially when dealing with errors. People who have tried using BitBlt or SetDIBits knows the horrors of error 87. One of my other favorites in the documentation is: "If the function succeeds, the return value is 1. If the function fails, the return value is 1."
A filesystem has never (AFAIK) implemented a trash / recycle bin folder -- not on Windows or OS X, and not on any UNIX that I know of.
Actually, OS/2 implemented it. It could be enabled/disabled per drive, the size of the trashcan could be configured, and it worked even for temporary files made by programs. And yes, it was somewhat slow.
Exactly. I can see why the code was split up - to increase reuse. Which is fine if the code you are reusing is of good quality. But the drop-in shadow is drawn as bitmaps, which means that it scales poorly in higher resolutions. It is not that difficult to use PolyLine/PolySegment instead, and the requests are smaller and mostly likely faster. There is not even a single comment line regarding this in the GTK source. So there is room for improvement (and it may have improved in GTK 2 which I have not looked into - yet)
I have looked into this and, yes, there are blatant inefficiencies in GTK. For instance: to draw the simple box with a mark in it for checkboxes, GTK 1.2 uses 6 PutImage operations. Does it cache the result at the server? No, it does it every time it needs to draw the box. It does not even compose the pixmap itself and then uses a single PutImage. The most efficient way of doing it is to compose the pixmap at the server, and the on each Expose event simply do a single CopyArea operation. (backing store would be even better). Looking into the GTK source code shows that this is not a simple thing to remedy. The drop-in shadows of the box is handled by one part of the code, the checkmark by another, and so on.
There are also examples of inefficient resource use. gcolorsel (v1.40) needs a pixmap for each color. 1165 pixmaps. This does not sound as a reasonable requirement to me.
You forget how nvidia and vmware handles this. They provide their drivers as two parts: one binary closed-source part, and one source wrapper. This allows them to provide their driver as binary only, and let the wrapper be compiled to fit the kernel. And if you are running a well-known kernel then the driver bundle includes the source part precompiled so you do not even need a compiler. NVidia even uses the same binary part for their drivers for windows and linux (ok, possibly compiled with different compilers), so the kernel version cannot really be the issue here. I assume that Intel and NVidia has different strategies here for driver development. It seems that NVidia has a group developing the common part, and then different groups developing the OS-specific parts. I suspect that Intel is using distinct groups here instead, which means seperate resource allocation. Or maybe network drivers are just so different that Intel cannot make a common part?
Slashdot Mirror
Do you have any references to back that up?
A 80186? That is really weird. As far as I know, the 80186 was only used for embedded applications, and never made it into a general-purpose PC.
It was rare, but it did make into normal PCs. I used a Siemens PC-D during my education. It was a bit slow, had a non-standard keyboard, non-standard graphic controller, an on-board hardware debugger (which defaulted to german keyboard layout) and the BIOS was a bit weird.
You are right that the cost of and SMS in the network is practically zero. But there are two other factors detemining the price:
What do other countries such as Asia, Europe and America pay?
Depends, 1.5 - 5.5 eurocents in Denmark. The prices in Denmark have the past few years mostly followed the inter-carrier settlement cost.
Google for "The Moral Virologist"
How about OpenWatcom ? It is a pretty decent compiler, although a bit dated now.
Actually IBM z/VM is geared toward virtualization. Everything you run on it is running inside its own VM. The instruction set is also virtualized - it is changed on-the-fly to whatever the CPU supports. That is how old programs from the sixties can still run on modern hardware.
More information at http://www.vm.ibm.com/
But z/VM will not be the "new virtual machine" for desktops because: (a) the virtual instruction set is s390, (b) all I/O is done through "channels", (c) you need big iron to run it.
Have you considered Oracle iFS? Since it is based on an Oracle DB so it should be possible to do a two-way replication. Or possibly make the synchronization policy yourself by database triggers.
They can try various things:
- Lower the price
- Improve performance
- Rely on integrators/partners/consultancy
I think that Intel will try all of the above.But I don't think that the CPU itself is the most expensive part of an Itanium system.
This is going to be interesting. We still haven't seen how "mature" Itanium and "mature" x86-64 compares. Itanium probably needs another iteration before we can see if you really can just keep on addign execution units to the Itanium architecture.
Currently they are relying on HP, but I know that HP is essentially technology-agnostic - they frequently sell IBM power systems, Sun SPARC machines, etc. as part of integration projects.
What I am really missing in the x86 CPUs is the amount of monitoring counters that are present in Itanium. I cannot remember the exact number but Itanium has about 200 distinct performance counters. That is really helpful when you are tuning an application. I still haven't seen anything like it on other CPUs.
And me? I'm using an Alpha machine because it is slightly obscure :-)
I don't think that Intel will have any problems with keeping Itanium viable. Itanium is not geared toward low-end systems, and in those system the CPU is not everything. It also seems that Intel has lately been using some of HP and Compaq's engineers to make the next generation of Itanium and it got a major speed increase by that. We still haven't seen where Itanium does not scale, whereas we know where the x86 has problems (too few registers, do complicated instruction decoder), so in a couple of years we may see that x86-64 cannot scale better than Itanium and it is a dead end (or we may see the reverse)
It is going to be interesting for the customers that are currently running Alpha and PA-RISC on large servers. If they have to recompile to a new architecture will they jump on the Itanium or the x86-64 wagon?
But using Itanium for a single-CPU system? That does not make sense. You simply get more power using the "low-end" x86.
True. I did not try to run it through a feedback profiler and then rearranging the code to keep the hot code together. That could have been interesting.
I have another theory: the compiler could assume 64-bit operations were safe and did them behind my back for copying data. Or maybe the heap manager is vastly more efficient in 64-bit mode than in 32-bit.
I remember the watcom compiler doing similar tricks in 16-bit mode with inlining structure-copying by setting up SI and DI registers an doing 32-bit moves if it knew it was safe.
A few years back I did a test with a server which store state information (I will not bore you with the details). I did some performance test on both the 32-bit version and the 64-bit version. Same source code. Same test data. Same configuration. On HP-UX 11.0 PA-RISC with the aCC compiler.
The 64-bit version used about 15% more memory than the 32-bit version. But it was also 20% percent faster. That still puzzles me, because the server does not perform any 64-bit operations.
I have DSL 2048/512 for 79 euro = USD 101
There have been some nice price drops during the past 6 months. Instead of lowering the prices Cybercity chose to double the downstream speed at no cost.
Of course they can. RFC2865, page 48, "Session-Timeout". It only needs a bit of support in the billing system.
I always thought that XFS was some sort of an integrated IC circuit.
There are numerous possible billing models. You can pay a fixed amount per month; per MB; you can pay directly to the hotspot provider; you can pay via you ISP; The payment can be post-paid or pre-paid. Maybe you want to "top up" the pre-paid account. Maybe the pre-paid account should expire 72 hours after activation. Maybe the hotspot location wants to sponsor your access. It all boils down to 1 thing: Getting money from your pocket.
The billing model has to be predictable and transparent. Most end-users do not really grasp the concept of per-MB billing. Per-month models have problems with high-bandwidth users.Pure wireless ISPs have problems with getting the customers in the first place, while the regular ISP (where the users already have an account) may not have the necessary infrastructure to handle roaming users.
2004 is going to be a very interesting year.
I recently spoke with software developer who knew a bit about this. He claimed that the accuracy, even in areas with very good GSM coverage, were not better than 100 meters. He also said that in areas where there were coverage with only 1 or 2 stations the accuracy was about 1km.
Do anyone have supporting or contradicting information?
Thise one is probably older:
IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.
AUTHOR. ANONYMOUS.
ENVIRONMENT DIVISION.
DATA DIVISION.
PROCEDURE DIVISION.
MAINLINE.
DISPLAY 'Hello world!'.
STOP RUN.
It should be a valid program back in 1959. But I am not sure if the non-capital letters were supported on those old beasts. You may have had to specify the source-computer and the object-computer directives to make it convert the character sets automatically.
It is also quite interesting that slashdot is very unfriendly to cobol code. It claims that I am yelling AND that the "postercomment" compression filter is triggered.
The author has reinvented the wheel. Any debug heap that provides a trace can do this, so this is basically an old hat.t rol_83 .html provides a very good list of resources for debug heaps.
http://www.cbmamiga.demon.co.uk/mpatrol/mpa
I prefer documentation over source code. But the microsoft documentation on user/gdi/kernel is incomplete. It covers the trivial cases but leaves out most corner cases. When compared to, say, OS/2 API documentation the microsoft documentation is "thin". IBM knows how to write documentation.
An example: GDI paths. (selectclippath, beginpath, closefigure, etc). The documentation tells you how to make a string into the outline and use that as a path. It even has an example for doing this. good. Guess what happens if the font you are using is a bitmap font? The documentation does not tell you. Not even a hint. (answer: the path functions does not fail, they just simply wont work).
The API could also be a lot better especially when dealing with errors. People who have tried using BitBlt or SetDIBits knows the horrors of error 87. One of my other favorites in the documentation is: "If the function succeeds, the return value is 1. If the function fails, the return value is 1."
And then other compilers will warn you about "statement has no effect"
Actually, OS/2 implemented it. It could be enabled/disabled per drive, the size of the trashcan could be configured, and it worked even for temporary files made by programs. And yes, it was somewhat slow.
Try "evil empire microsoft" ... www.microsoft.com
The first result on MSN is
Exactly. I can see why the code was split up - to increase reuse. Which is fine if the code you are reusing is of good quality. But the drop-in shadow is drawn as bitmaps, which means that it scales poorly in higher resolutions. It is not that difficult to use PolyLine/PolySegment instead, and the requests are smaller and mostly likely faster. There is not even a single comment line regarding this in the GTK source. So there is room for improvement (and it may have improved in GTK 2 which I have not looked into - yet)
I have looked into this and, yes, there are blatant inefficiencies in GTK. For instance: to draw the simple box with a mark in it for checkboxes, GTK 1.2 uses 6 PutImage operations. Does it cache the result at the server? No, it does it every time it needs to draw the box. It does not even compose the pixmap itself and then uses a single PutImage. The most efficient way of doing it is to compose the pixmap at the server, and the on each Expose event simply do a single CopyArea operation. (backing store would be even better). Looking into the GTK source code shows that this is not a simple thing to remedy. The drop-in shadows of the box is handled by one part of the code, the checkmark by another, and so on.
There are also examples of inefficient resource use. gcolorsel (v1.40) needs a pixmap for each color. 1165 pixmaps. This does not sound as a reasonable requirement to me.
You forget how nvidia and vmware handles this. They provide their drivers as two parts: one binary closed-source part, and one source wrapper. This allows them to provide their driver as binary only, and let the wrapper be compiled to fit the kernel.
And if you are running a well-known kernel then the driver bundle includes the source part precompiled so you do not even need a compiler. NVidia even uses the same binary part for their drivers for windows and linux (ok, possibly compiled with different compilers), so the kernel version cannot really be the issue here.
I assume that Intel and NVidia has different strategies here for driver development. It seems that NVidia has a group developing the common part, and then different groups developing the OS-specific parts. I suspect that Intel is using distinct groups here instead, which means seperate resource allocation. Or maybe network drivers are just so different that Intel cannot make a common part?