4 ms·
For context, note that this site was part of a class project from 2000. Some stuff is still relevant, some not. Other similarly styled informational sites crea
by _delirium 12y ago
For context, note that this site was part of a class project from 2000. Some stuff is still relevant, some not.
Other similarly styled informational sites created by students in this course over the years can be found here: http://cs.stanford.edu/people/eroberts/courses/soco/ http://cs.stanford.edu/people/eroberts/courses/soco/
- jerf 12y agoAll of it is true in the historical sense, virtually none of it is relevant. With the advent of "instruction decoders", everything is RISC on the inside and the "machine code" is now nothing more than another layer of interface. Instruction sets no longer determine internal architecture. And instruction decoders are trivial elements of the overall die. RISC didn't die and CISC didn't die... "RISC vs. CISC" died instead.
- voidlogic 12y agoIn some ways this modern hybrid is better than either. RISC CPUs were almost always internally more efficient due to the simpler decode and easier application of performance tricks; whereas CISC was always better externally as it had better memory/instruction density. So in some ways the CISC on the outside, RISC in the inside approach is the best thing that could have happened for a CISC arch. like x86.
- 1amzave 12y ago> CISC was always better externally ...aside from being orders of magnitude more of an ass-pain if you ever have to write software that actually deals with machine code (at least on x86; perhaps other CISCs aren't as bad). Simple example: given an instruction boundary, find the preceding instruction boundary. On most any RISC it's trivial (subtract 4, or perhaps 2 in some cases). On x86...I'm not an expert, but I'm about 80% confident it's basically impossible to do in the general case.
- voidlogic 12y ago>...aside from being orders of magnitude more of an ass-pain if you ever have to write software that actually deals with machine code 1. I was talking about external as in the memory hierarchy not development effort. >(at least on x86; perhaps other CISCs aren't as bad). This, the PDP-11 machines have a lovely instruction set for example.
- Ded7xSEoPKYNsDd 12y agoThis is certainly impossible on x86 - you can even interleave two different instruction streams (which is mainly used to confuse static analysis tools).
- sliverstorm 12y agoI don't know that I would call the decoder trivial. You can see here in AMD's Bulldozer, it occupies a third of the front end. http://pc.watch.impress.co.jp/img/pcw/docs/430/341/10.jpg http://pc.watch.impress.co.jp/img/pcw/docs/430/341/10.jpg
- zirkonit 12y agoA trip down memory lane. Some of the “hot” technologies took off (CPU architectures, genome computations, ray tracing); some lingered on in the same early 2000s state (genetic algorithms, etc). I, for one, am slightly puzzled why genetic algos never became mainstream in any computational field.
- _delirium 12y agoI don't use them much myself, but genetic algorithms (and "evolutionary computation (EC)" more broadly) have become pretty big in some areas. In AI there seems to be a bit of a geographical tilt, with EC being bigger in Europe and Asia than North America. And in application areas, EC seems to be bigger in areas considered "engineering" rather than "computing" (in terms of publications, IEEE-affiliated rather than ACM-affiliated venues).
- zirkonit 12y agoCurious to know, thanks.
- astrange 12y agoComputer programming is hard enough when you know how the algorithms work, so the idea of genetic programming as "randomly generating program text and mixing them together till it works" is definitely more than anyone wants to deal with. Genetic programming is also a machine learning technique where you generate random answers then mix them together until it increases the fitness function. Since it knows nothing about the actual problem space, it runs very slowly yet doesn't work better than something more sensible like simulated annealing.