История изменений
Исправление MOPKOBKA, (текущая версия) :
я меня плохая память на имена. зато хорошая на красивые решения. тебе показали решение. по решению возражения есть?
Такой реализации нету (используемой, разве что студент написал), потому что она была бы невыносимо медленной. Это вообще традиция реализовывать отдельно массивы в lisp, как я уже писал, они были даже в перволиспе. Строки тоже идут отдельно.
еще раз. лисп машина может быть реализована просто и эффективно и по использованию памяти и по кеш хитам.
Нет, из за того что ты не можешь обращаться к cons внутри списка или графа за разумное время, никакой речи про кеши итд вести нельзя, сначала нужно что бы они не сливали В 7_406_000 РАЗ. Никакое уплотнение не спасет лисп. Нужна оптимизация на представление cons-списков в виде массива, и alist в виде хеш-таблицы, и много чего еще. Тогда у него будет возможность потягаться с реальными языками программирования, такими как Python, JS.
потому что, если данные сложной семантики и требуют сложной обработки - то придется реализовывать эти самые списки, графы, сборки мусора и проч.
В моем посте, даже наивная реализация с realloc на каждые 8 байтов обгоняет Lisp В 7_406_000 РАЗ. Заканчивай с этими сказками.
Даже если мы будем вставлять элементы в случайные позиции, моя наивная реализация на С выиграет.
Исправление MOPKOBKA, :
я меня плохая память на имена. зато хорошая на красивые решения. тебе показали решение. по решению возражения есть?
Такой реализации нету (используемой, разве что студент написал), потому что она была бы невыносимо медленной. Это вообще традиция реализовывать отдельно массивы в lisp, как я уже писал, они были даже в перволиспе. Строки тоже идут отдельно.
еще раз. лисп машина может быть реализована просто и эффективно и по использованию памяти и по кеш хитам.
Нет, из за того что ты не можешь обращаться к cons внутри списка или графа за разумное время, никакой речи про кеши итд вести нельзя, сначала нужно что бы они не сливали В 7_406_000 РАЗ. Никакое уплотнение не спасет лисп. Нужна оптимизация на представление cons-списков в виде массива, и alist в виде хеш-таблицы, и много чего еще. Тогда у него будет возможность потягаться с реальными языками программирования, такими как Python, JS.
потому что, если данные сложной семантики и требуют сложной обработки - то придется реализовывать эти самые списки, графы, сборки мусора и проч.
В моем посте, даже наивная реализация с realloc на каждые 8 байтов обгоняет Lisp В 7_406_000 РАЗ. Заканчивай с этими сказками.
Исправление MOPKOBKA, :
я меня плохая память на имена. зато хорошая на красивые решения. тебе показали решение. по решению возражения есть?
Такой реализации нету (используемой), потому что она была бы невыносимо медленной. Это вообще традиция реализовывать отдельно массивы в lisp, как я уже писал, они были даже в перволиспе. Строки тоже идут отдельно.
еще раз. лисп машина может быть реализована просто и эффективно и по использованию памяти и по кеш хитам.
Нет, из за того что ты не можешь обращаться к cons внутри списка или графа за разумное время, никакой речи про кеши итд вести нельзя, сначала нужно что бы они не сливали В 7_406_000 РАЗ. Никакое уплотнение не спасет лисп. Нужна оптимизация на представление cons-списков в виде массива, и alist в виде хеш-таблицы, и много чего еще. Тогда у него будет возможность потягаться с реальными языками программирования, такими как Python, JS.
потому что, если данные сложной семантики и требуют сложной обработки - то придется реализовывать эти самые списки, графы, сборки мусора и проч.
В моем посте, даже наивная реализация с realloc на каждые 8 байтов обгоняет Lisp В 7_406_000 РАЗ. Заканчивай с этими сказками.
Исправление MOPKOBKA, :
я меня плохая память на имена. зато хорошая на красивые решения. тебе показали решение. по решению возражения есть?
Такой реализации нету, потому что она была бы невыносимо медленной. Это вообще традиция реализовывать отдельно массивы в lisp, как я уже писал, они были даже в перволиспе. Строки тоже идут отдельно.
еще раз. лисп машина может быть реализована просто и эффективно и по использованию памяти и по кеш хитам.
Нет, из за того что ты не можешь обращаться к cons внутри списка или графа за разумное время, никакой речи про кеши итд вести нельзя, сначала нужно что бы они не сливали В 7_406_000 РАЗ. Никакое уплотнение не спасет лисп. Нужна оптимизация на представление cons-списков в виде массива, и alist в виде хеш-таблицы, и много чего еще. Тогда у него будет возможность потягаться с реальными языками программирования, такими как Python, JS.
потому что, если данные сложной семантики и требуют сложной обработки - то придется реализовывать эти самые списки, графы, сборки мусора и проч.
В моем посте, даже наивная реализация с realloc на каждые 8 байтов обгоняет Lisp В 7_406_000 РАЗ. Заканчивай с этими сказками.
Исходная версия MOPKOBKA, :
я меня плохая память на имена. зато хорошая на красивые решения. тебе показали решение. по решению возражения есть?
Такой реализации нету, потому что она была бы невыносимо медленной. Это вообще традиция реализовывать отдельно массивы в lisp, как я уже писал, они были даже в перволиспе.
еще раз. лисп машина может быть реализована просто и эффективно и по использованию памяти и по кеш хитам.
Нет, из за того что ты не можешь обращаться к cons внутри списка или графа за разумное время, никакой речи про кеши итд вести нельзя, сначала нужно что бы они не сливали В 7_406_000 РАЗ. Никакое уплотнение не спасет лисп. Нужна оптимизация на представление cons-списков в виде массива, и alist в виде хеш-таблицы, и много чего еще. Тогда у него будет возможность потягаться с реальными языками программирования, такими как Python, JS.
потому что, если данные сложной семантики и требуют сложной обработки - то придется реализовывать эти самые списки, графы, сборки мусора и проч.
В моем посте, даже наивная реализация с realloc на каждые 8 байтов обгоняет Lisp В 7_406_000 РАЗ. Заканчивай с этими сказками.