Could the second example be achieved more easily(if not more effectively in all cases) by translating on an instruction-by-instruction basis, then optimizing using whatever normally optimizes the native instruction set?
What do you mean by "whatever normally optimizes the native instruction set"? What normally allows the optimization of assembly is data flow analysis of constructs in the higher-level language being compiled (like C). You can only do limited types of optimization with the raw assembly (peephole). Additionally, we know for a fact that the VLIW/EPIC codes in IA-64 require advanced compilers to produce efficient executable programs.
At the machine code level you have lost all that high level information so it needs to be inferred by profiling and block analysis. I agree with the parent poster on the importance of blocks.
DEC Alpha tried something similiar with their x86 emulation.
I think that's a different situation. For starters, Itanium already does IA32 in hardware (it's just really crappy apparently).
DEC wasn't in the x86 market to start with so FX!32 extended their market by making NT/Alpha more attractive. With the 21164, Alpha introduced data handling functionality in hardware that was intended to accelerate x86 emulation. It was probably too late by then.
There must still be major management/direction problems with the Itanium project for them to resort to this kind of hack. It's embarassing that they can outperform their hardware implementation in software.
The only software emulation I can think of that was successful was Apple's 68k emulation for PPC, but their approach was brilliant and well thought out IMO (smooth transition, fat binaries including code for both chips). At the time, PPC was compelling. I don't think Itanium performance is as compelling even though Itanium 2 is pretty decent from what I've seen. I think for a straight 64 bit Linux system, Itanium 2 is a much better chip.
I suspect Intel and friends (oops almost typed fiends!) will be back with improved hardware support for IA32 because people won't be satisfied with the emulation performance. AMD has to feel pretty good about having Intel/HP in this position.
Don't worry about english. Trying to get people to take you seriously has nothing to do with being able to create simple sentences. After all, why should a published article on a review site have better grammar than a post on slashdot?
SQL server doesn't have platform flexibility. It's the only major RDBMS that doesn't. I'm always going to (personally) prefer systems that aren't tied to one platform. Again, benchmarks are only a very small part of the picture. And the kind of scaling we're talking about here with TPC seems to be CPU scaling, not storage subsystems.
Storage capability seems to be a huge concern when you're talking terabytes. I honestly don't know what the picture looks like. Can I put 8 fibre channel cards in a Windows box? Maybe you can. I'm pretty interested in the Itanium2 architecture. I think it will open up the midrange. Are a lot of big sites running SQL Server? I'm sure they are. The ones at work seem to be smaller data stuff for web applications more than core large multi-terabyte stuff.
I'm sure SQL Server has a lot of features. I'm not an Oracle/DB2/whatever fanboy either; that stuff is expensive to license and difficult to administer. I know that DB2 supports a few options for stored procedures and MS does not. Oracle has very broad platform support and can be tuned extensively. I bet SQL Server is a lot easier to manage though.
I think your manner of singing MS's tune betrays your fanboy disposition. I have no loyalty to any vendor, though you're right that I don't care for Microsoft-only systems.
I didn't mean quality with McDs. I meant calories, i.e. performance. TPM does not measure quality, I assure you. Sorry that was too abstract for you.
No more hamburger metaphors, I just wanted to see some MS fan boy vitriol. Thanks!
Hey, maybe there is more to buying a solution than initial price/performance on a specialized benchmark test. There might be storage issues, cost of ownership, or any number of things that way well be more important in an enterprise.
Of course you can't actually buy the MS stuff until June and even then you'll be running a new hardware platform AND a new software port.
If a position in a benchmark indicates to you anything beyond doing well in one test, like being "extremely capable" I suggest that you have much lower standards for applying that phrase than most people do.
qmail isn't real open source. It has a weird license that doesn't allow you to distribute modified source! postfix or exim are better alternatives for that reason.
I don't understand why anyone would run sendmail as their MTA with all the alternatives. It's insecure by design -- it's a monolithic suid root program. It's inefficient and it's difficult to configure.
You've got the same mindset as all the "experts" that say that Japanese consumers are so far ahead of the USA in technology.
I think smartcards could potentially offer better physical security than credit cards since they can hold cryptographic keys.
So then I get dumped into a group of your invisible monsters? Dude, we are all here, hiding under your bed, pressuring the American public to buy microminiature 3G phone/camera/breadmakers. And yes, they use nonstandard sized batteries. Moohahaha!
Exactly - credit cards have been using the same magnetic strip "technology" since the early 70s.
Japan and Europe have smart cards in wide use, but the U.S. lags. We still manually input name and address information into disparate point of sales systems for every vendor. That's just sad.
It's stupid to have a general purpose XML parser, when you only need a small subset of functionality.
Yeah, the world needs more half-assed barely functioning and noncompliant XML parsers.
Seriously I think it's much more robust to just use a normal XML parser. You get all the character set support. If someone hacked up their own parser at work I would reject it in a code review. There's no sense in maintaining your own XML parser these days; they are a commodity.
In the olden days, Perl 4 didn't let you do complex data structures and Perl 5 added that. Well, it was a big hack job.
I'm thinking about things with references where you have to know the difference between and when to use
percent, precent$, \percent {...}, at{... }, [... ] (sorry - lameness filter isn't letting me put real Perl code, heh heh)
, and so on or the idiotic context sensitive meaning of variables (list vs. scalar) and when you need to use the scalar keyword to override it.
Python doesn't need the equivalent of Tom Christiansen's Perl Data Structures Cookbook / man perldsc because everything's a reference and it's more straightforward.
Perl is, was, and always will be a huge hack and hacks on top of hacks. Why is it so hard to create data structures in Perl? Python is more logical and orthogonal. Ruby is a bastardized Python with a bunch of ugly Perl-like syntax.
Better drives that are designed to run 24/7 with load. The drives usually have lower seek times/lower rotational latency. Some of this comes at the cost of heat and noise which Joe Consumer might not tolerate. Seek times are incredibly underrated, btw. The SCSI interface itself really doesn't have much advantage over ATA, but the industry builds its best drives for SCSI/FCAL.
Firewire (IEEE 1394a/b) really isn't the right technology for disk data transfer. It's an extremely sophisticated interface that has features for synchronizing realtime multimedia stuff. It's also expensive.
Slashdot Mirror
-Kevin
What do you mean by "whatever normally optimizes the native instruction set"? What normally allows the optimization of assembly is data flow analysis of constructs in the higher-level language being compiled (like C). You can only do limited types of optimization with the raw assembly (peephole). Additionally, we know for a fact that the VLIW/EPIC codes in IA-64 require advanced compilers to produce efficient executable programs.
At the machine code level you have lost all that high level information so it needs to be inferred by profiling and block analysis. I agree with the parent poster on the importance of blocks.
-Kevin
I think that's a different situation. For starters, Itanium already does IA32 in hardware (it's just really crappy apparently).
DEC wasn't in the x86 market to start with so FX!32 extended their market by making NT/Alpha more attractive. With the 21164, Alpha introduced data handling functionality in hardware that was intended to accelerate x86 emulation. It was probably too late by then.
There must still be major management/direction problems with the Itanium project for them to resort to this kind of hack. It's embarassing that they can outperform their hardware implementation in software.
The only software emulation I can think of that was successful was Apple's 68k emulation for PPC, but their approach was brilliant and well thought out IMO (smooth transition, fat binaries including code for both chips). At the time, PPC was compelling. I don't think Itanium performance is as compelling even though Itanium 2 is pretty decent from what I've seen. I think for a straight 64 bit Linux system, Itanium 2 is a much better chip.
I suspect Intel and friends (oops almost typed fiends!) will be back with improved hardware support for IA32 because people won't be satisfied with the emulation performance. AMD has to feel pretty good about having Intel/HP in this position.
-Kevin
Don't be such a dick. They're Russian.
-Kevin
I've never seen assembly that's as horrible to read as C++.
Maybe if you look at the bits in the binary form of machine language, and then poke a pencil in your eye at the same time.
-Kevin
Storage capability seems to be a huge concern when you're talking terabytes. I honestly don't know what the picture looks like. Can I put 8 fibre channel cards in a Windows box? Maybe you can. I'm pretty interested in the Itanium2 architecture. I think it will open up the midrange. Are a lot of big sites running SQL Server? I'm sure they are. The ones at work seem to be smaller data stuff for web applications more than core large multi-terabyte stuff.
I'm sure SQL Server has a lot of features. I'm not an Oracle/DB2/whatever fanboy either; that stuff is expensive to license and difficult to administer. I know that DB2 supports a few options for stored procedures and MS does not. Oracle has very broad platform support and can be tuned extensively. I bet SQL Server is a lot easier to manage though.
I think your manner of singing MS's tune betrays your fanboy disposition. I have no loyalty to any vendor, though you're right that I don't care for Microsoft-only systems.
-Kevin
No more hamburger metaphors, I just wanted to see some MS fan boy vitriol. Thanks!
Hey, maybe there is more to buying a solution than initial price/performance on a specialized benchmark test. There might be storage issues, cost of ownership, or any number of things that way well be more important in an enterprise.
Of course you can't actually buy the MS stuff until June and even then you'll be running a new hardware platform AND a new software port.
If a position in a benchmark indicates to you anything beyond doing well in one test, like being "extremely capable" I suggest that you have much lower standards for applying that phrase than most people do.
McDonalds makes hamburgers with the best price/performance. Just something to think about.
-Kevin
qmail isn't real open source. It has a weird license that doesn't allow you to distribute modified source! postfix or exim are better alternatives for that reason.
Why? For the love of SMTP, why??? j/k
-Kevin
Mu is that Greek letter before nu. My evil laugh is Moo-haha, not Mu-haha or Mwah-haha. HTH.
-Kevin
Or worse, if he mixed with you and you turned green.
-Kevin
I think smartcards could potentially offer better physical security than credit cards since they can hold cryptographic keys.
So then I get dumped into a group of your invisible monsters? Dude, we are all here, hiding under your bed, pressuring the American public to buy microminiature 3G phone/camera/breadmakers. And yes, they use nonstandard sized batteries. Moohahaha!
-Kevin
Exactly - credit cards have been using the same magnetic strip "technology" since the early 70s.
Japan and Europe have smart cards in wide use, but the U.S. lags. We still manually input name and address information into disparate point of sales systems for every vendor. That's just sad.
-Kevin
-Kevin
Yeah, the world needs more half-assed barely functioning and noncompliant XML parsers.
Seriously I think it's much more robust to just use a normal XML parser. You get all the character set support. If someone hacked up their own parser at work I would reject it in a code review. There's no sense in maintaining your own XML parser these days; they are a commodity.
-Kevin
-Kevin
I'm thinking about things with references where you have to know the difference between and when to use
, and so on or the idiotic context sensitive meaning of variables (list vs. scalar) and when you need to use the scalar keyword to override it.Python doesn't need the equivalent of Tom Christiansen's Perl Data Structures Cookbook / man perldsc because everything's a reference and it's more straightforward.
-Kevin
-Kevin
-Kevin
-Kevin
Better drives that are designed to run 24/7 with load. The drives usually have lower seek times/lower rotational latency. Some of this comes at the cost of heat and noise which Joe Consumer might not tolerate. Seek times are incredibly underrated, btw. The SCSI interface itself really doesn't have much advantage over ATA, but the industry builds its best drives for SCSI/FCAL.
-Kevin
Most people would kill it from the task manager. My question is, why does stuff hang all the time on Windows in the first place?
-Kevin