What are the possibilities for Apple Silicon?

[senttoschool]

Here are some ideas:

• Make a $750 Macbook SE that doesn't suck
• Create Apple Cloud
• Big push for AAA gaming
• Make an Apple Console to compete with Playstation and Xbox or Switch

 

[Sullivan0930]

Neural implant. i want to be the apple.

 

[pshufd]

I'd like to see more software in Silicon. Perhaps put a standard and flexible text editor in silicon that programs can call so that setting up a text window for edit uses less power and runs faster. Basically look at feedback from programs that people use and add silicon and/or instructions to make these operations faster and use less power. Some of these things could be figured out by the compiler and some would require coding. AfterBurner is a big example of this.

 

[Gnattu]

Perhaps put a standard and flexible text editor in silicon that programs can call so that setting up a text window for edit uses less power and runs faster.

This is extremely hard to implement with hardware logic and there could be little benefit by doing so. Text processing, even plain text processing, is much more complex than lot of people thinking it is.

 

[pshufd]

This is extremely hard to implement with hardware logic and there could be little benefit by doing so. Text processing, even plain text processing, is much more complex than lot of people thinking it is.

One of the assignments in a CS course that I took in the 1970s had this as the assignment. I'd say that putting the equivalent of AfterBurner is not easy to do. I've looked at Genetic processing and the current pipelines to do the analysis are heavily based on branchy code. Could you come up with something in silicon to speed up that work? Perhaps a text management framework - certainly not easy to do but Apple seems to have done a pretty good job at doing hard and complex lately.

And even if you can't do it in a Macro sense, could you come with with instructions or APIs to more efficiently manage text management?

 

[Gnattu]

One of the assignments in a CS course that I took in the 1970s had this as the assignment. I'd say that putting the equivalent of AfterBurner is not easy to do. I've looked at Genetic processing and the current pipelines to do the analysis are heavily based on branchy code. Could you come up with something in silicon to speed up that work? Perhaps a text management framework - certainly not easy to do but Apple seems to have done a pretty good job at doing hard and complex lately.

And even if you can't do it in a Macro sense, could you come with with instructions or APIs to more efficiently manage text management?

One big problem is that we are having a big character set on modern computer systems, the logic could be simpler if we only need to support 256 ASCII characters. However on a modern system, we have to support more than one million characters. To build up a encoding lookup table that huge on hardware in not cost effective. On early days the basic display hardware for terminals are actually doing something like this, they store a looking table for the fonts of each character that it can display, and print that font onto the screen, and we call such display mode Text mode. In this mode the screen is divided into multiple grids, each grid is a character cell which can display a character. Terminal emulators (like the one come with macOS) are actually emulating the behavior of such hardware, that why it is called an "emulator". In the old days the character sets are small and the fonts are ugly(bitmaps with only a few pixels). Nowadays we have to display multiple languages, support beautiful fonts, even displaying emojis, and we have powerful CPUs, so just implement it in software will be a more viable solution.

Hardware logics usually have large benefits when the workload has constantly huge dataflow and been quite computational complex. CPUs on most computers struggles on the task which is both IO intensive and computational intensive.

 

[pshufd]

One big problem is that we are having a big character set on modern computer systems, the logic could be simpler if we only need to support 256 ASCII characters. However on a modern system, we have to support more than one million characters. To build up a encoding lookup table that huge on hardware in not cost effective. On early days the basic display hardware for terminals are actually doing something like this, they store a looking table for the fonts of each character that it can display, and print that font onto the screen, and we call such display mode Text mode. In this mode the screen is divided into multiple grids, each grid is a character cell which can display a character. Terminal emulators (like the one come with macOS) are actually emulating the behavior of such hardware, that why it is called an "emulator". In the old days the character sets are small and the fonts are ugly(bitmaps with only a few pixels). Nowadays we have to display multiple languages, support beautiful fonts, even displaying emojis, and we have powerful CPUs, so just implement it in software will be a more viable solution.

Hardware logics usually have large benefits when the workload has constantly huge dataflow and been quite computational complex. CPUs on most computers struggles on the task which is both IO intensive and computational intensive.

I had to do some work on character set translation on the Oracle Codebase a long time ago and the code was a seriously huge mess. So I can see that. But surely there are operations which could be improved with custom silicon.

One thing that I'd love is Huffman Encoding and Decoding in hardware to speed up JPEG processing. Most of the rest of JPEG processing has been parallelized with SIMD code but very hard to do with Huffman.

 

[Gnattu]

I had to do some work on character set translation on the Oracle Codebase a long time ago and the code was a seriously huge mess. So I can see that. But surely there are operations which could be improved with custom silicon.

Yes it is. It is hard to provide a (modern) editor that works from input capture to result display, but we can still optimize a lot of operations, and you may not even need extra silicon as lots of string operations can be optimized with SIMD instructions, like copy and sub-string searching. An SIMD optimized substring searching algorithm could be more than 10 times faster than the un-optimized strstr C function on an aarch64 system.

One thing that I'd love is Huffman Encoding and Decoding in hardware to speed up JPEG processing. Most of the rest of JPEG processing has been parallelized with SIMD code but very hard to do with Huffman.

This could be a good one. Image processing usually benefits from hardware acceleration a lot.

 

[JMacHack]

In order

1. Redundant compared to refurb MacBook Air

2. iCloud exists

3. Will happen the year of the Linux desktop

4. Laughable