3 ms·

I had a TC1000 with the Crusoe. In tasks like web browsing it was quite slow but it was surprisingly performant in games. I remember being shocked that I could

by causi 4y ago

I had a TC1000 with the Crusoe. In tasks like web browsing it was quite slow but it was surprisingly performant in games. I remember being shocked that I could play Star Trek: Bridge Commander with all the settings cranked up.

seunosewa 4y ago
I guess the wide architecture exploited the parallelism of games' graphics rendering code very well, just as GPUs do.
FullyFunctional 4y ago
Given the nature of the JIT and the limited size of the translation cache (2 MiB IIRC), applications with huge code bases and little repeat rate (like browsers and MS Word) will perform less well. The poster child for Crusoe was PowerDVD, but Quake had also gotten a lot of attention. Note, in those days there was a surprising amount of self-modifying code. That stuff is really nasty to deal with for a JIT. There was hardware support for detecting this on (IIRC) a 1 KiB granularity (because code was intermixed with data, making the latter look like self-modifying code).
- Symmetry 4y ago
  When NVidia adopted Transmeta's technology to target ARM instructions with their Project Denver they added a facility to just run native code for bits that weren't hot spots.
  - FullyFunctional 4y ago
    Even though I'm not sure what you mean by "native", this not exactly my understanding. AFAICT, Denver added a hardware Arm instruction decoder. This greatly helps with the first part of the JIT and especially accelerates the interpreter.
  - karteum 4y ago
    https://en.wikipedia.org/wiki/Project_Denver https://en.wikipedia.org/wiki/Project_Denver : "Project Denver was originally intended to support both ARM and x86 code using code morphing technology from Transmeta, but was changed to the ARMv8-A 64-bit instruction set because Nvidia could not obtain a license to Intel's patents"
- rep_lodsb 4y ago
  "Self-modifying code" might be more common today than it was back then, given the popularity of managed languages that also use some type of JIT. Forcing the output of that JIT through another translation step would be really bad for performance. If Transmeta had survived, perhaps they could have added support for different instruction sets to run e.g. Java or .NET "natively".
hedgehog 4y ago
I used a Sony PictureBook for a bit in 2001 running Linux (this exact one: https://www.linuxjournal.com/article/4548 https://www.linuxjournal.com/article/4548) and it was totally fine. Bigger apps like StarOffice were a bit sluggish at start but then be snappy in use. The battery life was really good for the time, I used it as a coffee shop laptop (although that time there were only maybe five coffee shops with wireless in Seattle and I was responsible for three of them). https://en.wikipedia.org/wiki/Sony_Vaio_C1_series https://en.wikipedia.org/wiki/Sony_Vaio_C1_series
- causi 4y ago
  I remember seeing those in Popular Science and lusting after them.

by causi 4y ago

seunosewa 4y ago

I guess the wide architecture exploited the parallelism of games' graphics rendering code very well, just as GPUs do.

FullyFunctional 4y ago

Given the nature of the JIT and the limited size of the translation cache (2 MiB IIRC), applications with huge code bases and little repeat rate (like browsers and MS Word) will perform less well. The poster child for Crusoe was PowerDVD, but Quake had also gotten a lot of attention. Note, in those days there was a surprising amount of self-modifying code. That stuff is really nasty to deal with for a JIT. There was hardware support for detecting this on (IIRC) a 1 KiB granularity (because code was intermixed with data, making the latter look like self-modifying code).

Symmetry 4y ago
When NVidia adopted Transmeta's technology to target ARM instructions with their Project Denver they added a facility to just run native code for bits that weren't hot spots.
- FullyFunctional 4y ago
  Even though I'm not sure what you mean by "native", this not exactly my understanding. AFAICT, Denver added a hardware Arm instruction decoder. This greatly helps with the first part of the JIT and especially accelerates the interpreter.
- karteum 4y ago
  https://en.wikipedia.org/wiki/Project_Denver https://en.wikipedia.org/wiki/Project_Denver : "Project Denver was originally intended to support both ARM and x86 code using code morphing technology from Transmeta, but was changed to the ARMv8-A 64-bit instruction set because Nvidia could not obtain a license to Intel's patents"
rep_lodsb 4y ago
"Self-modifying code" might be more common today than it was back then, given the popularity of managed languages that also use some type of JIT. Forcing the output of that JIT through another translation step would be really bad for performance. If Transmeta had survived, perhaps they could have added support for different instruction sets to run e.g. Java or .NET "natively".

hedgehog 4y ago

I used a Sony PictureBook for a bit in 2001 running Linux (this exact one: https://www.linuxjournal.com/article/4548 https://www.linuxjournal.com/article/4548) and it was totally fine. Bigger apps like StarOffice were a bit sluggish at start but then be snappy in use. The battery life was really good for the time, I used it as a coffee shop laptop (although that time there were only maybe five coffee shops with wireless in Seattle and I was responsible for three of them). https://en.wikipedia.org/wiki/Sony_Vaio_C1_series https://en.wikipedia.org/wiki/Sony_Vaio_C1_series

causi 4y ago
I remember seeing those in Popular Science and lusting after them.