セカンド・オピニオンの目次があんまりなのでWeb::Scraperしてみた
use strict; use warnings; use URI; use Web::Scraper; use Encode; my $url = 'http://journal.mycom.co.jp/column/sopinion/index.html'; my $http_proxy = 'http://proxy.hogehoge.com:8080/'; my $scraped = scrape_mycom_links($url, $http_proxy); foreach my $link (@{$scraped}){ my $scraped_column = scrape_mycom_column($link, $http_proxy); my $link_html = "-<a href=\"" . $link . "\">"; $link_html .= encode('euc-jp', $scraped_column->{'subtitle'}) . ": "; $link_html .= encode('euc-jp', $scraped_column->{'articletitle'}); $link_html .= "</a>\n" ; print $link_html; } sub scrape_mycom_links{ my $url = shift; my $http_proxy = shift; my $links = scraper { process 'table.tableStyle01 tr>td>a', 'links[]' => '@href'; result 'links'; }; $links->user_agent->proxy('http', $http_proxy); my $scraped = $links->scrape(URI->new($url)); } sub scrape_mycom_column{ my $url = shift; my $http_proxy = shift; my $titles = scraper { process '#articleMain >h2', 'title' => 'TEXT'; process 'h3.subtitle', 'subtitle' => 'TEXT'; process 'div.articleContent >h3', 'articletitle' => 'TEXT'; process 'div.articleContent >p', 'paragraph' => 'TEXT'; result 'title', 'subtitle', 'articletitle', 'paragraph'; }; $titles->user_agent->proxy('http', $http_proxy); my $scraped = $titles->scrape(URI->new($url)); $scraped->{'articletitle'} = $scraped->{'paragraph'} if not defined $scraped->{'articletitle'}; return($scraped); }
- 234 OS小論:OSの構造をもう少し考えてみる(40): メモリその8
- 233 OS小論:OSの構造をもう少し考えてみる(39): メモリその7
- 232 OS小論:OSの構造をもう少し考えてみる(38): メモリその6
- 231 OS小論:OSの構造をもう少し考えてみる(37): メモリその5
- 230 OS小論:OSの構造をもう少し考えてみる(36): メモリその4
- 229 OS小論:OSの構造をもう少し考えてみる(35): メモリその3
- 228 OS小論:OSの構造をもう少し考えてみる(34): メモリその2
- 227 OS小論:OSの構造をもう少し考えてみる(33): メモリその1
- 226 OS小論:OSの構造をもう少し考えてみる(32): プロセスその22
- 225 OS小論:OSの構造をもう少し考えてみる(31): プロセスその22
- 224 OS小論:OSの構造をもう少し考えてみる(30): プロセスその21
- 223 OS小論:OSの構造をもう少し考えてみる(29): これらの実装に関して詳細が一切無いが、OS小論:OSの構造をもう少し考えてみる(26)で触れた通り、x86系にはLOCK付きの命令を色々発行できるから、これを使ってMutexなりSemaphoreを構築していると想像される。ただ、元々Windowsはマルチプラットフォームを目指していたから、あまり特定のCPUに依存してしまうような複雑な構造はとっていないと思われる。
- 222 OS小論:OSの構造をもう少し考えてみる(28): プロセスその19
- 221 OS小論:OSの構造をもう少し考えてみる(27): プロセスその18
- 220 OS小論:OSの構造をもう少し考えてみる(26): プロセスその17
- 219 OS小論:OSの構造をもう少し考えてみる(25): プロセスその16
- 218 OS小論:OSの構造をもう少し考えてみる(24): プロセスその15
- 217 OS小論:OSの構造をもう少し考えてみる(23): プロセスその14
- 216 OS小論:OSの構造をもう少し考えてみる(22): プロセスその13
- 215 OS小論:OSの構造をもう少し考えてみる(21): プロセスその12
- 214 OS小論:OSの構造をもう少し考えてみる(20): プロセスその11
- 213 OS小論:OSの構造をもう少し考えてみる(19): プロセスその10
- 212 OS小論:OSの構造をもう少し考えてみる(18): プロセスその9
- 211 OS小論:OSの構造をもう少し考えてみる(17): プロセスその8
- 210 OS小論:OSの構造をもう少し考えてみる(16): プロセスその7
- 209 OS小論:OSの構造をもう少し考えてみる(15): プロセスその6
- 208 OS小論:OSの構造をもう少し考えてみる(14): プロセスその5
- 207 OS小論:OSの構造をもう少し考えてみる(13): プロセスその4
- 206 OS小論:OSの構造をもう少し考えてみる(12): プロセスその3
- 205 OS小論:OSの構造をもう少し考えてみる(11): プロセスその2
- 204 OS小論:OSの構造をもう少し考えてみる(10): プロセスその1
- 203 OS小論:OSの構造をもう少し考えてみる(9): デバイスドライバその4
- 202 OS小論:OSの構造をもう少し考えてみる(8): デバイスドライバその3
- 201 OS小論:OSの構造をもう少し考えてみる(7): デバイスドライバその1
- 200 OS小論:OSの構造をもう少し考えてみる(6): Interruptその3
- 199 OS小論:OSの構造をもう少し考えてみる(5): Interruptその2
- 198 OS小論:OSの構造をもう少し考えてみる(4): 4 level privilegeその3
- 197 OS小論:OSの構造をもう少し考えてみる(3): 4 level privilegeその2
- 196 OS小論:OSの構造をもう少し考えてみる(2): 4 level privilege(1)
- 195 OS小論:OSの構造をもう少し考えてみる(1): いい加減ハードウェアの話が続いたので、そろそろソフトウェアの話でも...とか思ったのですが、よく考えたら相変わらずハードウェアの話になりそうな気もします。でも一応建前はソフトウェア。
- 194 Core MicroArchitectureをもうすこし(18): これからのアーキテクチャ(続き)
- 193 Core MicroArchitectureをもうすこし(17): これからのアーキテクチャ(続き)
- 192 Core MicroArchitectureをもうすこし(16): これからのアーキテクチャ(続き)
- 191 Core MicroArchitectureをもうすこし(15): これからのアーキテクチャ(続き)
- 190 Core MicroArchitectureをもうすこし(14): これからのアーキテクチャ(続き)
- 189 Core MicroArchitectureをもうすこし(13): これからのアーキテクチャ
- 188 Core MicroArchitectureをもうすこし(12): Intelが考えるSustained Performance(続き)
- 187 Core MicroArchitectureをもうすこし(11): Intelが考えるSustained Performance(続き)
- 186 Core MicroArchitectureをもうすこし(10): Intelが考えるSustained Performance(続き)
- 185 Core MicroArchitectureをもうすこし(9): Intelが考えるSustained Performance(続き)
- 184 Core MicroArchitectureをもうすこし(8): Intelが考えるSustained Performance(続き)
- 183 Core MicroArchitectureをもうすこし(7): Intelが考えるSustained Performance(続き)
- 182 Core MicroArchitectureをもうすこし(6): Intelが考えるSustained Performance(続き)
- 181 Core MicroArchitectureをもうすこし(5): Intelが考えるSustained Performance(続き)
- 180 Core MicroArchitectureをもうすこし(4): Intelが考えるSustained Performance
- 179 Core MicroArchitectureをもうすこし(3): Sustained Performanceを考える際の条件
- 178 Core MicroArchitectureをもうすこし(2): 問題点への考察
- 177 Core MicroArchitectureをもうすこし(1): 承前
- 176 バスのアーキテクチャ - 過去から未来へ(137): Wrap-Up その4
- 175 バスのアーキテクチャ - 過去から未来へ(136): Wrap-Up その3
- 174 バスのアーキテクチャ - 過去から未来へ(135): Wrap-Up その2
- 173 バスのアーキテクチャ - 過去から未来へ(134): Wrap-Up その1
- 172 バスのアーキテクチャ - 過去から未来へ(133): フィールドバスの色々(その34)ZigBee(その15)
- 171 バスのアーキテクチャ - 過去から未来へ(132): フィールドバスの色々(その33)ZigBee(その14)
- 170 バスのアーキテクチャ - 過去から未来へ(131): フィールドバスの色々(その32)ZigBee(その13)
- 169 バスのアーキテクチャ - 過去から未来へ(130): フィールドバスの色々(その31)ZigBee(その12)
- 168 バスのアーキテクチャ - 過去から未来へ(129): フィールドバスの色々(その30)ZigBee(その11)
- 167 バスのアーキテクチャ - 過去から未来へ(128): フィールドバスの色々(その29)ZigBee(その10)
- 166 バスのアーキテクチャ - 過去から未来へ(127): フィールドバスの色々(その28)ZigBee(その9)
- 165 バスのアーキテクチャ - 過去から未来へ(126): フィールドバスの色々(その27)ZigBee(その8)
- 164 バスのアーキテクチャ - 過去から未来へ(125): フィールドバスの色々(その26)ZigBee(その7)
- 163 バスのアーキテクチャ - 過去から未来へ(124): フィールドバスの色々(その25)ZigBee(その6)
- 162 バスのアーキテクチャ - 過去から未来へ(123): フィールドバスの色々(その24)ZigBee(その5)
- 161 バスのアーキテクチャ - 過去から未来へ(122): フィールドバスの色々(その23)ZigBee(その4)
- 160 バスのアーキテクチャ - 過去から未来へ(121): フィールドバスの色々(その22)ZigBee(その3)
- 159 バスのアーキテクチャ - 過去から未来へ(120): フィールドバスの色々(その21)ZigBee(その2)
- 158 バスのアーキテクチャ - 過去から未来へ(119): フィールドバスの色々(その20)ZigBee(その1)
- 157 バスのアーキテクチャ - 過去から未来へ(118): フィールドバスの色々(その19)FlexRay(その11)
- 156 バスのアーキテクチャ - 過去から未来へ(117): フィールドバスの色々(その18)FlexRay(その10)
- 155 バスのアーキテクチャ - 過去から未来へ(116): フィールドバスの色々(その17)FlexRay(その9)
- 154 バスのアーキテクチャ - 過去から未来へ(115): フィールドバスの色々(その16)FlexRay(その8)
- 153 バスのアーキテクチャ - 過去から未来へ(114): フィールドバスの色々(その15)FlexRay(その7)
- 152 バスのアーキテクチャ - 過去から未来へ(113): フィールドバスの色々(その14)FlexRay(その6)
- 151 バスのアーキテクチャ - 過去から未来へ(112): フィールドバスの色々(その13)FlexRay(その5)
- 150 バスのアーキテクチャ - 過去から未来へ(111): フィールドバスの色々(その12)FlexRay(その4)
- 149 バスのアーキテクチャ - 過去から未来へ(110): フィールドバスの色々(その11)FlexRay(その3)
- 148 バスのアーキテクチャ - 過去から未来へ(109): フィールドバスの色々(その10)FlexRay(その2)
- 147 バスのアーキテクチャ - 過去から未来へ(108): フィールドバスの色々(その9)FlexRay(その1)
- 146 バスのアーキテクチャ - 過去から未来へ(107): フィールドバスの色々(その8)CAN(その7)
- 145 バスのアーキテクチャ - 過去から未来へ(106): フィールドバスの色々(その7)CAN(その6)
- 144 バスのアーキテクチャ - 過去から未来へ(105): フィールドバスの色々(その6)CAN(その5)
- 143 バスのアーキテクチャ - 過去から未来へ(104): フィールドバスの色々(その5)CAN(その4)
- 142 バスのアーキテクチャ - 過去から未来へ(103): フィールドバスの色々(その4)CAN(その3)
- 141 バスのアーキテクチャ - 過去から未来へ(102): フィールドバスの色々(その3)CAN(その2)
- 140 バスのアーキテクチャ - 過去から未来へ(101): フィールドバスの色々(その2)CAN(その1)
- 139 バスのアーキテクチャ - 過去から未来へ(100): フィールドバスの色々(その1)
- 138 バスのアーキテクチャ - 過去から未来へ(99): シンプルなバス(その17):SMBus(その5)
- 137 バスのアーキテクチャ - 過去から未来へ(98): シンプルなバス(その16):SMBus(その4)
- 136 バスのアーキテクチャ - 過去から未来へ(97): シンプルなバス(その15):SMBus(その3)
- 135 バスのアーキテクチャ - 過去から未来へ(96): シンプルなバス(その14):SMBus(その2)
- 134 バスのアーキテクチャ - 過去から未来へ(95): シンプルなバス(その13):SMBus(その1)
- 133 バスのアーキテクチャ - 過去から未来へ(94): シンプルなバス(その12):I2C(その5)
- 132 バスのアーキテクチャ - 過去から未来へ(93): シンプルなバス(その11):I2C(その4)
- 131 バスのアーキテクチャ - 過去から未来へ(92): シンプルなバス(その10):I2C(その3)
- 130 バスのアーキテクチャ - 過去から未来へ(91): シンプルなバス(その9):I2C(その2)
- 129 バスのアーキテクチャ - 過去から未来へ(90): シンプルなバス(その8):I2C(その1)
- 128 バスのアーキテクチャ - 過去から未来へ(89): シンプルなバス(その7):SPI(その3)
- 127 バスのアーキテクチャ - 過去から未来へ(88): シンプルなバス(その6):SPI(その2)
- 126 バスのアーキテクチャ - 過去から未来へ(87): シンプルなバス(その5):SPI(その1)
- 125 バスのアーキテクチャ - 過去から未来へ(86): シンプルなバス(その4):LPC(その4)
- 124 バスのアーキテクチャ - 過去から未来へ(85): シンプルなバス(その3):LPC(その3)
- 123 バスのアーキテクチャ - 過去から未来へ(84): シンプルなバス(その2):LPC(その2)
- 122 バスのアーキテクチャ - 過去から未来へ(83): シンプルなバス(その1):LPC(その1)
- 121 バスのアーキテクチャ - 過去から未来へ(82): プロトコル(その47):PCI Express(その25)
- 120 バスのアーキテクチャ - 過去から未来へ(81): プロトコル(その46):PCI Express(その24)
- 119 バスのアーキテクチャ - 過去から未来へ(80): プロトコル(その45):PCI-Express(その23)
- 118 バスのアーキテクチャ - 過去から未来へ(79): プロトコル(その44):PCI-Express(その22)
- 117 バスのアーキテクチャ - 過去から未来へ(78): プロトコル(その43):PCI-Express(その21)
- 116 バスのアーキテクチャ - 過去から未来へ(77): プロトコル(その42):PCI-Express(その20)
- 115 バスのアーキテクチャ - 過去から未来へ(76): プロトコル(その41):PCI-Express(その19)
- 114 バスのアーキテクチャ - 過去から未来へ(75): プロトコル(その40):PCI-Express(その18)
- 113 バスのアーキテクチャ - 過去から未来へ(74): プロトコル(その39):PCI-Express(その17)
- 112 バスのアーキテクチャ - 過去から未来へ(73): プロトコル(その8):PCI-Express(その16)
- 111 バスのアーキテクチャ - 過去から未来へ(72): プロトコル(その7):PCI-Express(その15)
- 110 バスのアーキテクチャ - 過去から未来へ(71): プロトコル(その6):PCI-Express(その14)
- 109 バスのアーキテクチャ - 過去から未来へ(70): プロトコル(その5):PCI-Express(その13)
- 108 バスのアーキテクチャ - 過去から未来へ(69): プロトコル(その4):PCI-Express(その12)
- 107 バスのアーキテクチャ - 過去から未来へ(68): プロトコル(その3):PCI-Express(その11)
- 106 バスのアーキテクチャ - 過去から未来へ(67): プロトコル(その32):PCI-Express(その10)
- 105 バスのアーキテクチャ - 過去から未来へ(66): プロトコル(その31):PCI-Express(その9)
- 104 バスのアーキテクチャ - 過去から未来へ(65): プロトコル(その30):PCI-Express(その8)
- 103 バスのアーキテクチャ - 過去から未来へ(64): プロトコル(その29):PCI-Express(その7)
- 102 バスのアーキテクチャ - 過去から未来へ(63): プロトコル(その28):PCI-Express(その6)
- 101 バスのアーキテクチャ - 過去から未来へ(62): プロトコル(その27):PCI-Express(その5)
- 100 バスのアーキテクチャ - 過去から未来へ(61): プロトコル(その26):PCI-Express(その4)
- 99 バスのアーキテクチャ - 過去から未来へ(60): プロトコル(その25):PCI-Express(その3)
- 98 バスのアーキテクチャ - 過去から未来へ(59): プロトコル(その24):PCI-Express(その2)
- 97 バスのアーキテクチャ - 過去から未来へ(58): プロトコル(その23):PCI Express(その1)
- 96 バスのアーキテクチャ - 過去から未来へ(57): プロトコル(その22):HyperTransport Link(その8)
- 95 バスのアーキテクチャ - 過去から未来へ(56): プロトコル(その21):HyperTransport Link(その7)
- 94 バスのアーキテクチャ - 過去から未来へ(55): プロトコル(その20):HyperTransport Link(その6)
- 93 バスのアーキテクチャ - 過去から未来へ(54): プロトコル(その19):HyperTransport Link(その5)
- 92 バスのアーキテクチャ - 過去から未来へ(53): プロトコル(その18):HyperTransport Link(その4)
- 91 バスのアーキテクチャ - 過去から未来へ(52): プロトコル(その17):HyperTransport Link(その3)
- 90 バスのアーキテクチャ - 過去から未来へ(51): プロトコル(その16):HyperTransport Link(その2)
- 89 バスのアーキテクチャ - 過去から未来へ(50): プロトコル(その15):HyperTransport Link(その1)
- 88 バスのアーキテクチャ - 過去から未来へ(49): プロトコル(その14):Network(その7)
- 87 バスのアーキテクチャ - 過去から未来へ(48): プロトコル(その13):Network(その6)
- 86 バスのアーキテクチャ - 過去から未来へ(47): プロトコル(その12):Network(その5)
- 85 バスのアーキテクチャ - 過去から未来へ(46): プロトコル(その11):Network(その4)
- 84 バスのアーキテクチャ - 過去から未来へ(45): プロトコル(その10):Network(その3)
- 83 バスのアーキテクチャ - 過去から未来へ(44): プロトコル(その9):Network(その2)
- 82 バスのアーキテクチャ - 過去から未来へ(43): プロトコル(その8):Network(その1)
- 81 バスのアーキテクチャ - 過去から未来へ(42): プロトコル(その7):DRAMインタフェース(その4)
- 80 バスのアーキテクチャ - 過去から未来へ(41): プロトコル(その6):DRAMインタフェース(その3)
- 79 バスのアーキテクチャ - 過去から未来へ(40): プロトコル(その5):DRAMインタフェース(その2)
- 78 バスのアーキテクチャ - 過去から未来へ(39): プロトコル(その4):DRAMインタフェース(その1)
- 77 バスのアーキテクチャ - 過去から未来へ(38): プロトコル(その3):IEEE-488の実装(その2)
- 76 バスのアーキテクチャ - 過去から未来へ(37): プロトコル(その2):IEEE-488の実装(その1)
- 75 バスのアーキテクチャ - 過去から未来へ(36): プロトコル(その1)
- 74 バスのアーキテクチャ - 過去から未来へ(35): Plug & Play(その10)
- 73 バスのアーキテクチャ - 過去から未来へ(34): Plug & Play(その9)
- 72 バスのアーキテクチャ - 過去から未来へ(33): Plug & Play(その8)
- 71 バスのアーキテクチャ - 過去から未来へ(32): Plug & Play(その7)
- 70 バスのアーキテクチャ - 過去から未来へ(31): Plug & Play(その6)
- 69 バスのアーキテクチャ - 過去から未来へ(30): Plug & Play(その5)
- 68 バスのアーキテクチャ - 過去から未来へ(29): Plug & Play(その4)
- 67 バスのアーキテクチャ - 過去から未来へ(28): Plug & Play(その3)
- 66 バスのアーキテクチャ - 過去から未来へ(27): Plug & Play(その2)
- 65 バスのアーキテクチャ - 過去から未来へ(26): Plug & Play(その1)
- 64 バスのアーキテクチャ - 過去から未来へ(25): Intermission(3)
- 63 バスのアーキテクチャ - 過去から未来へ(24): Intermission(2)
- 62 バスのアーキテクチャ - 過去から未来へ(23): Intermission(1)
- 61 バスのアーキテクチャ - 過去から未来へ(22): Ethernetのケーススタディ(3)
- 60 バスのアーキテクチャ - 過去から未来へ(21): Ethernetのケーススタディ(2)
- 59 バスのアーキテクチャ - 過去から未来へ(20): ○Ethernetのケーススタディ(1)
- 58 バスのアーキテクチャ - 過去から未来へ(19): ○シェアードバスのアーキテクチャ(7)
- 57 バスのアーキテクチャ - 過去から未来へ(18): ○シェアードバスのアーキテクチャ(6)
- 56 バスのアーキテクチャ - 過去から未来へ(17): ○シェアードバスのアーキテクチャ(5)
- 55 バスのアーキテクチャ - 過去から未来へ(16): ○シェアードバスのアーキテクチャ(4)
- 54 バスのアーキテクチャ - 過去から未来へ(15): ○シェアードバスのアーキテクチャ(3)
- 53 バスのアーキテクチャ - 過去から未来へ(14): ○シェアードバスのアーキテクチャ(2)
- 52 バスのアーキテクチャ - 過去から未来へ(13): ○シェアードバスのアーキテクチャ(1)
- 51 バスのアーキテクチャ - 過去から未来へ(12): ○もっと先になると?
- 50 バスのアーキテクチャ - 過去から未来へ(11): ○シリアルから再びパラレルへ?
- 49 バスのアーキテクチャ - 過去から未来へ(10): ○複数リンクの場合
- 48 バスのアーキテクチャ - 過去から未来へ(9): ○RaSerの基本的な仕組み
- 47 バスのアーキテクチャ - 過去から未来へ(8): ○HyperTransportの限界とPCI Expressへの道筋
- 46 バスのアーキテクチャ - 過去から未来へ(7): ○速度向上のための2つの方法 その2:Uni-Directional
- 45 バスのアーキテクチャ - 過去から未来へ(6): ○速度向上のための2つの方法その1:LVDS
- 44 バスのアーキテクチャ - 過去から未来へ(5): ○等長配線の困難さ
- 43 バスのアーキテクチャ - 過去から未来へ(4): ○Shared Clockと配線遅延
- 42 バスのアーキテクチャ - 過去から未来へ(3): さて、パラレルバスの弊害とは何かについて今回は述べてみたい。
- 41 バスのアーキテクチャ - 過去から未来へ(2): ○SerialとParallel
- 40 バスのアーキテクチャ - 過去から未来へ(1): ○承前 - 打ち合わせってのはこんなもんです
- 39 NuCORE Image Processor - Embedded Processorの一断層(8): ○NuCoreはどこに行くか?
- 38 NuCORE Image Processor - Embedded Processorの一断層(7): ○キーワードは「製品ターゲットの絞込み」
- 37 NuCORE Image Processor - Embedded Processorの一断層(6): ○デジタルバックエンドの目的
- 36 NuCORE Image Processor - Embedded Processorの一断層(5): ○デジタルバックエンド - ある種のDSP
- 35 NuCORE Image Processor - Embedded Processorの一断層(4): ○クロストークの削減 〜特徴的なアナログアンプ〜
- 34 NuCORE Image Processor - Embedded Processorの一断層(3): ○デジタル化によるノイズの削減 〜アナログフロントエンドの導入〜
- 33 NuCORE Image Processor - Embedded Processorの一断層(2): ○CCD映像のノイズ
- 32 NuCORE Image Processor - Embedded Processorの一断層(1): このところ、Pentium 4だAthlon XPだGeForce FXだRADEONだとPC系メインストリーム系の話題が多く続いた業界であるが、その陰で非PC系も色々と進化を遂げている。例えば家庭用ルーター向けには、BRECISのMSP2000がかなりのシェアを持っているところに、IntelのIXP42xシリーズが参入、性能ではほぼ互角の争いになってきている。ここに最近、Ubicomが独自のSoftware I/Oなるコンセプトを持つネットワークプロセッサを引っ提げて争いに参入しつつある。勿論、従来からこの分野で大きなシェアを持っていたARM/MIPS系プロセッサも引き続きこのマーケットにフォーカスしているため、傍から見ている分には実に楽しいというか興味深い状況になりつつある(当事者にとっては洒落にならないキツい争いな訳だが)。もっとも、直接ユーザーが触る事が出来ないという意味ではやはりマイナーなジャンルの話ではある。
- 31 パーソナルな64bit環境はいつ手に入る?: という訳で、30回以上にも及んでしまった64bitプロセッサに関する話題(当初は、こんなに長くなる予定は無かった)も、今回で一区切りである。
- 30 64bit Rhapsody 新しい地平を切り開くItanium(10): ○これからのItanium
- 29 64bit Rhapsody 新しい地平を切り開くItanium(9): ○Itaniumの誤算(4)
- 28 64bit Rhapsody 新しい地平を切り開くItanium(8): ○Itaniumの誤算(3)
- 27 64bit Rhapsody 新しい地平を切り開くItanium(7): ○Itaniumの誤算(2)
- 26 64bit Rhapsody 新しい地平を切り開くItanium(6): ○Itaniumの誤算(1)
- 25 64bit Rhapsody 新しい地平を切り開くItanium(5): ○効率向上のためのQuantum Leap(4)
- 24 64bit Rhapsody 新しい地平を切り開くItanium(4): ○効率向上のためのQuantum Leap(3)
- 23 64bit Rhapsody 新しい地平を切り開くItanium(3): ○効率向上のためのQuantum Leap(2)
- 22 64bit Rhapsody 新しい地平を切り開くItanium(2): ○効率向上のためのQuantum Leap
- 21 64bit Rhapsody 新しい地平を切り開くItanium(1): ○既存プロセッサの限界
- 20 64bit Rhapsody OSを持たないハードウェアの悲劇(4): ○Intel/AMDのアドバンテージ、Microsoftのディスアドバンテージ(2)
- 19 64bit Rhapsody OSを持たないハードウェアの悲劇(3): ○Intel/AMDのアドバンテージ、Microsoftのディスアドバンテージ
- 18 64bit Rhapsody OSを持たないハードウェアの悲劇(2): ○Microsoftの考えるOSのあり方
- 17 64bit Rhapsody OSを持たないハードウェアの悲劇: ○なんでAMDとIntelだけが苦戦するか
- 16 64bit Rhapsody IA-32とYamhill(5): ○LaGrandeに必要とされるアドレス管理体系(2)
- 15 64bit Rhapsody IA-32とYamhill(4): ○LaGrandeに必要とされるアドレス管理体系
- 14 64bit Rhapsody IA-32とYamhill(3): ○Yamhill=RISC+MMX/SSE/SSE2?
- 13 64bit Rhapsody IA-32とYamhill(2): ○新しい32bitプロセッサの必要性
- 12 64bit Rhapsody IA-32とYamhill(1): ○Yamhillというまぼろし
- 11 64bit Rhapsody Hammerの理想と現実(7): 前回( http://pcweb.mycom.co.jp/column/sopinion/sopinion010.html )、コンシューママーケットに64bitが必要であるかについて、AMDとIntel、両社からのコメントを紹介したわけだが、ではこれをどう評価するか。Gelsinger、Meretsky両氏の返事と比較してみると、論点が微妙にずれているところが面白い。Gelsinger氏は現在の技術をベースに、あくまで近未来の範疇で64bit化が必要かどうか、を論じている。これに対しMeretsky氏は、64bitプラットフォームが現実のものになっていることを前提に、将来どんな可能性がありえるかを論じたものである。つまり近未来の範疇では、やはり64bitの必要性が無い事を明らかにしているとも言える。
- 10 64bit Rhapsody Hammerの理想と現実(6): ちょっとここで話題を変えて、Hammerの64bitアドレッシングが、コンシューマデスクトップマーケットにどう影響するか、を考察してみたい。この連載の第2回でも触れたとおり、エンタープライズ向けでもない限りまず64bitアドレッシングは不要な訳だが、にも関わらずAMDは64bitプラットフォームをコンシューマのデスクトップ向けに展開しようとしている。ついでに言えば、IBMもPowerPC 970という64bitプロセッサをやはりデスクトップ向けに準備しており、図らずしも2つのデスクトップマーケット(WindowsとMacintosh)の両方で、64bit環境が使えることになってしまいそうだ。
- 9 64bit Rhapsody Hammerの理想と現実(5): 前回( http://pcweb.mycom.co.jp/column/sopinion/sopinion008.html )、Hammerのハードウェア的なメリットについて述べた訳だが、当然メリットだけしかないということではなく、問題もある。
- 8 64bit Rhapsody Hammerの理想と現実(4): 前回までは、Hammerをめぐるソフトウェア環境についてまとめてきたが、今度はちょっとハードウェアの面から見てみたい。
- 7 64bit Rhapsody Hammerの理想と現実(3): 前回までは、Hammerが64bitをサポートすることによるメリットを享受するのは誰か? という話をした訳だが( http://pcweb.mycom.co.jp/column/sopinion/sopinion006.html )、最大のメリットを享受するのは、何のことはないAMD自身である。通常、プロセッサベンダーは新しいアーキテクチャを持つCPUを開発する場合、それをサポートする開発キットを一式用意することを求められる。例えばIntelはIntel C/C++/FortranといったコンパイラとVTuneと呼ばれる開発キット、IPP(Intel Performance Primitive)と呼ばれるライブラリを提供しており、SSE/SSE2といった特殊命令はこれらを使う事で利用できるようになるという訳だ。サードパーティ任せにすると、当然ながらその普及は遅くなるのが常で、下手をすると全く普及せずに終わることすら考えられる。で、問題はAMDである。
- 6 64bit Rhapsody Hammerの理想と現実(2): AMDはx86-64を採用したことでx86の持つ非効率性をそのまま64bit環境まで引き継ぐことになってしまったことについては前回( http://pcweb.mycom.co.jp/column/sopinion/sopinion005.html )述べたとおりだが、このあたりはAMDも良く理解しているようだ。AMDはABI(Application Binary Interface)の説明の中で「Hammerで浮動小数点演算を行う場合、FPUを使わずにSSE/SSE2を使うことを推奨する」としており、これによりFPUの面倒なスタック操作やレジスタ操作を省く事を狙っているようだが、純粋に演算に関しては代替できても条件分岐やIEEE-754互換の80bit浮動小数点演算はSSE/SSE2でこなせないから、依然として非効率性はついて回ることになる。
- 5 64bit Rhapsody Hammerの理想と現実(1): ○Hammerが64bitをサポートした理由
- 4 64bit Rhapsody それでもある64bitの需要(2): ○64bitプロセッサに求められる資質
- 3 64bit Rhapsody それでもある64bitの需要(1): 前回、64bit CPUには結構無駄が多いという話をしたが、にも関わらず世の中に64bitプロセッサは数多い。例えばIBMのPowerプロセッサ(Macintoshに使われているPowerPCのもとになったもの)やSunMicrosystemsのSPARC、旧DEC(現COMPAQ→HP)のAlphaプロセッサなどはいずれも64bit化が完了しているし、HPのPA-RISCもとっくに64bit化されている。IntelもItaniumという64bitプロセッサを持っている。組み込み系でもMIPS64というアーキテクチャがあるし、といった具合に、市場を見渡すと割と多く存在しているのである。
- 2 64bit Rhapsody 一人歩きする64bit(2): ○アドレスサイズの落とし穴
- 1 64bit Rhapsody 一人歩きする64bit(1): 最近、妙に64bitプロセッサが盛り上がっている。理由は簡単、AMDのHammerプロセッサである。AMD AthlonとAMD Opteronという2つのブランドに分けて販売されるHammerプロセッサは、x86-64という新しい命令セットを搭載し、これが名前の通りx86に下位互換を保ちながら命令セットを64bit化したため、「デスクトップで64bitプロセッサ」とかいう話でいきなり盛り上がってしまったのである。しかし、64bitがそんなに素晴らしいのだろうか?